YSTEM EQUIREMENTS OCUMENTemits.sso.esa.int/emits-doc/ESTEC/AO-1-5763-AD8-P3-EST-RS-1001-i… ·...

D O C U M E N T

document title/ titre du document

YSTEM EQUIREMENTS OCUMENT

prepared by/préparé par PROBA 3 Project Team reference/réference P3-EST-RS-1001 issue/édition 1_4 revision/révision date of issue/date d’édition July 10th 2008 status/état Under review Document type/type de document SRD Distribution/distribution

a

ESTEC European Space Research and Technology Centre - Keplerlaan 1 - 2201 AZ Noordwijk - The Netherlands Tel. (31) 71 5656565 - Fax (31) 71 5656040 www.esa.int

P3-EST-RS-1001_issue 1_4

from 10_07_2008.doc

PROBA 3 / SRD

Issue 1_4 revision - July 10th 2008

P3-EST-RS-1001 page ii of viii

A P P R O V A L

Title Titre

issue issue

1_4 revision revision

-

author auteur

date date

July 10th 2008

approved by approuvé by

date date

C H A N G E L O G

reason for change /raison du changement issue/issue revision/revision date/date

C H A N G E R E C O R D

Issue: -1_4 Revision: -

reason for change/raison du changement page(s)/page(s) paragraph(s)/paragraph(s)

PROBA 3 / SRD


P3-EST-RS-1001 page iii of viii

T A B L E O F C O N T E N T S

1 INTRODUCTION ......................................................................................................9 1.1 Scope of Document ..................................................................................................................9 1.2 Definitions................................................................................................................................9 1.3 Requirements Identification...................................................................................................11

2 MISSION OBJECTIVES .........................................................................................12

3 APPLICABLE AND REFERENCE DOCUMENTS .................................................13 3.1 Applicable Documents ...........................................................................................................13

3.1.1 Applicable Standards and Regulations ..................................................................................13 3.1.2 ESA Applicable Documents ..................................................................................................15 3.1.3 Other Applicable Documents.................................................................................................15

3.2 Reference Documents ............................................................................................................16

4 SYSTEM REQUIREMENTS ...................................................................................16 4.1 System Performance Requirements .......................................................................................16 4.2 System Architecture, Configuration and Coordinate Frames ................................................16

4.2.1 Architecture and Configuration..............................................................................................16 4.2.2 Reference Coordinate Frames ................................................................................................17

4.2.2.1 General .................................................................................................................................17 4.2.2.2 ECI: Earth-Centred Inertial Frame.......................................................................................17 4.2.2.3 ROF: Rotating Orbit Frame .................................................................................................17 4.2.2.4 STF: Sun Target Frame........................................................................................................18 4.2.2.5 GFF: Geometric Fixed Frame .............................................................................................18 4.2.2.6 RBF: Rotating Body Frame ................................................................................................19 4.2.2.7 PLF: Payload Frame............................................................................................................19 4.2.2.8 Additional Reference Frames...............................................................................................20

4.3 Mission Profile Requirements................................................................................................20 4.3.1 Orbit Requirements ................................................................................................................20 4.3.2 Launch Vehicle Requirements ...............................................................................................21 4.3.3 Propulsion Module Requirements..........................................................................................21 4.3.4 Mission Lifetime ....................................................................................................................21 4.3.5 Mission Phases.......................................................................................................................22

4.3.5.1 General .................................................................................................................................22 4.3.5.2 Launch and Early Operations Phase ....................................................................................22 4.3.5.3 Orbit Raising Phase..............................................................................................................23 4.3.5.4 Commissioning Phase ..........................................................................................................24 4.3.5.5 Operational Phase ................................................................................................................25 4.3.5.6 Extended Operational Phase ................................................................................................25

PROBA 3 / SRD


P3-EST-RS-1001 page iv of viii

4.3.5.7 Post-Operational Phase ........................................................................................................26 4.3.5.8 De-Orbiting Phase................................................................................................................26

4.4 Environment Requirements....................................................................................................26 4.4.1 General ...................................................................................................................................26 4.4.2 Ground Environment..............................................................................................................26 4.4.3 Launch Environment..............................................................................................................27 4.4.4 Space Environment ................................................................................................................27 4.4.5 Mechanical Environment .......................................................................................................27 4.4.6 Thermal Environment ............................................................................................................27 4.4.7 Cleanliness/Contamination ....................................................................................................28 4.4.8 Electromagnetic Cleanliness ..................................................................................................28 4.4.9 Radiation ................................................................................................................................29

4.4.9.1 General .................................................................................................................................29 4.4.9.2 Radiation Dose.....................................................................................................................29 4.4.9.3 Radiation Induced Background............................................................................................29 4.4.9.4 Single Events Effects ...........................................................................................................29 4.4.9.5 Internal Charging .................................................................................................................31

5 FORMATION FLYING REQUIREMENTS ..............................................................31 5.1 General Formation Flying GNC Requirements .....................................................................31 5.2 Formation Flying Performance Requirements .......................................................................34 5.3 Formation Flying Manoeuvre Requirements .........................................................................35 5.4 Technology Requirements .....................................................................................................38

5.4.1 Technology Validation Requirements....................................................................................38 5.4.2 FF Metrology Requirements ..................................................................................................39

5.4.2.1 Coarse Metrology Requirements .........................................................................................39 5.4.2.2 Fine Metrology Requirements .............................................................................................40

5.4.3 FF Propulsion Requirements..................................................................................................41 5.5 RV Experiment Induced Requirements .................................................................................42 5.6 FDIR Requirements ...............................................................................................................42 5.7 Scientific Mission Induced Requirements .............................................................................43

6 CORONAGRAPH MISSION REQUIREMENTS .....................................................43 6.1 General ...................................................................................................................................43 6.2 Requirements on Formation Flying .......................................................................................43 6.3 Constraints induced by Sun pointing .....................................................................................45 6.4 Constraints induced by orbit parameters................................................................................46 6.5 Coronagraph design and accommodation requirements ........................................................46

7 SPACE SEGMENT REQUIREMENTS ...................................................................48 7.1 Spacecraft Functional and Design Requirements ..................................................................48

7.1.1 General Requirements............................................................................................................48 7.1.1.1 Satellite Lifetime..................................................................................................................48 7.1.1.2 Autonomy.............................................................................................................................48

PROBA 3 / SRD


P3-EST-RS-1001 page v of viii

7.1.1.3 Safe Mode ............................................................................................................................49 7.1.1.4 Fault Management................................................................................................................50 7.1.1.5 FDIR.....................................................................................................................................51 7.1.1.6 Fault Tolerance ....................................................................................................................51 7.1.1.7 Redundancy..........................................................................................................................51 7.1.1.8 Margin Policy.......................................................................................................................52

7.1.1.8.1 Mass Margin ..................................................................................................................52 7.1.1.8.2 On-Board Propulsion Margins .......................................................................................52 7.1.1.8.3 Launcher Margins ..........................................................................................................53 7.1.1.8.4 Electrical Power Margin ................................................................................................53 7.1.1.8.5 Data Processing Margins ...............................................................................................54 7.1.1.8.6 Communication Margins................................................................................................54 7.1.1.8.7 Radiation Margins..........................................................................................................54

7.1.2 Architecture and Configuration..............................................................................................55 7.1.2.1 Space Segment .....................................................................................................................55 7.1.2.2 Launch Composite ...............................................................................................................55 7.1.2.3 Satellite Stack.......................................................................................................................56 7.1.2.4 Coronagraph Spacecraft (CS) ..............................................................................................56 7.1.2.5 Occulter Spacecraft (OS) .....................................................................................................56 7.1.2.6 Propulsion Module (PM) .....................................................................................................57 7.1.2.7 Launcher Interface ...............................................................................................................57 7.1.2.8 Propulsion Module Interface (only LPM case)....................................................................57

7.1.3 Structure and Mechanisms Requirements..............................................................................57 7.1.3.1 General Requirements..........................................................................................................57 7.1.3.2 Structure Definitions and Functions ....................................................................................58 7.1.3.3 Damage Tolerance ...............................................................................................................59 7.1.3.4 Strength ................................................................................................................................59 7.1.3.5 Factors ..................................................................................................................................61 7.1.3.6 Notching...............................................................................................................................63 7.1.3.7 Stiffness................................................................................................................................64 7.1.3.8 Fracture ................................................................................................................................65 7.1.3.9 Mechanisms .........................................................................................................................65 7.1.3.10 Pyrotechnics .....................................................................................................................67 7.1.3.11 Mechanical Parts ..............................................................................................................67 7.1.3.12 Materials...........................................................................................................................67 7.1.3.13 Alignment Stability ..........................................................................................................67

7.1.4 Thermal Control Requirements..............................................................................................68 7.1.4.1 General .................................................................................................................................68 7.1.4.2 Definitions............................................................................................................................68 7.1.4.3 Operability ...........................................................................................................................68 7.1.4.4 Functional.............................................................................................................................68 7.1.4.5 Thermal Performance...........................................................................................................69 7.1.4.6 Thermal Design....................................................................................................................69 7.1.4.7 Verification ..........................................................................................................................70

7.1.4.7.1 Analysis..........................................................................................................................70

PROBA 3 / SRD


P3-EST-RS-1001 page vi of viii

7.1.4.7.2 Software .........................................................................................................................70 7.1.4.7.3 Test.................................................................................................................................70

7.1.5 Onboard Propulsion Requirements ........................................................................................70 7.1.5.1 Terms, Definitions, Abbreviations and Symbols .................................................................70 7.1.5.2 General Requirements..........................................................................................................71 7.1.5.3 Functional Requirements .....................................................................................................71 7.1.5.4 Performance Requirements ..................................................................................................72 7.1.5.5 Operational Requirements....................................................................................................72 7.1.5.6 Design Requirements ...........................................................................................................73 7.1.5.7 Verification Requirements ...................................................................................................74

7.1.6 Electrical Power Requirements ..............................................................................................74 7.1.6.1 General Requirements..........................................................................................................74 7.1.6.2 Failure Containment and Redundancy.................................................................................75 7.1.6.3 Energy Generation ...............................................................................................................75 7.1.6.4 Energy Storage.....................................................................................................................79 7.1.6.5 Power Conditioning and Control .........................................................................................80 7.1.6.6 Power Distribution and Protection.......................................................................................80 7.1.6.7 Harness.................................................................................................................................82

7.1.7 Electromagnetic Compatibility Requirements .......................................................................83 7.1.8 Command, Control and Data Handling Requirements ..........................................................84

7.1.8.1 Definitions............................................................................................................................84 7.1.8.2 General Requirements..........................................................................................................84 7.1.8.3 Spacecraft Control Requirements ........................................................................................85 7.1.8.4 Functional Requirements .....................................................................................................86 7.1.8.5 Performance Requirements ..................................................................................................87 7.1.8.6 Design and Operational Requirements.................................................................................87 7.1.8.7 Redundancy..........................................................................................................................90 7.1.8.8 Autonomy, FDIR and Safe Mode ........................................................................................90 7.1.8.9 Testability.............................................................................................................................91

7.1.9 Communication Subsystem Requirements ............................................................................91 7.1.9.1 Definitions............................................................................................................................91 7.1.9.2 General .................................................................................................................................91 7.1.9.3 Functional Requirements .....................................................................................................92 7.1.9.4 Performance Requirements ..................................................................................................92 7.1.9.5 Inter Satellite Link ...............................................................................................................93 7.1.9.6 Verification ..........................................................................................................................93

7.1.10 Command and Control requirements .....................................................................................93 7.1.11 GNC Requirements ................................................................................................................95

7.1.11.1 General .............................................................................................................................95 7.1.11.2 Functional Requirements .................................................................................................97 7.1.11.3 Design and Operational Requirements.............................................................................97 7.1.11.4 Composite Operations Requirements...............................................................................98 7.1.11.5 Verification Requirement.................................................................................................98

7.1.12 Software Engineering Requirements .....................................................................................98 7.1.12.1 General .............................................................................................................................98

PROBA 3 / SRD


P3-EST-RS-1001 page vii of viii

7.1.12.2 Software Specification .....................................................................................................99 7.1.12.3 Software Design.............................................................................................................100 7.1.12.4 Software Implementation...............................................................................................101 7.1.12.5 Software Maintenance During Flight.............................................................................102 7.1.12.6 Software Test Bed / Software Validation Facility .........................................................102 7.1.12.7 Software Validation Process ..........................................................................................103 7.1.12.8 Software Delivery and Acceptance Process...................................................................103 7.1.12.9 Software Verification Process........................................................................................103 7.1.12.10 Software Management Process ......................................................................................104

7.2 Spacecraft Operational Requirements..................................................................................104 7.2.1 Spacecraft Operability..........................................................................................................104 7.2.2 Spacecraft Commandability .................................................................................................105

7.2.2.1 General ...............................................................................................................................105 7.2.2.2 Mission Timeline Management .........................................................................................107

7.2.3 Spacecraft Observability ......................................................................................................108 7.3 Verification Requirements ...................................................................................................110

7.3.1 General Aspects ...................................................................................................................110 7.3.1.1 Verification Objective........................................................................................................110 7.3.1.2 Verification Scope..............................................................................................................110

7.3.2 Verification Approach..........................................................................................................111 7.3.2.1 General ...............................................................................................................................111 7.3.2.2 Requirement identification and traceability .......................................................................111 7.3.2.3 Requirement Attributes ......................................................................................................111 7.3.2.4 Verification Methods .........................................................................................................112 7.3.2.5 Level of Verification..........................................................................................................112

7.3.3 Model Philosophy ................................................................................................................112 7.3.3.1 Satellite System and Subsystem Models............................................................................112 7.3.3.2 Simulators and Test Benches .............................................................................................113 7.3.3.3 Decoupling of Payload and Satellites ................................................................................113

7.3.4 GSE ......................................................................................................................................114 7.3.5 Verification Data Base .........................................................................................................114 7.3.6 Satellite Reference Data Base ..............................................................................................114 7.3.7 Ground Segment Compatibility Tests..................................................................................114

8 GROUND SEGMENT REQUIREMENTS .............................................................115 8.1 General .................................................................................................................................115 8.2 Ground Station Characteristics ............................................................................................116 8.3 Monitoring and Control .......................................................................................................117 8.4 Mission Planning..................................................................................................................117 8.5 On-Board Software Maintenance.........................................................................................118 8.6 Flight Dynamics ...................................................................................................................119 8.7 Formation Flying..................................................................................................................120

9 OPERATIONS REQUIREMENTS ........................................................................121 9.1 General .................................................................................................................................121

PROBA 3 / SRD


P3-EST-RS-1001 page viii of viii

9.2 Operations Preparation.........................................................................................................122 9.3 Operational Validation.........................................................................................................123

10 ACRONYMS.........................................................................................................123

PROBA 3 / SRD

issue 1_4 revision - July 10th 2008 P3-EST-RS-1001 page 9 of 127

1 INTRODUCTION

1.1 Scope of Document IN-1-D This System Requirements Document (SRD) establishes the system

functional and technical requirements applicable to the PROBA-3 mission, afterwards called “PROBA-3”.

IN-2-D It shall serve as the baseline requirement document for the PROBA-3 system, focusing on the Space Segment (SSEG), the Launch Segment (LSEG), the Ground Segment (GSEG) and Operations (OPS).

IN-3-N Note: In most areas the basic requirements are covered by the applicable documents and standards. However, in some areas the most important requirements are recalled explicitly to highlight their importance.

1.2 Definitions IN-4-D Goal requirement is an essential requirement for ensuring the

mission’s objectives that, due to the demonstration nature of the mission does not have sufficient heritage or background in order to be defined as a regular mandatory requirement. However, the contractor is requested to provide proper justification for the approval of the Agency in case such a goal requirement is not, or only partially, met.

IN-5-D Safe Mode is a mode that shall ensure the safety of the spacecraft under all conditions, i.e. it shall ensure no possibility of collision or separation beyond that which can be recovered with the spacecraft on board resources.

IN-6-D Vital functions are those that, if not executed, or wrongly executed, or executed at the incorrect time could cause mission degradation.

IN-7-D Hazardous functions are those which when executed at the incorrect time could cause permanent mission degradation or mission loss, or damage to equipment, facilities or personnel.

IN-8-D High-priority TC is a telecommand (TC) executed without the intervention of the On-Board Software (OBSW).

IN-9-D Launch Composite defines the complete stack ontop of the launcher comprising the Occulter Spacecraft (OS), the Coronagraph Spacecraft

PROBA 3 / SRD


(CS) and the Propulsion Module (PM). This includes all necessary adapters and separation systems.

IN-10-D Occulter Spacecraft (OS) is the spacecraft with the Occulting Disc. In the present document the OS is also referred to as the formation centre spacecraft (FCS) – usually this satellite is the target or mirror spacecraft.

IN-11-D Coronagraph Spacecraft (CS) is the spacecraft with the Coronagraph Instrument/Optics. In the present document the CS is also referred to as the formation second spacecraft (F2S)

IN-12-D Spacecraft A (SC-A) is the spacecraft that will contain the sensing elements of the high-accuracy metrology (HAM) subsystem. SC-A can be either FCS or F2S.

IN-13-D Spacecraft B (SC-B) is the spacecraft that does not contain the sensing elements of the HAM subsystem.

IN-14-D Propulsion Module (PM) is a separable propulsion stage that is used to transfer from the launch orbit to the operational orbit.

IN-15-D Satellite Stack (SS) is the stack comprising the Occulter Spacecraft, the Coronagraph Spacecraft. This includes all necessary adapters and separation systems.

IN-16-D Off-line Operations is the nominal mode of PROBA-3 operations whereby the commands/instructions are up-loaded to the satellites in advance, the satellites operated fully autonomously for the off-line period, and data is downloaded during scheduled ground station contacts for analysis at a later date.

IN-17-D Ground Response Time is the time inside which no interraction is required from the ground. This time includes all activities involved in commanding the satellites, i.e. detection and clarification of satellite configuration, determination of action required, preparation and validation (if required) of action and execution of action. The ground station contacts must be organised to be commensurate with these activities.

IN-18-D Validation is the Proof by examination of objective evidence and specific testing, that the product accomplishes the intended purpose. In addition,proof that the product functions in the expected manner when placed in the intended environment. Validation is performed to ensure that the product is ready for a particular use, function, or mission and may be determined by test, analysis, demonstration, or a combination of these.

PROBA 3 / SRD


IN-19-D Operational Validation is the set of specific validation activities that demonstrate the correct performance of all operations products, processes and people, working together, within a representative environment, during representative operational scenarios, e.g. Nominal operations, LEOP. The operational validation demonstrates the correct operations of the space to ground chain including all operational interfaces and communications, and using operational versions of products and systems.

1.3 Requirements Identification IN-20-D All objects in this document are identified by a unique alphanumeric

code with the following format:

XX-YYY-Z

IN-21-D The first set of characters, XX refers to the chapters of this SRD

IN = Introduction

MO= Mission Objectives

DO= Documents (applicable and reference)

SY = System Requirements

FF = Formation Flying Requirements

CO = Coronagraph Mission Requirements

SS = Space Segment Requirements

GS = Ground Segment Requirements

OP = Operations Requirements

IN-22-D The second set of characters, YYY refers to requirements numbers. The sequence of these numbers may contain gaps.

IN-23-D The third set of characters, Z refers to the category of objects included in this document:

R - Requirements to be mandatorily complied with, and verified, by the Contractor.

G – Goal requirements (or performance goals), to be subject of system trade-off analysis by the Contractor, and to be complied with

PROBA 3 / SRD


under limited conditions to be defined and quantified (see complete definition in chapter 1.2)

D – Definitions providing descriptive/clarification text about a set of requirements or goals.

N - Notes providing supporting information about a set of requirements or goals.

2 MISSION OBJECTIVES MO-1-D PROBA-3 is an experimental mission devoted to the in-orbit

demonstration of new techniques and technology, namely Formation Flying (FF).

MO-2-D The main objectives of the PROBA_3 mission are:

The development to Technology Readiness Level (TRL) 9, in-orbit demonstration, of the Formation Flying techniques and associated technologies

The development and validation of the ground verification tools and facilities

The implementation of a guest payload devoted to the observation of the Sun Corona as part of the demonstration of FF

MO-3-D The PROBA-3 Mission is part of the In Orbit Demonstration (IOD) program of ESA aiming at in-orbit demonstration of technologies for future larger programs.

MO-4-D As a successor of PROBA-1 and PROBA-2 missions, on-board autonomy and off-line operations are planned to complement and support the Formation Flying mission.

MO-5-D The PROBA-3 mission targets to be a precursor of the XEUS Science Mission and as such PROBA-3 will consist of two spacecraft demonstrating the capability to fly into a given geometrical configuration in order to achieve the function of a single large virtual spacecraft.

MO-6-D The more detailed objectives of the PROBA-3 mission are :

Demonstration of Formation Flying and GNC specific Control Algorithms

PROBA 3 / SRD


Demonstration of Formation Flying metrologies, sensors and actuators.

Demonstration of the autonomy concept in the frame of Formation Flying

Demonstration of FDIR and Safe Mode concept for spacecraft flying in formation

Development, verification and validation of tools needed to support Formation Flying future missions

Validation of the Ground Segment and the operational concept for multiple spacecrafts flying in formation.

Observation of the Sun Corona using a dedicated Coronagraph instrument and the Formation Flying capability of the two spacecraft flying in a dedicated configuration.

3 APPLICABLE AND REFERENCE DOCUMENTS

3.1 Applicable Documents DO-1-D The following documents are applicable to the requirements of the

present specification.

DO-2-D In general, Applicable Documents apply in their entirety, if the applicability is not explicitly restricted in this document.

DO-3-D In the case of conflicts between this document and the applicable documents the conflict shall be brought to the attention of ESA for resolution.

3.1.1 APPLICABLE STANDARDS AND REGULATIONS

AD 1 ECSS-E-ST-10C Space engineering - System engineering – General requirements

AD 2 ECSS-E-ST-10-06C Space engineering - System engineering - Functional and technical specification

AD 3 ECSS-E-ST-10-02C Space engineering - Verification

PROBA 3 / SRD


AD 4 ECSS-E-ST-10-04C Space engineering - Space environment

AD 5 ECSS-E-ST-10-12C Space engineering - Radiation dose

AD 6 ECSS-E-ST-20C Space engineering - Electrical and electronic

AD 7 No document

AD 8 ECSS-E-ST-20-08C Space engineering - Photovoltaic assemblies and components

AD 9 ECSS-E-ST-31C Space engineering - Thermal control - general requirements

AD 10 ECSS-E-ST-32C Space engineering - Structural – general requirements

AD 11 ECSS-E-ST-33-01C Space engineering - Mechanisms

AD 12 ECSS-E-ST-35-01C Space engineering - Liquid and electric propulsion for spacecraft

AD 13 ECSS-E-ST-33-11C Space engineering - Explosive systems and devices

AD 14 No document

AD 15 ECSS-E-ST-32-08C Space engineering - Materials

AD 16 ECSS-E-ST-32-01C Space engineering - Fracture control

AD 17 ECSS-E-ST-32-11C Space engineering - Modal survey assessment

AD 18 ECSS-E-ST-40C Space engineering - Software - general requirements

AD 19 No document

AD 20 ECSS-E-ST-50C Space engineering - Communications

AD 21 ECSS-E-ST-50-01C Space engineering - Space data links - Telemetry synchronization and channel coding

AD 22 ECSS-E-ST-50-03C Space engineering - Space data links - Telemetry transfer frame protocol

AD 23 ECSS-E-ST-50-04C Space engineering - Space data links - Telecommand protocols, synchronization and channel coding

AD 24 ECSS-E-ST-50-05C Space engineering - Radio frequency and modulation

PROBA 3 / SRD


AD 25 ECSS-E-ST-70-41C Space engineering - Telemetry and telecommand packet utilization

AD 26 CCSDS 133.0-B-1 Space Packet Protocol. Blue Book. Issue 1.(ISO 22646), Sep-2003

AD 27 ECSS-Q-ST-70 C Space product assurance - Materials, mechanical parts and processes

AD 28 ECSS-Q-ST-70-01C Space product assurance - Contamination and cleanliness control

AD 29 ECSS-Q-ST-70-36C Space product assurance - Materials selection for controlling stres-corrosion cracking

AD 30 PSS-03-208 Guidelines for threaded fasteners, Issue TBD

AD 31 Space systems - Electromagnetic compatibility requirements, ISO 14302-2002(E), edition 2002-12-15

AD 32 Council Directive on the approximation of the laws of the Member States relating to electromagnetic compatibility, 89/336/EEC, 3 May 1989

AD 33 ECSS-E-ST-10-03C Space engineering – Testing

3.1.2 ESA APPLICABLE DOCUMENTS

AD 34 PROBA 3 Environmental Specification, P3-EST-RS-6003, Issue 1, 17 June 2008

AD 35 Error Budgets for Formation Flying Missions, NPD/5022/TD/TR/001 v1.r1.m0, Issue 1.1, 03 March 2008

AD 36 PROBA-3 Ground Segment and Operations Concept Framework, P3-EST-PL-6002

3.1.3 OTHER APPLICABLE DOCUMENTS

AD 37 Vega User’s Manual, Issue 3, Revision 0, March 2006

AD 38 TBD Launcher User’s Manual

AD 39 S2.ASU.ICD.2006 Propulsion Module Mechanical Interface Control Document, Issue 6, March 2006.

http://ice.sso.esa.int/intranet/public/docs/standards/CCSDS-133.0-B-1.pdf

PROBA 3 / SRD


AD 40 S2.ASU.ICD.7013 LISA Pathfinder Propulsion Module Harness Electrical Interface Control Document, Issue 3, February 2007.

AD 41 S2.ASU.ICD.7013 LISA Pathfinder Propulsion Module Thermal Interface Control Document, Issue 4, March 2007.

AD 42 S2.ASU.MA.7002 LISA Pathfinder Propulsion Module User Manual, Issue TBD, Date TBD.

3.2 Reference Documents

RD 1 Preliminary XEUS Pointing Requirements, SCI-A/2006.111/NR, Issue 3, Revision 0, 25 August 2006 (ESA)

RD 2 ECSS-E-ST-20-06C Space engineering - Spacecraft charging

RD 3 XEUS-CV Technical Report, CDF-76(A) 2008.

4 SYSTEM REQUIREMENTS

4.1 System Performance Requirements SY-1-R The PROBA-3 system shall support the mission objectives as specified

in chapter 2.

SY-2-R The PROBA-3 system shall support the achievement of the Formation Flying requirements as specified in chaper 5.

SY-3-R The PROBA-3 system shall support the achievement of the Coronograph Mission requirements as specified in chaper 6.

SY-4-G As a goal requirement, the PROBA-3 system shall be optimized from an overall system point of view, i.e. aiming at the most cost effective solution when taking into account all Flight, Ground and Launch Segments.

4.2 System Architecture, Configuration and Coordinate Frames

4.2.1 ARCHITECTURE AND CONFIGURATION SY-5-R The PROBA-3 system shall be composed of a :

Space Segment.

PROBA 3 / SRD


Ground Segment (including Operations)

Launch Segment.

SY-6-R The Space Segment shall be compliant with the requirements defined in chapter 7.

SY-7-R The Ground Segment and Operations shall be compliant with the requirements defined in chapter 8 and chapter 9 within the framework outlined in AD 36 .

SY-8-N Note: The Launch Segment and potential Propulsion Module requirements are provided in section 4.3.2 and 4.3.3, respectively.

4.2.2 REFERENCE COORDINATE FRAMES

4.2.2.1 General

SY-9-R All reference frames shall be right-handed and orthogonal.

4.2.2.2 ECI: Earth-Centred Inertial Frame

SY-10-D The Earth-Centred Inertial (ECI) reference frame will be the J2000 equatorial coordinate system and is defined as follows:

The origin is at the centre of the Earth

The +X axis is at the intersection of the mean ecliptic plane with the mean equatorial plane at the date of 01/01//2000 and pointing positively towards the vernal equinox

The +Z axis is orthogonal to the mean equatorial plane at the date of 01/01/2000 and pointing positively towards the north

The +Y axis completes the right handed reference frame

4.2.2.3 ROF: Rotating Orbit Frame

SY-11-D The Rotating Orbit Frame (also referred to as the Local Vertical Local Horizontal, or LVLH frame) is the coordinate system defined as follows:

The origin is located at the FCS centre of mass.

PROBA 3 / SRD


The +Z axis points towards the centre of the Earth.

The +Y axis is parallel to the orbit angular momentum vector, pointing in the opposite direction (i.e. orbit anti-normal).

The +X axis completes the right-handed set

4.2.2.4 STF: Sun Target Frame

SY-12-D The Sun Target Frame (STF) is the coordinate system defined as follows:

the origin is located at the centre of the occulting disk on the Occulter Spacecraft

the +Z axis points towards the centre of the Sun.

the +X and +Y axes must be defined appropriately (TBC)

4.2.2.5 GFF: Geometric Fixed Frame

SY-13-D A Geometric Fixed Frame (GFF) is used as a reference for each satellite and is fixed to the structure of the satellite; typically a launch interface mechanical point. A direction cosine matrix will specify the orientation with respect to the RBF, although the GFF is nominally defined as follows:

the origin is located at some fixed mechanical point on the rigid spacecraft struture, with respect to which all avionics equipments is located.

On the Occulter Spacecraft, the +Z axis is along the nominal axis of symmetry of the occulting disc

On the Coronagrpah Spacecraft, the +Z axis is along the nominal boresight of the coronagraph instrument


PROBA 3 / SRD


4.2.2.6 RBF: Rotating Body Frame

SY-14-D A Rotating Body Frame (RBF) is fixed to each satellite and used by the GNC system. A direction cosine matrix will specify the orientation with respect to the GFF. The RBF is defined as follows:

the origin is located at the centre of mass of the satellite.

On the Occulter Spacecraft, the +Z axis is along the nominal axis of symmetry of the occulting disc

On the Coronagrpah Spacecraft, the +Z axis is along the nominal boresight of the coronagraph instrument


4.2.2.7 PLF: Payload Frame

SY-15-D The Payload Frame (PLF) is fixed to the Coronagraph instrument components as follows:

For the Coronagraph Spacecraft:

the origin is located at the centre of the corograph instrument aperture.

the +Z axis is along the nominal boresight of the coronagraph instrument

the +X axis is in the X-Z plane of the GFF

the +Y axis completes the right-hand set

For the Occulter Spacecraft:

the origin is located at the centre of the occulting disk on the Occulter Spacecraft

the +Z axis is along the nominal axis of symmetry of the occulting disc

the +X axis is in the X-Z plane of the GFF

the +Y axis completes the right-hand set

PROBA 3 / SRD


4.2.2.8 Additional Reference Frames

SY-16-R In addition, there will be additional frames required, that shall be specified by the Contractor.

SY-17-R All additional reference frames shall be defined in relation to the frames given above.

SY-18-R All body-fixed reference frames shall be specified with respect to the relevant spacecraft GFF.

SY-19-R For structural design purposes, at minimum, the following frames of reference shall be defined by the Contractor:

Individual Proba-3 spacecraft (CS and OS) with its origins at the deployed CoG location (defined as the RBF above)

Individual Proba-3 spacecraft (CS and OS) with its origins at , or nearby the respective separation planes

Launch composite (PM, CS, OS) with its origin at the deployed CoG location

Launch composite (PM, CS, OS) with its origin at or nearby the PM to Launcher separation plane

4.3 Mission Profile Requirements

4.3.1 ORBIT REQUIREMENTS SY-20-R The PROBA-3 orbit shall be a high elliptical orbit (HEO) to ensure a low

perturbation environment around its apogee.

SY-21-N Note: During the PROBA-3 Phase A studies, various potential orbits were assessed. The mission analysis has concluded that the most suitable orbit for the PROBA-3 system will have the following parameters:

High Eliptical Earth Orbit with 24 hours period

Apogee around 70.000 km

Perigee around 800 km

PROBA 3 / SRD


SY-22-R Orbital parameters shall be chosen such that there are at least 12 (TBC) hours coverage of the main Ground Station over the full mission lifetime without orbital corrections.

SY-23-R The perigee of the orbit shall be chosen such that there is no risk of re-entering the atmosphere during the mission lifetime.

4.3.2 LAUNCH VEHICLE REQUIREMENTS SY-24-G As a goal requirement and as a baseline the PROBA 3 satellites shall

be launched by a Vega launcher from Kourou on an HEO orbit of one day period.

SY-25-R In case the goal requirement SY-24-G from above cannot be met a backup launcher from TBD on an HEO orbit of one day period shall be defined and justified by the contractor.

SY-26-R The spacecraft shall be compatible with the baseline and possible backup launcher requirements and environment for all ground, ascent and orbit phases.

4.3.3 PROPULSION MODULE REQUIREMENTS SY-27-R In case the goal requirement SY-24-G from above is met, an additional

Propulsion Module able to deliver the spacecraft stack into the final operational orbit shall be defined/selected.

SY-28-N Note: The PROBA 3 satellites may use the LISA Pathfinder Propulsion Module (LPM) as additional propulsion stage to the Vega launcher (TBC).

4.3.4 MISSION LIFETIME SY-29-R The nominal mission lifetime shall be 2 years.

SY-30-R The nominal mission lifetime shall commence after separation from the launcher.

PROBA 3 / SRD


4.3.5 MISSION PHASES

4.3.5.1 General

SY-31-R Seven mission phases shall be considered: the Launch and Early Operations Phase (LEOP), the Transfer Phase, the Commissioning Phase, the Operational Phase, the Extended Operational Phase, the Post-Operational Phase and the De-orbiting Phase.

SY-32-R Up-link and down-link capabilities on the operational orbit shall be sized for a typical ground station operation period of up to 15 (TBC) hours/day including overheads .

SY-33-R Throughout all mission phases and orbits, ground contact shall be possible at all times whilst the spacecraft are visible from the allocated ground stations..

4.3.5.2 Launch and Early Operations Phase

SY-34-D The Launch and Early Orbit Phase (LEOP) is defined as the period following separation of the Launch Composite or Satellite Stack, as appropriate, from the launcher until declared ready for apogee raising manoeuvre.

SY-35-R The LEOP operations to be defined by the Contractor shall include the following key events:

The switch-over from ground-supplied power to the Satellite Stack internal source of power during the launch count-down

The launch and ascent phase until separation of the Satellite Stack or Launch Composite from the launcher.

SY-36-R The master spacecraft shall autonomously detect separation from the launch vehicle.

SY-37-R Following separation from the launcher the Launch Composite or Satellite Stack shall autonomously initiate a sequence that will bring it to a predefined mode.

SY-38-R Any conditions that could cause the automatic initialisation sequence to damage the spacecraft shall be identified on-board and appropriate autonomous actions shall be taken by the spacecraft.

PROBA 3 / SRD


SY-39-R There shall be no nominal or contingency activities performed during LEOP that will require a ground response time of less than 2 hours (TBC).

SY-40-R The entire LEOP shall not exceed 2 (TBC) days.

SY-41-N Note: LEOP implies 24 hour operations shift coverage and near 24 hour station coverage as the spacecraft configuration requires a high level of monitoring. When this level of criticality is lowered, LEOP can be declared over and the next phase can begin.

SY-42-R The ESTRACK network of ground stations shall be used for communications with the spacecraft during the LEOP.

SY-43-D The recovery actions expected after the failure is detected and before the sequence is restarted are TBD.

SY-44-R After separation from the launcher stage, the master spacecraft shall autonomously activate one of the transmitter channels and thus allow the ESA ground station network to establish the first contact.

SY-45-R After separation from the launcher upper stage, the Satellite Stack or Launch Composite shall autonomously reduce any remaining body rates.

SY-46-R Following separation from the launch vehicle the Satellite Stack or Launch Composite shall provide the necessary attitude information for attitude reconstitution on the ground.

4.3.5.3 Orbit Raising Phase

SY-47-D Following the LEOP, the orbit raising phase will include all operations required to bring the Satellite Stack, or Lauch Composite, as applicable, to the operational orbit.

SY-48-R During the orbit raising phase there shall be no nominal or contingency activities that will require a ground response time of less than 24 hours (TBC).

SY-49-R It shall be ensured that the signal of the spacecraft stack can be safely acquired at the ground station within 3 hours (TBC) of each orbit raising manoeuvre.

SY-50-R There shall be no criticalities for the orbit raising manoeuvre sequence, i.e. if it is not possible to perform the manoeuvre at the planned time, it shall be possible to replan the manoeuvre for a subsequent orbit.

PROBA 3 / SRD


SY-51-R During an orbit correction period, if needed, adjustment manoeuvres to reach the reference operational orbit shall be performed in order to correct for the launcher dispersion errors.

4.3.5.4 Commissioning Phase

SY-52-R The Commissioning Phase shall include the Satellite Stack separation from the PM (if applicable), the Coronagraph S/C separation from the Occulter S/C and initial loose formation acquisition.

SY-53-R The commissioning phase shall be completed before launch plus 3 months.

SY-54-R During the commisioning phase the PROBA-3 satellites shall be incrementally brought into a fully operational state, with the objective to verify and characterise the performance of all units, subsystems and Coronagraph instrument functions, and to validate the Ground Segment operations and the capability to deliver the specified user products.

SY-55-R Full activation of the on-board FDIR, as appropriate for ensuring the safety of the satellites in their current configuraiton, shall be initiated immediately after separation from the PM or launcher, respectively.

SY-56-R During the commissioning phase there shall be no nominal or contingency activities that will require a ground response time of less than 3 days (TBC).

SY-57-R The commissioning activities shall be operated ‘off-line’, i.e. the commissioning activities will be uploaded to the on-board queue for later execution.

SY-58-D The commissioning activities will be evaluated during office hours, from telemetry dumped during planned, scheduled ground station passes.

SY-59-R One ground station shall be used for communications with the spacecraft during the commissioning phase.

SY-60-R The activities during the commissioning phase shall be organised in a manner that minimises the risk to spacecraft safety.

SY-61-R Authorisation points (GO/NO GO) prior to critical activities shall be identified by the Contractor and included in the commissioning procedures for Agency approval.

PROBA 3 / SRD


SY-62-R Subsequent to its separation, the PM (if applicable) shall be directed to an orbit that is not posing risk on the further operation of the Satellite Stack and later of the two PROBA-3 spacecraft.

4.3.5.5 Operational Phase

SY-63-D The operational phase is defined as the operational period between completion of commissioning (as agreed at the Commissioning Completion Review), and the Formation Flying objectives being met.

SY-64-R One Ground Station shall be used for communications with the spacecraft during the operational phase.

SY-65-R Formation Flying activities shall be planned for execution such as to be visible from the allocated Ground Station.

SY-66-R Monitoring and control of the formation flying demonstrations may be desirable during visibilities from the ground station within office hours, but there shall be no dependencies on the ground for the safe demonstration completion.

SY-67-R During the operational phase there shall be no nominal or contingency activities that will require a ground response time of less than 1 week (TBC). Exceptions to this requirement will be specifically stated in this document.

SY-68-R The spacecraft design shall account for Solar eclipses during which no experiment (neither scientific nor FF technologies) will be performed.

SY-69-D Sun pointing formation may be broken at apogee pass for Formation Flying technologies test purpose.

SY-70-D Sun pointing formation may be broken at perigee pass at any time.

SY-71-R Orbit selection shall maximise the visibility of the Redu ground station during the complete 2 years lifetime without any on board orbit correction.

4.3.5.6 Extended Operational Phase

SY-72-R The extended operations phase shall exploit the remaining resources on board for the continuation of the payload operations, following the completion of the formation flying objectives.

PROBA 3 / SRD


SY-73-R One Ground Station (TBC) shall be used for communications with the spacecraft during the extended operational phase.

SY-74-R During the extended operational phase there shall be no nominal or contingency activities that will require a ground response time of less than 1 week (TBC).

4.3.5.7 Post-Operational Phase

SY-75-R On-board resources shall be provided for configuring the spacecraft into a safe state at the end of life.

SY-76-R The capability shall be provided to completely deactivate the spacecraft at the end of life.

SY-77-R One Ground Station shall be used for communications with the spacecraft during the post-operational phase.

SY-78-R During the post-operational phase there shall be no nominal or contingency activities that will require a ground response time of less than 24 hours (TBC).

SY-79-R The post-operational phase shall have a maximum duration of 2 days (TBC).

4.3.5.8 De-Orbiting Phase

SY-80-R The mission concept shall include a de-orbiting phase, to be defined by the Contractor.

4.4 Environment Requirements

4.4.1 GENERAL SY-81-R The PROBA 3 spacecraft shall be designed to operate under the

environmental conditions as defined in chapter 4.4 "Environmental Requirements" for the full duration of the mission.

4.4.2 GROUND ENVIRONMENT SY-82-R The PROBA 3 spacecraft shall be designed to survive the environment

and handling during assembly, integration, testing and transport up to

PROBA 3 / SRD


the Launch site as per AD 37 or AD 38 and per the applicable Launcher ICD.

SY-83-R The PROBA 3 spacecraft shall be designed to limit the effect of internal and external contamination of its sensitive units to a level which guarantees the required performance during on-ground and in-orbit operations.

4.4.3 LAUNCH ENVIRONMENT SY-84-R The PROBA 3 spacecraft shall be compatible with the launcher ground

operations (including contamination, RF environment and EMC) during the launch campaign as per the corresponding launcher User Manuals.

SY-85-R The PROBA 3 spacecraft shall be designed to survive the environment during launch as defined by the applicable User Manuals of the baseline and backup launchers.

4.4.4 SPACE ENVIRONMENT SY-86-R The Satellite design shall be compatible with the in-orbit environment

as defined in AD 4.

SY-87-R The worst case spacecraft launch date w.r.t. the solar activity cycle shall be considered for the derivation of the in-orbit environment, in particular for the radiation dose.

4.4.5 MECHANICAL ENVIRONMENT SY-88-R The spacecraft shall be designed to withstand all mechanical loads

encountered during its entire lifetime, including manufacturing, handling, transportation, testing, launch and in-orbit operations

4.4.6 THERMAL ENVIRONMENT SY-89-R The spacecraft design shall take into account the thermally relevant

environments encountered during the entire mission.

SY-90-D Per AD 9, the mission includes:

a. Integration, transportation, storage and testing

b. Preparation at the launch site

c. Pre-launch phase when the spacecraft is under the fairing

PROBA 3 / SRD


d. Ascent phase

e. In-orbit operations from launcher separation until end of mission

SY-91-R For units having a view factor to external space, the following solar, albedo and terrestrial fluxes of table 4.1 shall be considered.

Solar Constant (W/m²) Albedo Coefficient (-) Earth Temperature (K)

min max min max min max 1320 1420 0.2 0.4 245 265

Table 4.1

4.4.7 CLEANLINESS/CONTAMINATION SY-92-R The spacecraft shall be integrated, tested, stored and transported in a

clean environment of Class 100,000 as defined in AD 28 Annex F minimum.

4.4.8 ELECTROMAGNETIC CLEANLINESS SY-93-R Shielding shall be used to control EMC with the environment and for

RFC purposes as provided by the basic space vehicle structure designed as a “Faraday cage”, by enclosures of electronics boxes, or by cable or bundle overshields.

SY-94-R The spacecraft design shall aim for magnetic cleanliness when implementing internal design such harness twisting, routing of currents to avoid current loops.

SY-95-R Spacecraft design and materials shall be selected and operated such as to ensure that the following voltages and electric fields due to charging are not exceeded:

-1000V maximum differential voltage in normal gradient

+100V maximum differential voltage in inverse gradient

10^7 V/m maximum electric field within dielectrics

SY-96-R Transmitter interfaces bandwidth shall not exceed the useful signal bandwidth to be transmitted through.

PROBA 3 / SRD


4.4.9 RADIATION

4.4.9.1 General

SY-97-R In performing the radiation analyses the Contractor shall use the nominal mission scenario and take into account data from the PROBA 3 Environmental Specification AD 34.

SY-98-R A list of all external surfaces (e.g., thermal blankets, thermal paints, windows, etc.) shall be maintained and it shall be demonstrated that any degradation of properties due to radiation dose over the 2 years mission is acceptable from a performance point of view.

SY-99-R The AD 5 shall be used as a guideline.

4.4.9.2 Radiation Dose

SY-100-R Both ionising dose effects and non-ionising dose effects shall be taken into account.

4.4.9.3 Radiation Induced Background

SY-101-D Radiation impinging onto a detector or its associated electronics can produce an increase in noise, which in turn can produce a significant decrease of performance. Such changes can last until well after the radiation dose has stopped (remittances).

4.4.9.4 Single Events Effects

SY-102-R The PROBA 3 spacecraft shall be designed to withstand cosmic rays

and heavy ion impacts, which can provoke Single Event Effects (SEE) (i.e., Single Event Upset (SEU), Single Event Latch-up (SEL) or Single Event Transient (SET)) in devices.

SY-103-D Single event effects (SEE) occurrence during in-orbit operational life will be dimensioned through the cosmic rays integral flux versus Linear Energy Transfer (LET) values and Solar proton energy spectra, as given in AD 34..

PROBA 3 / SRD


SY-104-R SEE rates for a given component shall be derived from the relevant tested LET threshold associated with the component as well as proton testing (TBC).

SY-105-R Electronic components applied in the spacecraft shall either be immune to destructive SEE or the operation condition shall be selected such that the device is immune to such effects.

SY-106-D Destructive SEE can e.g. be SEGR, SEB and SEL.

SY-107-R Components shall be considered immune to destructive SEE effects when the LET threshold is above 60 MeV-cm2/mg (TBC)

SY-108-R Electronic components applied in the spacecraft shall either be immune to non-destructive SEE or provisions shall be made in the design for protection against interuption in on-going operations, unacceptable degradation or failure effects.

SY-109-D Non-destructive SEE can e.g be SEU and SET.

SY-110-R Components shall be considered immune to non-destructive SEE effects when the LET threshold is above 40 MeV-cm2/mg (TBC)

SY-111-R Protection against SEE shall include error detection, transient filters and correction schemes. (TBC)

SY-112-R Any device used as memory (EDAC, registers, ASICs, etc.) for which the correct functioning is critical to mission objectives, mission life or spacecraft safety, shall have protection against SEE effects. (TBC)

SY-113-R The rate of un-correctable errors in spacecraft memories shall be better than 1E-11 (error/bit/day). (TBC)

SY-114-R All spacecraft processor semiconductor memories and registers shall implement Single Error Correction and Double Error Detection (SECDED) for each smallest addressable unit in memory. (tbc)

SY-115-R The processor design (on board computer, mission critical eq) shall ensure that the processor internal registers are refreshed at a rate sufficient to avoid cumulation of deposited charges leading to errors. (tbc)

SY-116-R The AD 5 shall be used as a guideline for assessment of SEE in different components types.

PROBA 3 / SRD


4.4.9.5 Internal Charging

SY-117-R Internal charging and subsequent discharge effects shall be considered

in the spacecraft design.

SY-118-R In determining the charging the worst case environment as given in AD 34 or chapter 4.4.8 herein shall be used.

SY-119-R The RD 2 shall be used as a guideline.

5 FORMATION FLYING REQUIREMENTS

5.1 General Formation Flying GNC Requirements FF-1-R Each spacecraft shall embark a long distance, omni-directional, coarse

metrology system (LCM).

FF-2-R The spacecraft shall embark a high accuracy metrology (HAM) system.

FF-3-R All spacecraft metrology subsystems shall have individual metrology-fixed refernce coordinate frames.

FF-4-R All metrology reference coordinate frames shall be specified with respect to the relevant spacecraft GFF.

FF-5-R The PROBA 3 design shall allow to test on board the various levels of metrology systems, the Coarse Metrology (LCM) and the High Accuracy Metrology (HAM).

FF-6-R All metrology systems shall provide an output data of better than 1 Hz and with a datation accuracy better than 1 ms (TBC) with respect to GPS time for the duration of the orbit.

FF-7-R Raw measurement and processed navigation data shall be available from all metrology systems, for off-line evaluation purposes.

FF-8-R The Inter-Satellite Link (ISL) shall provide a sufficient performance in terms of high data rates and low data latencies such that either spacecraft can command the other in closed-loop control in nominal configuration, while still meeting the required formation flying performances.

FF-9-R The GNC system design shall insure that each transition from one metrology sensor to the next more accurate sensor is robust to

PROBA 3 / SRD


maximum expected sensor errors, maximum expected variations in system dynamics, and maximum expected measurement latencies.

FF-10-R The maximum permissible error in relative position, angle (where applicable), relative position rate and angular rate (where applicable) required to initialise each metrology sensor shall be specified as better than TBD.

FF-11-R The GNC system design shall allow the mode transitions between the LCM sensors and the HAM sensors to be tested, in a reliable and repeatable manner.

FF-12-R The GNC system design shall allow on board testing of the robustness of each level of metrology, with respect to the attitude of the satellites and with respect to the relative velocity of the two satellites, both for acquisition and for nominal use.

FF-13-R The two spacecraft shall never reach a state (i.e. relative positions and velocities) from which it is impossible to recover the formation with less than 10% (TBC) of the total mission delta-V, in less than 1 day.

FF-14-R The formation break and build shall be optimised during perigee pass in order to minimize the induced ΔV and propellant consumption.

FF-15-R A 6-DoF collision avoidance system shall be active at all times during the mission.

FF-16-R The formation control system shall be capable of autonomously detecting and rectifying anomalies in the formation positioning and spacecraft attitude which might lead to degradation of performance or loss of mission (TBC).

FF-17-G As a goal requirement the detection from FF-16-R above shall be done wherever possible using a separate, independent set of sensors to those used for the nominal control.

FF-18-R The formation control system shall allow testing of all the on board autonomous mode transitions, with several input conditions, including simulated failure cases.

FF-19-R It shall be possible to correlate the formation measurements with absolute and relative GPS measurements, when available.

FF-20-R Absolute GPS (complemented by orbital propagation) shall provide absolute navigation (PVT) for each satellite in the formation in order to support/check the coarse metrology acquisition and the anti-collision functionality.

PROBA 3 / SRD


FF-21-R Relative GPS (carrier phase) shall be available for FF coarse metrology performance validation.

FF-22-R The mounted GPS receiver shall have a performance accuracy compatible with the orbit determination requirements of the mission.

FF-23-R The GNC system shall be able to incorporate on-board relative GPS data and station tracking data, when available, into the relative metrology calculations.

FF-24-R The mounted GPS receiver shall have a performance accuracy compatible with the relative metrology requirements of the mission.

FF-25-R To demonstrate the FF performances, a FF budget shall be provided, which includes relative position, attitude and rates budgets.

FF-26-R Each contributor to the position, attitude and rate error shall be determined by test, analysis or a combination of both.

FF-27-R The following contributors shall be at least included in each budget:

Sensor performances

Control performances

Actuator performances

Imperfect knowledge of the spacecraft characteristics (e.g. inertia) and calibration errors

Spacecraft internal disturbances (e.g. wheel noise)

Coupling

Structure contribution (e.g. alignment, thermo-elastic)

Navigation performances

FF-28-R The methodology used to derive the FF budget, and the format of this

budget shall be shall be based on AD 35 and agreed with ESA.

FF-29-R The Formation Flying experiments shall be executed with FDIR enabled.

FF-30-R No criticalities shall be induced during FF experiments that could require ground intervention within the specified response time.

PROBA 3 / SRD


5.2 Formation Flying Performance Requirements FF-31-G The goal HPAP lateral position knowledge error shall be less than

0.17mm at a nominal ISD of 35m, and less than 0.73mm at a nominal ISD of 150m (95% confidence).

FF-32-N Note:The requirement FF-31-G above can be met using post-processing.

FF-33-G The goal HPAP longitudinal position knowledge error shall be less than 0.3mm (95% confidence).


FF-35-N Note: The two goal requirements from above are taken from RD 1, the XEUS RDME (Relative Displacement Measurement Error). Meeting this requirement will help to pre-validate XEUS required technologies.

FF-36-G The goal HPAP lateral position error shall be less than 1mm at a nominal ISD of 35m, and less than 4.29mm at a nominal ISD of 150m (95% confidence).

FF-37-N Note: The goal requirement from above is taken from RD 1, the XEUS RDE (Relative Displacement Error). Meeting this requirement will help to pre-validate XEUS required technologies.

FF-38-G The goal HPAP longitudinal position error shall be less than 3mm (95% confidence).

FF-39-N Note: The goal requirement from above is taken from RD 3.

FF-40-R The HPAP requirements shall be demonstrated and verified at 35m and at 150m.

FF-41-G The goal HPAP AAME for F2S shall be less than 1 arc-second across the target direction vector, and less than 1 arc-minute about the target direction vector (95% confidence).


FF-43-G The goal HPAP AAE for F2S shall be less than 1 arc-minute across the target direction vector, and less than 10 arc-minutes about the target direction vector (95% confidence).

PROBA 3 / SRD


FF-44-G The goal HPAP AAME for FCS shall be less than 10 arc-seconds across the target direction vector, and less than 10 arc-minutes about the target direction vector (95% confidence).


FF-46-G The goal HPAP AAE for FCS shall be less than 1 arc-minute across the target direction vector, and less than 1° about the target direction vector (95% confidence).

FF-47-N Note: This requirement is taken from RD 1, the XEUS AAE (Absolute Attitude Error) and AAME (Absolute Attitude Measurement Error). Meeting this requirement will help to pre-validate XEUS required technologies.

FF-48-R The HPAP lateral RDMS for F2S shall be less than 0.29mm over the HPAP specified stability time interval (see requirement FF-51-G below) (95% confidence).

FF-49-R The HPAP AAMS for F2S shall be less than 1.5 arc-sec over the HPAP specified stability time interval (see requirement FF-51-G below) (95% confidence).

FF-50-R The HPAP lateral metrology stability for F2S shall be less than 100μm over the HPAP specified stability time interval (see requirement FF-51-G below) (95% confidence).

FF-51-G The goal HPAP specified stabilty time interval shall be 84 hours (TBC), assuming an L2 Halo orbit.

FF-52-R The minimum HPAP specified stabilty time interval shall be 4 hours (TBC).

FF-53-R The HPM velocity error shall be less than 0.3 mm/s (95% confidence).

FF-54-R The HPM lateral and longitudinal displacement errors shall be less than 5mm (95% confidence).

FF-55-R The HPM attitude and attitude rate errors for both spacecraft shall be maintained such that the HAM system can perform nominally, without a break in measurements.

5.3 Formation Flying Manoeuvre Requirements

PROBA 3 / SRD


FF-56-R For each FF manoeuvre, the manoeuvre shall take less than 1 orbit to complete.

FF-57-R For each FF manoeuvre, the time-dependent profile of the target direction vector and nominal ISD shall be specified.

FF-58-R For each FF manoeuvre described as a loose formation manoeuvre, the time taken to perform the manoeuvre shall be minimised.

FF-59-R A set of Formation Coarse Acquisition Manoeuvres shall be specified, that are representative of the potential distribution of starting satellite positions, attitudes and rates, up to a maximum separation distance of 100km(TBC).

FF-60-R The set defined in FF-59-R above shall be chosen such that successful demonstrations shall validate the formation acquisition system.

FF-61-R At least one of the specified Formation Coarse Acquisition Manoeuvres shall be based on the LCM sensors only.

FF-62-R At least one of the specified Formation Coarse Acquisition Manoeuvres shall be performed autonomously, using inter-satellite communications.

FF-63-R The set of Formation Coarse Acquisition Manoeuvres shall be successfully demonstrated in orbit.

FF-64-R All involved subsystems of the two spacecraft shall be sized to allow at least 5 (TBC) formation coarse acquisition manoeuvres per year following a collision avoidance event, with a maximum ISD of 10km (TBC) at perigee at the start of each manoeuvre.

FF-65-R A Formation Fine Acquisition manoeuvre shall be successfully demonstrated in orbit.

FF-66-R A Formation Station Keeping Test (decentralised) manoeuvre with an FST unbroken period of at least 1 hour shall be successfully demonstrated in orbit.

FF-67-R A Formation Station Keeping Test (centralised) manoeuvre with an FST unbroken period of at least 1 hour shall be successfully demonstrated in orbit.

FF-68-R A Formation Resizing Close (decentralised loose) manoeuvre with an FST unbroken period of at least 30 minutes at a nominal ISD of 25m (TBC) shall be successfully demonstrated in orbit.

PROBA 3 / SRD


FF-69-R A Formation Resizing Close (decentralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes at a nominal ISD of 25m (TBC) shall be successfully demonstrated in orbit.

FF-70-R A Formation Resizing Close (centralised loose) manoeuvre with an FST unbroken period of at least 30 minutes at a nominal ISD of 25m (TBC) shall be successfully demonstrated in orbit.

FF-71-R A Formation Resizing Close (centralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes at a nominal ISD of 25m (TBC) shall be successfully demonstrated in orbit.

FF-72-R A Formation Resizing Close (centralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes at a nominal ISD of 25m (TBC), and with SC-B generating the centralised commands, shall be successfully demonstrated in orbit.

FF-73-R A Formation Resizing Far (decentralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes at a nominal ISD of 250m (TBC) shall be successfully demonstrated in orbit.

FF-74-R A Formation Retargeting (decentralised loose) manoeuvre with an FST unbroken period of at least 30 minutes, and with the target vector at 30° from the original, shall be successfully demonstrated in orbit.

FF-75-R A Formation Retargeting (decentralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes, and with the target vector at 30° from the original, shall be successfully demonstrated in orbit.

FF-76-R A Formation Retargeting (centralised loose) manoeuvre with an FST unbroken period of at least 30 minutes, and with the target vector at 30° from the original, shall be successfully demonstrated in orbit.

FF-77-R A Formation Retargeting (centralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes, and with the target vector at 30° from the original, shall be successfully demonstrated in orbit.

FF-78-R A Formation Retargeting (centralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes, with the target vector at 30° from the original, and using only thrusters for both translation and rotation (i.e. no reaction wheels used throughout) shall be successfully demonstrated in orbit.

FF-79-R A Formation Retargeting (centralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes, the target vector at 30° from the original, and with SC-B generating the centralised commands, shall be successfully demonstrated in orbit.

PROBA 3 / SRD


FF-80-R A Formation Resize and Retargeting (decentralised loose) manoeuvre with an FST unbroken period of at least 30 minutes, at a nominal ISD of 25m (TBC) and with the target vector at 30° from the original, shall be successfully demonstrated in orbit.

FF-81-R A Formation Resize and Retargeting (decentralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes, at a nominal ISD of 25m (TBC) and with the target vector at 30° from the original, shall be successfully demonstrated in orbit.

FF-82-R A Formation Resize and Retargeting (centralised loose) manoeuvre with an FST unbroken period of at least 30 minutes, at a nominal ISD of 25m (TBC) and with the target vector at 30° from the original, shall be successfully demonstrated in orbit.

FF-83-R A Formation Resize and Retargeting (centralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes, at a nominal ISD of 25m (TBC) and with the target vector at 30° from the original, shall be successfully demonstrated in orbit.

FF-84-R A Formation Resize and Retargeting (centralised rigid) manoeuvre with an FST unbroken period of at least 30 minutes, at a nominal ISD of 25m (TBC), with the target vector at 30° from the original, and with SC-B generating the centralised commands, shall be successfully demonstrated in orbit.

FF-85-R A set of Collision Avoidance Test Manoeuvres shall be specified that will validate the collision avoidance system.

FF-86-R At least one specified manoeuvre shall be based on the LCM sensors only.

FF-87-R The Collision Avoidance Test Manoeuvres shall be successfully demonstrated in orbit.

5.4 Technology Requirements

5.4.1 TECHNOLOGY VALIDATION REQUIREMENTS FF-88-R A set of Metrology Test Manoeuvres shall be specified, that shall

validate the domain of utilisation and the performances of the LCM system and HAM system.

FF-89-R The Metrology Test Manoeuvres shall be successfully demonstrated in orbit.

PROBA 3 / SRD


FF-90-R All traits and characteristics without flight heritage of all onboard GNC actuators and sensors that can be tested or characterised in orbit shall be listed.

FF-91-R A set of GNC Sensor & Actuator Characterisation manoeuvres shall be specified that will individually test and characterise each of the traits listed in FF-90-R above.

FF-92-R The GNC Sensor & Actuator Characterisation manoeuvres shall be successfully demonstrated in orbit.

5.4.2 FF METROLOGY REQUIREMENTS

5.4.2.1 Coarse Metrology Requirements

FF-93-R The LCM system shall allow each spacecraft to locate the other, without knowledge/ constraints of the attitude of either spacecraft.

FF-94-R The LCM system shall provide each spacecraft with the other spacecraft’s relative 3D position, measured in an LCM-fixed LCM-centred reference coordinate frame, and expressed as range, elevation and azimuth, range rate, elevation and azimuth rates, and time synchronisation between on-board clocks.

FF-95-R The LCM system shall also provide the other spacecraft’s relative 3D position and velocity expressed in Cartesian coordinates, relative to the same LCM-fixed LCM-centred reference coordinate frame.

FF-96-R The LCM system shall allow each spacecraft to locate the other within the following boundaries:

Range: 10 m to 100 km (TBC);

Range Rate: up to +/-10 m/s

Field of View (FoV): 360 deg / 4π steradian complete coverage

Angular Rate: up to +/-5 deg/s in each axis

FF-97-R The LCM system performance shall meet the following “initial accuracies” (99.7 % confidence) under the LCM boundaries:

Range: +/- 1 m

Elevation and Azimuth: +/-45 de;

PROBA 3 / SRD


FF-98-R The LCM system shall acquire and fix relative navigation between S/C in the formation, meeting the “initial accuracies”, in less than 5 min (TBC) after the swith-on of the LCM units.

FF-99-R The LCM system performance shall meet the following “final accuracies” (99.7 % confidence) under the “nominal formation conditions" (see definition):

Range: +/- 60 mm (TBC)

Range Rate (modulus): 3 mm/s

Elevation and Azimuth: +/-1.75 deg

Elevation Rate and Azimuth Rate (modulus): 0.3 deg/s

FF-100-R The LCM system shall acquire and fix relative navigation between S/C in the formation, meeting the “final accuracies”, in less than 80 min (TBC) after the swith-on of the LCM units.

FF-101-R The LCM system shall provide measurements regardless of orbital position or eclipse status.

FF-102-R The LCM system shall enable time synchronisation between the two spacecrafs to accuracy better than 0.1 ms

FF-103-R The LCM system shall provide offset computation between spacecraft on-board clocks with an accuracy better than TBD ns.

FF-104-R Relative positions and attitudes where no intra-SC metrology information is available shall be fully defined and minimised, i.e. reduced below a minimum to be agreed with the Agency.

FF-105-R The Formation Flying management system shall insure that the situations / configurations addressed in FF-104-R above are avoided, i.e. reduced below a minimum to be agreed with the Agency.

5.4.2.2 Fine Metrology Requirements

FF-106-R The HAM system shall allow high accuracy formation control in nominal formation conditions, with spacecraft separations ranging from 25m to 250m.

FF-107-R The HAM system shall provide measurements regardless of orbital position or eclipse status.

PROBA 3 / SRD


FF-108-R The HAM system shall provide data at 10Hz.

FF-109-R The HAM system shall be used to achieve both HPAP and HPM requirements.

FF-110-R In the reference coordinate frame of the lowest-accuracy HAM metrology system, HAM shall be operational if the lateral offset of HAM sensor part #1 on one of the spacecraft wrt to HAM sensor part #2 on the other spacecraft is below 5˚ and the relative lateral speed is below 0.5˚/sec.

FF-111-R In the reference coordinate frame of the highest-accuracy HAM metrology, the HAM shall provide the lateral offset of the relevant HAM sensor on one of the spacecraft wrt the relevant HAM sensor part on the other spacecraft with an accuracy of ≤32 µm.

FF-112-R In the reference coordinate frame of the highest-accuracy HAM metrology, the HAM shall unambiguously provide the longitudinal distance between the relevant HAM sensor part on one of the spacecraft wrt to the relevant HAM sensor part on the other spacecraft within a range of +/-75 mm to an accuracy of <100 µm

FF-113-R Relative target distance shall be provided in the full separation range with an accuracy of <100 µm.

FF-114-R The longitudinal HAM shall be operational if the relative longitudinal speed between the satellites is below 50 mm/sec.

FF-115-R The lateral HAM shall be operational if the relative llateral speed between the satellites is below 5 mm/sec.

5.4.3 FF PROPULSION REQUIREMENTS FF-116-R An on-board propulsion system shall be implemented on both PROBA-

3 spacecraft.

FF-117-R The propulsion systems shall provide sufficient magnitude and accuracy in forces and torques to meet the FF manoeuvre and attitude control requirements.

FF-118-R A demonstration propulsion system shall be implemented with the ability to perform demonstration of micro-Newton FF in at least one longitudinal axis.

PROBA 3 / SRD


5.5 RV Experiment Induced Requirements FF-119-R The PROBA3 mission shall include a Rendez-vous (RV) experiment.

FF-120-R A single period of operation of the RV experiment shall be at least 3 complete and continuous orbits.

FF-121-R The PROBA3 mission shall include at least TBC periods of operation of the RV experiment.

FF-122-R The number of periods of operation shall be TBD and agreed between the mission prime and the RV experiment PI.

FF-123-R During each period of operation, the RV experiment shall have highest priority (with the exception of spacecraft FDIR), i.e.shall have full authority to operate both spacecraft in an autonomous and independent manner.

FF-124-R The PROBA3 mission shall include a vision-based sensor, mounted on one of the spacecraft.

FF-125-R The vision based sensor from FF-124-R above shall be capable of detecting TBD active light spots mounted on the other spacecraft at a distance of at least 5000m (TBC).

FF-126-R The number and arrangement of the active light spot pattern shall be TBD and agreed between the mission prime and the RV experiment PI.

FF-127-R The GNC algorithms associated with the RV experiment shall be able to interface with the GNC algorithms used for formation flying, such that individual GNC formation flying algorithms can be executed as function calls from the RV experiment.

FF-128-R The GNC algorithms associated with the RV experiment shall be able to receive telemetry from GNC sensors and actuators, and shall be able to command the propulsion systems on both spacecraft for position and attitude control purposes.

5.6 FDIR Requirements FF-129-R In the case that an anomaly is detected during a FF experiment or the

experiment terminates in an unexpected way, the spacecraft shall acquire a safe configuration prior to perigee passage entry.

FF-130-R The FF experiment timeline shall reflect the requirement FF-129-R above.

PROBA 3 / SRD


5.7 Scientific Mission Induced Requirements FF-131-R The PROBA 3 design shall comply with the Formation Flying

requirements derived from the scientific mission as expressed in § 6.

FF-132-R The PROBA 3 design shall allow to test defined Formation Flying experiments during the science mode (i.e fine formation flying experiment) as far as the science objectives are met (i.e no manoeuvres).

6 CORONAGRAPH MISSION REQUIREMENTS CO-1-N Note: This paragraph deals with the Formation Flying and spacecraft

requirements induced by the Coronagraph Mission requirements. It does not deal with the scientific requirements that the Coronagraph instrument shall fulfill.

6.1 General CO-2-R The Occultor S/C shall ensure a nominal occultation of the entrance

pupil of the Coronagraph instrument with respect to the Sun disc.

CO-3-R The formation shall maintain the entrance pupil of the Coronagraph instrument centered in the shadow of the external occultor with performances as specified in chapter 6.2

CO-4-R The Occultor S/C shall have a disc with a diameter covering the apparent Sun diameter at a distance of 150m, that complies with θ0 in requirement CO-8-R from below.

CO-5-R The intersatellte distance shall be adjustable following the seasons by ground command.

CO-6-R As to demonstrate Coronagraph performance, a FF budget shall pe provided, which includes position, attitude and rate budgets.

CO-7-R For the Coronagraph FF budget the methodology used to derive the budget and the format of this budget shall be based on AD 35 and agreed with ESA.

6.2 Requirements on Formation Flying

PROBA 3 / SRD


CO-8-R To meet the coronagraph requirements, the FF system shall maintain the relative position of instrument and occulting disk such that the apparent radius of the occulting disc shall be nominally θ0 = 1.015 Rsun, no less than θmin = 1.01 Rsun and no greater than θmax = 1.02 Rsun. This requirement shall be met with a confidence 99.73%.

CO-9-R To meet the coronagraph requirements, the FF system shall be able to hold formation such that the lateral and longitudinal errors fall within the envelope shown in figure 1 below, whose boundary is defined by the equation:

( )( )

( ) LDDDLISDLISDD

000

min00

min00

-1-/tantan

tan-tan

===

θθθθ

CO-10-D In the equation from above D0 is the maximum lateral error with no

longitudinal error, L0 the corresponding maximum longitudinal error with no lateral error, ISD the nominal separation between the instrument aperture and the centre of the occulting disc, and L and D define the boundary of lateral and longitudinal errors respectively (see figure 1). θ0 and θmin are respectively the nominal and minimum apparent radius of the occulting disc, given in requirement CO-8-R from above.

CO-11-R The requirement CO-9-R from above shall be met with a confidence of 99.73% (i.e. of the time).

CO-12-N Note: the exact values are dependent on the nominal separation of the two S/C, ISD, which varies slightly throughout the year. For a given separation it is possible to give more specific lateral and longitudinal position requirements.

x

y

D0

L0

D L

Figure 1: The volume (symmetric about x-axis) in which the ADE must lie

PROBA 3 / SRD


CO-13-R In order to fulfill the science requirements, the Coronagraph S/C shall

meet the following pointing requirements:

The APE between the Coronagraph instrument boresight and the centre of the Sun shall be less than 8 arc-seconds TBC (95% confidence).

The APE of the error about the Coronagraph instrument boresight shall be less than 0.5º TBC (95% confidence).

Over a 10 second interval, the RPE of the angle between the Coronagraph instrument boresight and the centre of the sun shall be less than 2.5 arc-seconds TBC (95% confidence).

Over a 10 second interval, the RPE of the error about the Coronagraph instrument boresight shall be less than 1 arc-minute TBC (95% confidence).

CO-14-R To meet science requirements, the Occulter S/C (i.e. housing the occulter disc) shall meet the following pointing requirements:

The APE of the angle between the symmetry axis of the occulting disk and the centre of the Sun shall be less than 0.5º TBC (95% confidence).

The APE of the error angle about the symmetry axis of the occulting disk shall be less than 0.5º TBC (95% confidence).

6.3 Constraints induced by Sun pointing CO-15-R The Coronagraph instrument shall be operated under condition that all

bright sources (Earth, Moon, but except the Sun) are out of a half cone angle of 35° (TBC) around the optical axis of the instrument (TBC).

CO-16-R The evolution of the apogee with relation to the Sun over the year shall be taken into account in the definition of measurement requiements for the Coronagraph instrument.

CO-17-R Any optical metrologies and star trackers shall be optimised for the Coronagraph instrument’s operation in terms of their accommodation on the spacecraft.

CO-18-R The requiement CO-17-R from above shall be demonstrated by analysis.

PROBA 3 / SRD


6.4 Constraints induced by orbit parameters CO-19-R Scientific observation phases shall last several hours continuously

(minimum 2 hours TBC) and provide a minimum of 6 hours per day (TBC) of Coronagraph observation on the days where the Coronagraph experiment is scheduled.

CO-20-G A total of 12 (TBC) hours per day of Coronagraph observation shall be considered as a goal requirement on the days where the Coronagraph experiment is scheduled..

6.5 Coronagraph design and accommodation requirements CO-21-R The Occulter S/C side looking to the Coronagraph S/C (i.e. the

Occulter disk) shall be coated as black as possible, with black paint or black MLI minimizing straylight.

CO-22-R The BRDF value shall be TBD

CO-23-G As a goal requirement the Occulter S/C design shall be such than no protusions exceed the Occulter disk as seen from the Coronagraph instrument.

CO-24-R The rim geometry of the Occultor disk shall be TBD

CO-25-R An additional Sun sensor shall be accommodated on the Sun side of the Occulter S/C (TBC).

CO-26-R The mass of the Sun sensor shall be TBD kg.

CO-27-R The volume allocation for the Sun sensor shall be :

Height = 200mm (TBC) (direction of the Sun),

Length = 150mm (TBC),

Width = 100mm (TBC)

CO-28-R The power allocation for the Sun Sensor shall be : 1 W (TBC)

CO-29-R 17 Gbits / day (TBC) shall be foreseen onboard the Coronagraph S/C for the scientific payload’s needs.

CO-30-N Note: The requirement CO-29-R from above corresponds to a 6 hours Sun observation sequence per day.

PROBA 3 / SRD


CO-31-R A Shadow Position Sensor (SPS) shall be used to verify that the Coronagraph instrument’s entrance pupil is centered within the shadow cone of the occulting disc.

CO-32-R An Occulter Position Sensor (OPSE) shall be used to check the accuracy of the Formation Flying by providing information on the position of the Occulter S/C in the field of view of the Coronagraph S/C.

CO-33-R In order to implement requirement CO-32-R from above, four (TBC) LEDs shall be accommodated on the Coronagraph-facing side of the Occulter S/C.

CO-34-R When switched ON, the LEDs shall provide information on the position of the occulter disk in the field of view of the Coronagraph instrument.

CO-35-N Note: By comparing the position of the barycentre of the LED images with the reference pixel, the Coronagraph instrument will be able to estimate the accuracy of positioning of the occulter disk w.r.t. the optical axis of the Coronagraph instrument.

CO-36-R The accommodation of an Absolute Radiometer and Sun Sensor (ARaSS) shall be foreseen.

CO-37-N The ARaSS will be used to measure the visible irradiance of the solar disk and to provide independent/additional information on the Sun pointing of the Occulter spacecraft.

CO-38-R The Coronagraph S/C shall have a mass allocation for the Coronagraph instrument of 35 kg (TBC).

CO-39-R The volume accommodation for the Coronagraph instrument shall be:

Length : 1000mm (TBC),

Width : 800mm (TBC),

Height : 300mm (TBC).

CO-40-R The Coronagraph S/C shall have a power allocation for the Coronagraph instrument of 35 W (TBC) in operating mode and 4 W TBC) in non-operating mode.

CO-41-R The Coronagraph instrument shall be thermally decoupled from the S/C platform.

CO-42-R Data provided by the Coronagraph instrument detector shall be compressed without loss, stored in the S/C mass memory and then transmitted to ground, in real time or after the observation phase.

PROBA 3 / SRD


7 SPACE SEGMENT REQUIREMENTS

7.1 Spacecraft Functional and Design Requirements

7.1.1 GENERAL REQUIREMENTS

7.1.1.1 Satellite Lifetime

SS-1-R The two spacecraft shall be designed for 2 years of operational lifetime, i.e. after separation from the launcher.

SS-2-R The satellite consumables (propellants, solar array power, SSMM(s)) shall be dimensioned for 2 years lifetime from separation from the launcher with margins as defined in chapter 7.1.1.8.

SS-3-R The two spacecraft shall be designed and sized to support daily Formation Flying operations during the Nominal Operational Phase.

SS-4-R The two spacecraft shall be designed and sized to support daily Coronograph instrument data acquisition as defined in chapter 6 during at least 50% of the Nominal Operational Phase and with a minimum sequence of 7 consecutive days of Sun observation.

7.1.1.2 Autonomy

SS-5-R It shall be possible to program the satellites for fully autonomous operations not requiring commanding by the Ground Segment for at least a period of 7 days.

SS-6-R It shall be possible to override any on-board automated activity from the ground.

SS-7-R During LEOP critical phases (e.g. separation, deployments, etc.), the satellites shall be able to operate nominally during a ground outage period of at least two hours (TBC).

SS-8-R During LEOP, outside critical phases, the two spacecraft shall be able to operate nominally during a ground outage of at least 40 hours (TBC).

SS-9-R During LEOP, outside critical phases, the two spacecraft shall be safe following the occurrence of one failure and without ground intervention for at least two hours (TBC).

PROBA 3 / SRD


SS-10-R An unambiguous indication shall be provided in the telemetry every time an autonomous intervention takes place on-board to permit the ground to reconstruct every related action that has been executed on-board, both at sub-system and system level.

SS-11-R The information from SS-10-R above shall be stored on-board for interrogation by the ground, and shall remain in memory (including failures) until reset by the ground.

SS-12-R The operational modes of the two spacecraft and their payloads, subsystems and units shall be clearly identified in terms of both hardware and software.

7.1.1.3 Safe Mode

SS-13-R In case of an autonomously unrecoverable major failure threatening the health of either of the two satellites, the satellite shall be autonomously switched over to a Safe Mode in which the satellite will only require minimal resources.

SS-14-R The satellite Safe Mode shall guarantee onboard command and control, ground communications, power and energy management, minimum of attitude control and safe thermal control.

SS-15-G A goal requirement for the satellite Safe Mode shall be to have it provided by hardware or software functions not involved in the other modes of operations.

SS-16-R The Safe Mode shall bring/keep the spacecraft into a stable formation mode which minimizes fuel consumption.

SS-17-R The spacecraft condition shall remain stable in Safe Mode for unlimited duration waiting ready to receive ground commands.

SS-18-R The two satellites shall have the necessary on-board resources to sustain at least one acquisition and recovery from Safe Mode every month (TBC).

SS-19-R The Safe Mode shall guarantee TM/TC communications between the ground and the satellite to:

Downlink all the information necessary to ground operators to understand the failure events and to identify the involved hardware/software making efficient usage of the (reduced) downlink bandwidth

PROBA 3 / SRD


Uplink commands to be executed by the satellite for upgrading the configuration and returning to nominal modes

SS-20-R Transition to Safe Mode shall not endanger the satellite or any of its elements, irrespective of the moment at which Safe Mode is invoked.

SS-21-R It shall be possible to enter Safe Mode also by ground command.

SS-22-R The Safe Mode software shall permit to download the nominal software image for investigation and to patch or upload a new full software version.

SS-23-R No satellite nominal operation shall require inhibition of the Safe Mode, nor a forced entry into Safe Mode.

SS-24-R Mode changes from Safe Mode to another satellite mode shall be commanded from the ground either in real time, via the on-board queue or using OBCPs.

SS-25-R In case either of the two spacecraft enters the satellite Safe Mode the system shall guarantee collision avoidance, evaporation avoidance and maintain the formation in a predefined safe state

7.1.1.4 Fault Management

SS-26-R Either of the two spacecraft shall automatically detect, isolate, recover and report any fault, failure, and/or error that cause deviation from its nominal configuration and operational mode or that may adversely affect the mission.

SS-27-N Note: The requirement SS-26-R above includes hardware and software failures.

SS-28-R Coronagraph instrument failures shall not lead to a Safe Mode of the satellite.

SS-29-R The fault management functions at all levels shall be able to access lower level telemetry data produced by the sub-systems.

SS-30-N Note: The requirement SS-29-R above includes in particular non-periodic event packets that can be used to trigger recovery actions at system or sub-system levels as a result of an anomaly occurred (and detected) in another sub-system.

SS-31-R A predefined set of fault management functions at specific FDIR levels shall carry out consistency verification checks on independent or

PROBA 3 / SRD


redundant sensor readings whenever available before starting the recovery actions.

7.1.1.5 FDIR

SS-32-R The FDIR (Failure Detection Isolation and Recovery) shall be capable of dealing with all mission modes, from launcher separation, composite stack operation, separation of satellites (and any kick stages) through the nominal operations and end-of-life disposal.

SS-33-R FDIR shall be performed autonomously within the satellites in a hierarchical manner with the aim of isolating and recovering faults at unit, subsystems or instrument level as far as necessary to preserve the satellite health and operability.

SS-34-R The FDIR parameters shall be fully configurable by ground command and be available in telemetry on request.

.SS-35-G As a goal requirement all systems used for fault management within FDIR shall be intrinsically fail safe.

7.1.1.6 Fault Tolerance

SS-36-R Protected switching configurations employing separate “arm” and “active” operations shall be implemented whenever an unintended activation can lead to an operational hazard.

SS-37-R It shall not be possible to disable/inhibit a protection feature that in case of a single failure at S/C level could lead to the loss of the main primary power bus.

7.1.1.7 Redundancy

SS-38-R All authorised combinations of prime and redundant equipment shall exhibit the same operational characteristics.

SS-39-R For each on-board function, there shall be at least one alternative configuration that can achieve the same function using different on-board units.

SS-40-R It shall be possible to read GNC primary and redundant sensor data separately and simultaneously.

PROBA 3 / SRD


SS-41-R Hot redundancy shall be provided for functions that would lead to critical and/or catastrophic consequences in case of failure.

SS-42-R It shall be possible by Ground command to reverse the switching to a redundant unit provided that such switching capability cannot result in an irreversible undesirable configuration.

SS-43-R Checkout of all redundant or contingency operational modes or units shall be possible during ground testing of the fully integrated spacecraft.

7.1.1.8 Margin Policy

7.1.1.8.1 Mass Margin

SS-44-R At equipment level, the following design maturity mass margins shall be applied:

5% for OTS equipment (ECSS category A & B);

10% for OTS items requiring minor modifications (ECSS category C);

20% for new designed/developed items, or items requiring major modifications or re-design (ECSS category D).

SS-45-R At end of phase B (i.e. at System PDR), the total mass of the spacecraft shall include a system level margin of at least 10% of the nominal mass at launch.

SS-46-R In the phase C/D (i.e. at System CDR), the total mass of the spacecraft shall include a system level margin of at least 5% of the nominal mass at launch.

7.1.1.8.2 On-Board Propulsion Margins

SS-47-R The following margins shall be added to the deltaV calculations:

Formation deployment (incl. orbit injection and correction): 20%

Commissioning: 20%

Routine Operations (incl. wheel off-loading): 20%

Critical Operations: 20%

Mission Core Experiments: 20%

PROBA 3 / SRD


Other Experiments: 5%

SS-48-R In addition to the deltaV margins from requirement SS-47-R above, an additional margin of 5% shall be applied on propellant mass calculations and a margin of 20% for pressurant mass calculation

7.1.1.8.3 Launcher Margins

7.1.1.8.3.1 Delta-V Margins

SS-49-R In case a Propulsion Module is used to raise the orbit of the Launch Composite, a 1% margin on top of the impulsive Delta-V of the PM shall be considered in order to take into account gravity losses.

SS-50-R In case a Propulsion Module is used to raise the orbit of the Launch Composite, a TBD constant margin shall take into account the Delta-V needed to compensate for atmospheric drag, PM test burn and launcher dispersions.

SS-51-R In case a Propulsion Module is used to raise the orbit of the Launch Composite, a Delta-V margin of 2% on top of the Delta-V previously defined in requirements SS-49-R and SS-50-R from above shall be added.

7.1.1.8.3.2 Mass Margins

SS-52-R For the computations of launcher performances a 10% margin on top of the Satellite Stack (OS+CS+adapters) wet mass shall be considered.

SS-53-R For the computations of launcher performances and in case a Propulsion Module is used to raise the orbit of the Launch Composite, a 10% margin on top of the Propulsion Module dry mass shall be considered.

SS-54-R For the computations of launcher performances and in case a Propulsion Module is used to raise the orbit of the Launch Composite, a 0% (TBC) margin for the Propulsion Module propellant mass shall be considered.

7.1.1.8.4 Electrical Power Margin

SS-55-R At equipment level and for conventional units, the following design maturity power margins shall be applied:

5% for OTS equipment (ECSS category A/B);

PROBA 3 / SRD


10% for OTS items requiring minor modifications (ECSS category C;

20% for new designed/developed items, or items requiring major modifications or re-design (ECSS category D).

SS-56-R The electrical power resources shall be dimensioned with margin providing power up to the end of mission as defined in AD 6.

SS-57-R An electrical sub-system margin of no less than 5% at Flight Acceptance Review (FAR) on available power and energy shall be included in the budgets, available (as a minimum) with one solar array string failed and one battery cell failed during all the designed life of the power system including all spacecraft modes of operation.

7.1.1.8.5 Data Processing Margins

SS-58-R Requirements in this section shall be computed with worst-case scenarios to be agreed with ESA (at latest for the System PDR).

SS-59-R Margins to be applied for the size of RAMs, EEPROMs, and PROMs, shall be:

25 % at FAR.

SS-60-R Margins to be applied for the load of data busses (1553, OBDH or others) loads shall be:

25 % at FAR.

SS-61-R Margins to be applied for the processing load of all CPUs shall be:

25 % at System FAR.

7.1.1.8.6 Communication Margins

SS-62-R Link budgets and associated margins, for all phases of the mission, shall be computed with at least the following margins:

nominal margin: 3 dB;

RSS worst-case margin: 0 dB;

mean − 3σ margin: 0 dB.

7.1.1.8.7 Radiation Margins

PROBA 3 / SRD


SS-63-R The PROBA-3 satellites and their components shall be designed to withstand twice the expected levels of predicted radiation.

7.1.2 ARCHITECTURE AND CONFIGURATION

7.1.2.1 Space Segment

SS-64-R The PROBA-3 Space Segment (SSEG) shall consist of a Coronagraph Spacecraft (CS) and an Occulter Spacecraft (OS).

SS-65-R The space segment design shall be compatible with an operational one day HEO orbit with ground contact with the Redu ground station larger than 14 (TBC) hours a day.

7.1.2.2 Launch Composite

SS-66-R The PROBA-3 Launch Composite (LC) shall consist of a Coronagraph Spacecraft (CS), an Occulter Spacecraft (OS) and a Propulsion Module (PM), the latter TBC.

SS-67-N Note: The Propulsion Module from requirement SS-66-R above is needed only in the case the launcher cannot deliver the satellite stack (OS,CS) into the final operational orbit

SS-68-R The PM, CS and OS satellite structures shall maintain the necessary alignment between all satellite elements during ground and in-orbit operations.

SS-69-R Each component of the launch composite ( PM, CS, OS) shall provide hoisting and handling points.

SS-70-R In addition, hoisting / handling points for the satellite stack shall be provided.

SS-71-R In addition, hoisting / handling points for the launch composite shall be provided.

SS-72-R In the launch configuration the lighter S/C shall be placed on top of the heavier S/C.

PROBA 3 / SRD


7.1.2.3 Satellite Stack

SS-73-G As a goal requirement the satellite stack (OS, CS) total wet mass at launch shall not exceed 550 kg (TBC) in case of the Vega launch, including the adapter between the two spacecraft but excluding the launch vehicle adapter.

7.1.2.4 Coronagraph Spacecraft (CS)

SS-74-R The main functions of the Coronagraph Spacecraft shall be:

To operate as one of two spacecraft performing Formation Flying demonstrations

To accommodate the technology required to perform Formation Flying demonstrations

To accommodate the Coronagraph instrument

To interface to, provide power and control the Propulsion Module (in case the PM is needed)

To interface to and support the Occulter Spacecraft

7.1.2.5 Occulter Spacecraft (OS)

SS-75-R The main functions of the Occulter Spacecraft shall be:

To operate as one of two spacecraft performing Formation Flying demonstrations

To accommodate the technology required to perform Formation Flying demonstrations

To accommodate the occulting disc and the Absolute Radiometer and Sun Sensor (ARaSS)

To interface to the Coronagraph Spacecraft

PROBA 3 / SRD


7.1.2.6 Propulsion Module (PM)

SS-76-R The main function of the PM shall be to contain a separate Chemical Propulsion System (CPS) that shall be used to transfer the satellite stack from the launch orbit to the operational orbit.

7.1.2.7 Launcher Interface

SS-77-R The launch composite interface to the launcher shall be based on Vega User Manual AD 37.

SS-78-R The Satellite Stack interface to the launcher shall be also compatible with a backup launcher, as per its respective User’s ManualAD 38.

7.1.2.8 Propulsion Module Interface (only LPM case)

SS-79-N Note: For the baseline Vega launcher the injection into the final orbit may be performed by the Lisa Pathfinder Propulsion Module (LPM). In this case the following interface requirements apply.

SS-80-R The PROBA-3 Spacecraft, Ground Support Equipments and operations shall comply with the Lisa Pathfinder Propulsion Module Mechanical Interface Requirements as specified in AD 39.

SS-81-R The PROBA-3 Spacecraft, Ground Support Equipments and operations shall comply with the LISA Pathfinder Propulsion Module Harness Electrical Interface Requirements as specified in AD 40.

SS-82-R The PROBA-3 Spacecraft, Ground Support Equipments and operations shall comply with the LISA Pathfinder Propulsion Module Thermal Interface Requirements as specified in AD 41.

SS-83-R In case the LPM is baselined, the PROBA 3 satellites budgets shall implement the necessary ressources allocation (mass, power, CPU load) in order to command and control the LISA Pathfinder Module as specified in LPM User Manual AD 42.

7.1.3 STRUCTURE AND MECHANISMS REQUIREMENTS

7.1.3.1 General Requirements

SS-84-R The following ECSS documents shall apply:

PROBA 3 / SRD


AD 10

AD 11

AD 13

AD 16

AD 15

AD 17 AD 27

AD 30

AD 37 VEGA User’s Manual

AD 38 TBD Backup Launcher User’s Manual

7.1.3.2 Structure Definitions and Functions

SS-85-R The structure shall carry all the element of the spacecraft including the instruments and the technological experiments during integration, launch and in orbit.

SS-86-R The structure shall maintain the prescribed relative alignment with the required stability between the optical instruments and sensors during ground and in-orbit operations.

SS-87-R The structure configurations shall ensure unobstructed field of view for the payload (for observation and calibration purposes) and the communication and navigation antennae.

SS-88-R The mechanical design and layout shall provide sufficient accessibility to allow easy integration, removal and maintenance activities of all secondary structures, equipment and the payload.

SS-89-R Items requiring integration or adjustment at the launch site (for safety, logistic or life reasons) shall be accessible without removing any equipment or instrument.

SS-90-R The mechanical design shall allow removal and maintenance of all secondary structures, equipment and the payload.

SS-91-R The mechanical design shall provide access to connectors.

PROBA 3 / SRD


SS-92-R The structure shall be designed to be compatible, in volume and response to the environment with the specification of the pre-selected backup launcher.

7.1.3.3 Damage Tolerance

SS-93-R Damage tolerance design principles, e.g. fail-safe design (redundancy) of attachment points, or safe-life design and damage tolerant materials, shall be applied, as specified in AD 10 , § 4.3.7.

SS-94-R Where a single-point failure mode is identified and redundancy can not be provided, the required strength and lifetime (safe-life design) shall be demonstrated.

SS-95-R Interfaces within the primary structure, between primary and secondary structures, and to all units above 0.5 kg shall be fail-safe. In particular any bolted interface holding more than 0.5 kg shall survive with any bolt missing with safety factors for ultimate and yield equal to 1.

7.1.3.4 Strength

SS-96-R Satellites design shall ensure the survival of the structure under the

worst feasible combination of mechanical and thermal loads for the complete lifetime of the satellite.

SS-97-R The lifetime shall include: manufacturing, assembly, testing, transport, launch and in-orbit operations.

SS-98-R The structural design of the satellite shall pass successfully the qualification static, sine vibration, random vibration, acoustic and shock tests required by the Launcher Authority.

SS-99-R The satellite shall pass successfully the acceptance static, sine vibration, random vibration, acoustic and shock tests required by Launcher Authority.

SS-100-R The following failure modes, for the Launch Composite (PM, CS, OS), the Satellite Stack (CS, OS) each satellite and all equipment at all levels of integration, shall be prevented:

Permanent deformation,

PROBA 3 / SRD


Rupture,

Instability and buckling,

Gapping of bolted joints

Degradation of bonded joints,

Vibration induced mounting interface slip,

Loss of alignment of equipment and payloads subject to alignment stability requirements,

Excessive strains or stresses impairing mechanisms operation, release, or deployment,

Distortion violating any specified envelope,

Distortion causing functional failure or short circuit.

SS-101-R Fasteners shall be classified and analysed as any other structural item.

SS-102-R Fasteners smaller than diameter 5 mm shall not be used in safe life applications.

SS-103-R For fasteners equal to or larger than diameter 5 mm, the following requirements apply:

Titanium alloy fasteners shall not be used in safe life applications.

All potential fracture-critical fasteners shall be procured and tested according to aerospace standards or specifications with equivalent requirements.

All safe life fasteners shall be marked and stored separately following NDI or proof testing.

SS-104-R No yielding is allowed at proof load/proof pressure.

SS-105-R On-orbit loads from the PM thrust vector or any similar sources shall be derived and considered for appendages (eg Solar Panel) which may be deployed during such manoeuvre.

PROBA 3 / SRD


7.1.3.5 Factors

SS-106-R Load multipliers specified by the launcher design authority (e.g. development factor, uncertainty factor, acceptance factor, qualification factor, test factor) shall apply in addition to the design safety factors.

SS-107-R Margins of safety (MOS) shall be calculated by the following formula:

1 - )_(

_load)(allowable MoSxFOSloadapplied

=

where:

allowable load: allowable load under specified functional conditions (e.g. yield, buckling, ultimate)

applied load: computed or measured load under defined load condition (design loads)

FOS: Factor of safety applicable to the specified functional conditions including the specified load conditions (e.g. yield, ultimate, buckling)

SS-108-R All margins of safety (MOS) shall be positive.

SS-109-R The relationship between Loads and factors shall be the following:

SS-110-R The mechanical part of the LL shall be derived from the launcher

manual (e.g. quasi static loads, minimum requested test loads) either directly or indirectly (via analysis, e.g. frequency response). The LL shall also be derived from the expected ground handling and transportation loads.

SS-111-R The project factor KP shall account for possible mass increase at the start of the satellite design.

PROBA 3 / SRD


SS-112-R The model factor KM shall account for the uncertainty at the start of the satellite design with respect to mathematical model used to establish the design.

SS-113-R The qualification load QL to be considered at the beginning of the programme shall, as a minimum, be equal to the DL loads.

SS-114-R Qualification loads QL and acceptance loads AL shall be as a minimum:

KQ× LL final for qualification

KA× LL final for acceptance

where LL final is the best knowledge of the LL as resulting from the LCDA (or an envelope thereof) approved by the launcher authorities.

SS-115-R The loads or factors relationship from SS-114-R above shall apply to the quasi static and dynamic loads for general design, dimensioning and testing.

SS-116-R The following factors shall be used:

KM = 1.00 Maximum Predicted Mass shall be taken into account (including system level margin)

KP = 1.25 prior to verification of the structural dynamic model of the satellite by dynamic testing

KP = 1.00 after verification of the structural dynamic model of the satellite by dynamic testing

FOSD = 1.25

FOSY = 1.1

FOSU = 1.5

KQ = 1.25

KA = 1.1

SS-117-N Note: These factors assume the use of classical materials for which A values allowables are available from recognized standards/organisation.

PROBA 3 / SRD


SS-118-R In case such A values are not available, the contractor shall define an appropriate safety factor which shall then be approved by the Agency.

SS-119-R The minimum factors of safety for bolted joints slip and gapping shall be 1.1 and 1.25 respectively [TBC].

SS-120-R Minimum factors of safety against ultimate shall be:

Pressure vessels 1.5

Lines and fittings smaller than 38 mm diameter 4.0

Lines and fittings 38 mm diameter or greater 2.0

Valves, filters, regulators, other pressurised components 2.5

SS-121-R For combined loads where L(P) is the load due to maximum expected operating pressure and L(M) is the non-pressure limit load, the factored, ultimate load case shall be: 1.5 L(M) + 1.5 L(P)

SS-122-R For load cases involving thermal and/or moisture de-sorption loads, the thermal/moisture de-sorption stress at the applicable temperature shall be factored by 1.5 to determine the equivalent ultimate thermal/ moisture de-sorption load and this shall be added to 1.5 times the non-pressure load and/or the pressure load.

SS-123-R Where pressure and/or temperature and/or moisture de-sorption relieves the non-pressure load a Factor of Safety of 1.0 shall be used for the pressure and/or thermal and/or moisture de-sorption loads. In this case the pressure load shall be based on the minimum operating pressure.

SS-124-R The satellite Structural Thermal Model (if part of the model philosophy) shall be able to survive 4 times all mechanical qualification tests.

SS-125-R The satellite Flight Model shall be able to survive 4 times all mechanical acceptance tests plus one launch.

SS-126-R A scatter factor of 4 shall be used in the fatigue analysis.

7.1.3.6 Notching

SS-127-R Primary notching, i.e. notching to keep the accelerations of the centre

of mass of PROBA-3 at the design loads, is allowed provided the stiffness requirement is met.

PROBA 3 / SRD


SS-128-R Secondary notching (ie, to protect units / instruments), or notching below the CoG acceleration is generally not allowed unless approved by the Agency.

7.1.3.7 Stiffness

SS-129-R The lowest frequencies and the effective masses of the Launch

Composite (i.e. PM, CS, OS) in launch configuration, hard mounted to the launch vehicle interface shall be in accordance with the Vega User’s Manual.

SS-130-R The structural design of the Launch Composite shall provide a minimum margin of +15% over the specified frequencies before verification of the satellite dynamic properties by test.

SS-131-R The lowest frequencies and the effective masses of the stack CS and OS in launch configuration, hard mounted to the PM shall be sufficient to decouple the dynamical behaviour of the Launch Composite (PM, CS and OS) frequency plus a minimum of 15% margin.

SS-132-R To optimize the structural mass, the half power point rule (=1.4 times the lowest eigen frequency of the PM) instead of the one octave rule (=2 times the lowest eigen frequency) shall be considered.

SS-133-R The on-orbit stiffness requirement of the individual CS and OS any deployed appendages shall be greater then 8Hz (TBC).

SS-134-R The stiffness of the spacecraft in-orbit configuration shall preclude the interaction of the spacecraft flexible modes with the attitude control system.

SS-135-R The structural design of equipment shall prevent the dynamic coupling of equipment with the spacecraft structural modes.

SS-136-R As a general rule the resonance frequency of compact equipment and boxes in hard mounted condition shall be above 140 Hz.

SS-137-R Whenever the requirement SS-136-R from above cannot be met, equipment shall be designed to withstand the effects specific to the dynamic amplification caused by the coupling with the spacecraft.

PROBA 3 / SRD


7.1.3.8 Fracture

SS-138-R Fracture control principles shall be applied where structural failure can

result in a catastrophic or critical hazard.

SS-139-R A reduced fracture control program shall be implemented as per AD 16, chapter 11.

SS-140-R Structure shall be designed with a level of redundancy to be agreed with the Agency to ensure that the failure of one structural element does not cause general failure of the entire structure with catastrophic consequences (e.g. loss of launcher, endangerment of human life)

SS-141-R A NDI after manufacturing (forging, machining and thermal treatment) shall be performed by the launcher interface ring supplier as well as the I/F ring supplier between the potential Propulsion Module / CS and CS/OS.

7.1.3.9 Mechanisms

SS-142-R All mechanisms shall demonstrate conformance to requirements of AD 11.

SS-143-R The mechanism engineering shall consider every phase of the mission and conform to the related mission requirements and environmental constraints.

SS-144-R The mechanism shall provide structural support to an equipment or payload unit of the spacecraft and shall change its relative position with respect to the spacecraft in a predictable manner.

SS-145-R The kinematic requirements applicable to each position change shall be substantiated; mechanical interface, position accuracy or velocity tolerances shall be specified and demonstrated to conform to the functional needs.

SS-146-R The envelopes within which each moving part is allowed to move shall be defined.

SS-147-R Loads shall be derived according to requirements specified in the chapter 7.1.3.5 above.

SS-148-R The following specific factors of safety shall apply in the calculation of the margin of safety for the following components:

PROBA 3 / SRD


cables, stress FOS against rupture: 3.0

stops, shaft shoulders and recesses, FOS against yield: 2.0.

SS-149-R Loads induced by the mechanism operation shall be added to the in-orbit loads.

SS-150-R Motors shall withstand their stalling torque for a period of time of at least 24 hours under the maximum predicted operating voltage and under the predicted worst case flight thermal environment without degradation.

SS-151-R The mechanisms shall not require any periodic maintenance for their entire ground storage period.

SS-152-N Note: It is acceptable that mechanisms need to be de-tensioned during a long period of storage.

SS-153-R Activations of mechanisms after a period of storage shall be performed to verify the functional performances.

SS-154-R Unless redundancy is achieved by the provision of a complete redundant mechanism, active elements of mechanisms as sensors, motor windings (and brushes where applicable), actuators, switches and electronics shall be redundant.

SS-155-R For thermal design requiring installation of thermal insulations onto or close to moving parts, it shall be demonstrated by test that clearance with adequate margin, agreed by ESA, are ensured and maintained throughout the mission.

SS-156-R Full deployment status of one-shot drivable mechanisms shall be telemetered.

SS-157-R Mechanisms (except the "single shot" type) shall be designed so that they cannot be driven into a nonrecoverable condition.

SS-158-R The status of mechanisms that are locked during launch shall be available during the pre-launch phase.

SS-159-R The capability shall be provided to monitor the various stages of a motorised deployment process.

SS-160-R Mechanisms that make use of pyrotechnics shall be designed to provide easy access to EED's when integrated with the spacecraft for their installation and possible replacement.

PROBA 3 / SRD


7.1.3.10 Pyrotechnics

SS-161-R Pyrotechnics application and design shall be as per AD 13 and approved by ESA.

SS-162-R All pyrotechnics shall be initiated via a dedicated module which is mechanically segregated, electrically independent and screened, and thermally decoupled from the rest of the unit that houses it.

SS-163-R The module from SS-162-R above shall incorporate the safety inhibits.

SS-164-R It shall be possible to test the functionality of the unit initiating the pyrotechnic devices without activating the devices.

SS-165-R Use of pyrotechnic devices shall be compatible with the cleanliness requirements of the spacecraft.

7.1.3.11 Mechanical Parts

SS-166-R Mechanical parts selection shall be in accordance with the following space standard:

AD 27

7.1.3.12 Materials

SS-167-R The selection of a material shall be in accordance with the following space standards:

AD 15

AD 27

AD 29

SS-168-R Metallic structural products shall be selected from preferred lists of alloys with high resistance to stress corrosion cracking, as indicated in Table 1 of AD 29.

7.1.3.13 Alignment Stability

SS-169-R The structure alignment of the CS and OS shall be maintained considering the following factors:

PROBA 3 / SRD


Moisture distortion

Thermo-elastic effect

1g to 0g effect

Micro-vibration

7.1.4 THERMAL CONTROL REQUIREMENTS

7.1.4.1 General

SS-170-R The spacecraft shall comply with the definitions and requirements given in AD 9 with the additions and modifications listed hereunder.

7.1.4.2 Definitions

SS-171-D Design Temperature Range – is the temperature range (operating, non-operating, switch-on) against which the thermal control shall be designed.

SS-172-D Acceptance Temperature Range – is the temperature range (operating, non-operating, switch-on) at which a unit of qualified design is tested for demonstration of its flightworthiness.

SS-173-D Qualification Temperature Range – is the temperature range (operating, non-operating, switch-on) at which a unit is tested for qualification of its design.

7.1.4.3 Operability

SS-174-R The Thermal Control System (TCS) shall operate nominally throughout the mission lifetime.

SS-175-R It shall be possible for all parameters used for active thermal control, including fault management, to be updated by ground command and be available in telemetry on request.

7.1.4.4 Functional

PROBA 3 / SRD


SS-176-R All unit Temperature Reference Points (TRPs) shall be defined and equipped with a flight temperature sensor.

SS-177-R The TCS shall provide sufficient temperature sensors for in-flight monitoring of unit TRPs.

SS-178-R Heaters used for temperature control shall be protected against failure by redundancy of the complete chain.

7.1.4.5 Thermal Performance

SS-179-R It shall be possible to demonstrate conformance of the design to thermal performance requirements by thermal analyses and thermal tests.

SS-180-R The performance of the thermal control shall be defined in terms of:

Temperature

Temperature stability

Temperature gradients

Interface fluxes

Heater power

7.1.4.6 Thermal Design

SS-181-R The design shall allow temperature trimming after the thermal balance tests.

SS-182-R The TCS must be testable on ground, i.e. no TCS item shall prevent the spacecraft from being operated/tested under an attitude required by the thermal environment test.

SS-183-R The design shall cope with the space environment defined in chapter 4.4.6.

SS-184-R The design shall permit analysis by mathematical models.

SS-185-R The dimensioning of the Thermal Control shall cover worst-case scenarios derived from every mission phase up to the end of the operating lifetime, and worst combination of expected physical properties and operative conditions incl. safe modes.

PROBA 3 / SRD


SS-186-R Materials with non-stable thermo-optical properties shall be justified and provided with their ageing law.

SS-187-R The spacecraft MLI shall be vented such as to comply with depressurisation requirements.

7.1.4.7 Verification

7.1.4.7.1 Analysis

SS-188-R The TRPs temperature and temperature stability shall be predicted.

SS-189-R A Coupled Thermal Mathematical Model (CTMM) of the spacecraft in its launch configuration shall be derived from and correlated with the Detailed Thermal Mathematical Model (DTMM).

SS-190-R The format of this model shall be agreed with the Launcher Authority if not specified in Launcher Interface Control Document (TBC).

SS-191-R All TRPs shall be associated with a node number in any spacecraft TMM.

SS-192-R An uncertainty analysis shall be done at the beginning of the PROBA-3 Phase C/D and re-assessed after the satellite thermal balance tests.

SS-193-R A set of failure cases shall be simulated to demonstrate compliance with single failure tolerance requirement.

7.1.4.7.2 Software

SS-194-R The software ESARAD and ESATAN shall be used for the system thermal analyses.

7.1.4.7.3 Test

SS-195-R All TRPs shall equipped with a temperature sensor during the system thermal tests.

7.1.5 ONBOARD PROPULSION REQUIREMENTS

7.1.5.1 Terms, Definitions, Abbreviations and Symbols

SS-196-R Chapter 3 of AD 12 shall apply.

PROBA 3 / SRD



SS-197-R Chapter 4 of AD 12 shall apply.

SS-198-R Chapter 5 of AD 12 shall apply for chemical propulsion systems (incl. cold gas systems).

SS-199-R Chapter 6 of AD 12 shall apply for electric propulsion systems.

7.1.5.3 Functional Requirements

SS-200-R The propulsion systems shall provide actuation forces and torques necessary for:

Six degree of freedom attitude control during science mode operations and the defined formation flying manoeuvres;

Reaction wheel off-loading;

Perigee pass manoeuvres, including formation break and re-acquisition;

Safe mode manoeuvres;

Coarse re-acquisition after a CAM.

SS-201-R The propulsion system shall provide telemetry data sufficient to perform:

Routine monitoring of system operating parameters and performance;

Failure detection and isolation;

Switch-over to redundant resources.

SS-202-R The arrangement of thrusters in the on-board propulsion systems shall allow application of thrusts to provide pure forces and torques in the six degrees of freedom.

SS-203-R The propulsion system shall provide an in-orbit propellant gauging capability, able to determine the remaining propellant mass to an accuracy of better than 10%.

SS-204-R Electric propulsion systems shall include means to neutralise any charge build up associated with operation of the systems.

PROBA 3 / SRD


7.1.5.4 Performance Requirements

SS-205-R The detailed performance requirements on the propulsion systems shall be derived from the mission and system performance requirements associated with the relevant propulsion system functions.

SS-206-R The propulsion systems shall be capable of meeting the mission delta V requirement.

SS-207-R The performance of the propulsion systems shall be defined in terms of:

Thrust range;

Thrust resolution, accuracy and repeatability (incl. minimum impulse bit);

Trust vector stability;

Thrust noise;

Specific impulse;

Specific power.

SS-208-R The performance requirements shall be met throughout the mission lifetime.

7.1.5.5 Operational Requirements

SS-209-R The operation of the propulsion systems shall not result in the degradation or loss of function of any other spacecraft system.

SS-210-R The propulsion systems shall operate nominally throughout the mission operational lifetime.

SS-211-R It shall be possible to operate thrusters in any combination, compatible with the available power level, as necessary to meet the mission requirements.

SS-212-R During operation the propulsion systems shall provide telemetry for health and performance monitoring, including:

Tank and operating branch pressures;

Equipment temperatures;

PROBA 3 / SRD


Equipment electrical parameters.

SS-213-R The operation of the propulsion systems shall be performed according to defined operating modes, to meet the mission operational requirements, including:

Off mode (where all electrical equipments are powered off and all fluidic components in the closed position);

Standby mode (where electrical units are powered on but fluidic components are in the closed position);

Nominal mode (where all units are operating nominally under command of the GNC system).

7.1.5.6 Design Requirements

SS-214-R The thruster directions and locations shall be selected to minimise plume impingement on the spacecraft and contamination of sensitive equipments.

SS-215-R Propulsion systems required to achieve mission success and core criteria shall be single point failure tolerant.

SS-216-R Propulsion systems required only to achieve other criteria (e.g. a demonstration propulsion system) need not be single point failure tolerant.

SS-217-R Fluidic control valve design shall ensure that the valve stays closed in case of failure.

SS-218-R Closed volumes within the fluidic systems shall be designed to avoid the risk of overpressure due to temperature increases.

SS-219-R Inadvertent thruster firing and hazardous propellants external leakage on ground shall be prevented by safety inhibits and barriers, in accordance with launch site safety regulations.

SS-220-R A propellant specification shall be established, and the compatibility of the specified propellant with the selected design and mission requirements shall be demonstrated.

SS-221-R Number and location of fill and drain valves and test ports of propulsion systems shall be compatible with requirements for testing and for loading and unloading of propellants and pressurant gas.

PROBA 3 / SRD


SS-222-R The design of any lifetime-degrading components of system shall be compatible with the operational life.

SS-223-R The layout of the propulsion systems shall ensure symmetric depletion of fuel in all tanks during thruster firing to minimise the shift of spacecraft centre of gravity during the mission.

7.1.5.7 Verification Requirements

SS-224-R Chapter 5.6 of AD 12 shall apply for chemical propulsion systems (incl. cold gas systems).

SS-225-R Chapter 6.7 of AD 12 shall apply for electric propulsion systems.

SS-226-R Verification testing of propulsion systems shall be performed under representative flight conditions (eg. thruster firings shall be performed under vacuum conditions).

SS-227-N Verification of experimental or demonstration propulsion systems, not required for mission success or mission core experiments, need not include the following:

Ageing or Lifetime;

Mutual effects of electrostatic and magnetic fields;

Thruster plume characterisation;

Electrostatic, contamination and erosion analyses;

Gauging analysis;.

7.1.6 ELECTRICAL POWER REQUIREMENTS


SS-228-R The power system of both PROBA 3 spacecraft shall be designed in accordance with AD 6 and AD 8.

SS-229-R The power subsystem shall provide all power required by the spacecraft for the launch ascending phase and all the mission modes through the entire duration of the mission and shall support test, pre-launch and launch activities.

PROBA 3 / SRD


7.1.6.2 Failure Containment and Redundancy

SS-230-R The power system shall autonomously perform mode transition operations of the protection and energy management without support from other spacecraft subsystems.

SS-231-R All automatic H/W and S/W protection features shall be overridable except the hardware based functions as detailed in paragraph 5.3b of AD 6.

SS-232-R The power outlets shall be equipped with protection devices preventing failure propagation from any user to the bus.

SS-233-R Double isolation shall be provided in the primary power subsystem (before power distribution).

SS-234-R No single point failure shall endanger full mission performance or cause permanent damage to any essential load.

SS-235-R An automatic protection shall be provided to ensure that the power subsystem is able to recover from any malfunction in any load or from any abnormal spacecraft mode of operation.

7.1.6.3 Energy Generation

SS-236-R The solar array shall utilize 100 % European triple junction cells with integral shunt diode. The BOL efficiency of the solar cell shall be at least 27% (@ 25°C).

SS-237-R The solar arrays shall provide the power required by the spacecraft in worst-case conditions after the 2 years mission and with one string lost.

SS-238-R In case of two shorts on the same panel, the power loss shall not be more than the power of two strings.

SS-239-R It shall be possible to monitor the current of each solar array section.

SS-240-R The solar aspect angle and flux shall be defined for the sizing case of the solar array.

SS-241-R Requirements for the solar array shall be established for all mission phases (ie. Including test, pre-launch, launch, commissioning etc. as well as normal operation)

SS-242-R A solar array performance prediction analysis shall be performed and shall include all mission phases, considering all effects having an

PROBA 3 / SRD


impact upon performance (e.g. temperature, radiation, contamination, sun intensity, solar aspect angle, UV, micrometeorites, coverglassing, calibration losses, mismatch losses, by-pass and blocking diode losses, all pointing errors including spacecraft attitude and solar array drive related aspects, random failures) and shall be based on accepted cell degradation figures and actual cell performance measurements.

SS-243-R The performance prediction shall include the range of voltage and current in worst case conditions

SS-244-N Note: Ttypically the highest voltage is under maximum illumination in a cold condition at BOL, eg. coming out of eclipse and typically the lowest voltage is under minimum illumination in a hot condition at EOL.

SS-245-N Note: Typically the highest current is under maximum illumination at perpendicular incidence in a hot condition at BOL and typically the lowest current is under minimum illumination at the largest off-set angle of incidence in a cold condition at EOL.

SS-246-R The solar array design margins shall include the assumption of the loss of 1 electrical string, to be accounted in all calculations as a direct loss.

SS-247-N Note: In order to meet the solar array reliability requirements, the impact of other loss factors may lead to the addition of other spare strings.

SS-248-R The solar array shall be designed such that the performance of each string and section allows the efficient use of the selected bus regulation principle during all mission phases.

SS-249-R The solar array design shall provide protection against short circuit of cells to the structure, shadowing due to antennas or appendages and electrical transients, including discharges (e.g. ESD).

SS-250-R For ESD, a maximum value of voltage difference between adjacent cells, correlated to a minimum cell gap, shall be derived and applied to the electrical network.

SS-251-R The solar array design analysis shall evaluate the impacts of the discharge phenomena on the electrical network and shall provide an inventory of the possible electrical transients that the solar array may be submitted to during the mission.

SS-252-R The solar array design shall prevent any failure propagation, including thermo-mechanical and other non-electrical causes.

SS-253-R All solar array strings shall have individual blocking diodes.

PROBA 3 / SRD


SS-254-R Solar cells shall be protected against ‘hot spots’ (ie. any deleterious reverse-bias conditions) by the use of by-pass diodes to protect individual cells or groups of cells.

SS-255-R The photovoltaic assembly layout shall be designed to meet the solar array magnetic moment requirements.

SS-256-R The solar array shall be designed to survive the atomic-oxygen orbit environment without performance degradation (this requirement can be deleted when the final selection of the orbit is done).

SS-257-R The solar array interface voltage shall be TBD V at the harness interface.

SS-258-R All current carrying tracks after blocking diodes shall have double isolation.

SS-259-R The values of solar array section equivalent capacitance and inductance shall be defined in worst case conditions.

SS-260-R The maximum voltage in case of open circuit failure shall be lower than or equal to TBD Volts

SS-261-R Plume impingement effects shall be analysed

SS-262-R In the flight configuration, the following shall be applied:

Avoid electrical continuity of the solar array conductive panels to each other or to the spacecraft structure.

Implement means to prevent voltage difference due to electrostatic charging (e.g. by providing bleeding resistors).

Size bleeding resistors to limit both electrostatic charging and power loss from the solar array section and dissipation in the resistor itself in case of a cell string to panel short (including derating).

SS-263-R A short between a solar cell string and a conductive panel shall not produce any solar array power loss.

SS-264-R Leakage losses of bypass diodes shall be deducted from the power computation if they represent more than 0.1% of the overall power to be provided.

SS-265-R The model used for power computation shall be validated by test on the specific solar cell type used for the mission

PROBA 3 / SRD


SS-266-R EOL I-V curve shall be measured after irradiation with particles (electrons and protons) at dosages equivalent to the mission radiation profile and agreed with the customer.

SS-267-R Fundamental SA frequencies, including hold-down attachment, in hard mounted condition, shall be:

Stowed configuration

fo ≥ 60 Hz (in plane directions)

fo ≥ 50 Hz (out of plane direction)

Deployed configuration

fo ≥ (TBD) Hz (in plane directions)

fo ≥ (TBD) Hz (out of plane direction)

SS-268-R The stiffness of fully deployed solar array shall be such that the effective residual mass and inertia shall be less than 10% for frequencies above 0.5 Hz assuming a rigid interface with the SADM (if applicable).

SS-269-R The Spacecraft shall provide structures for mechanical attachment of the hinges of deployable solar panels to comply with the interface stiffness requirement: TBD N/mm.

SS-270-R For qualification, the function of the deployment mechanism shall be demonstrated in vacuum at the temperature extremes, by test or similarity.

SS-271-N Note: worst case is typically cold at ambient pressure, so a test at the extreme cold temperature in eg. a Nitrogen atmosphere is considered as acceptable.

SS-272-R In order to check torque margin, the following approach shall apply:

in case of a spring mechanism, to disconnect half the springs

in case of a motor mechanism, to reduce the drive current by 50%

SS-273-R The SA release function, including the function of the hold down mechanism shall be demonstrated in vacuum at the temperature extremes.

PROBA 3 / SRD


SS-274-N Note: worst case is typically cold at ambient pressure, so a test at the extreme cold temperature in eg. a Nitrogen atmosphere should be sufficient.

SS-275-R For acceptance each SA wing shall perform full deployment at ambient conditions, as well as flasher test before and after structural and environmental testing.

7.1.6.4 Energy Storage

SS-276-R Peak power and power during eclipse shall be provided to the spacecraft by batteries.

SS-277-R The batteries shall provide the energy required by the spacecraft in worst-case conditions for the entire duration of the mission.

SS-278-R Battery capacity shall be selected to provide compliance to the lifetime requirements in terms of depth of discharge, number of charge cycles and temperature.

SS-279-R Protection against excessive overcharge, undervoltage, overheating or freezing shall be provided.

SS-280-R Two failures shall not cause the complete loss of the energy storage capacity, multiple modules shall be accommodated to maximise the fault tolerance.

SS-281-R The EPS telemetry monitoring shall allow determination of the battery state of charge from ground to an accuracy better than 10%.

SS-282-R For battery technologies where battery performance and/or lifetime is severely impaired by excessive charge or discharge (e.g lithium-ion), provisions shall be made to prevent exceeding of these limits.

SS-283-R The design shall take into account any residual discharge currents due to leakage through connected circuitry.

SS-284-R The batteries and their regulator shall be functionally single failure tolerant.

SS-285-R The back-up system shall be completely independent of on-board computer control.

PROBA 3 / SRD


7.1.6.5 Power Conditioning and Control

SS-286-R The power system shall condition, control, store and protect / distribute electrical power on board of the spacecraft.

SS-287-R The power system shall provide status monitoring and telecommand interfaces necessary to operate the subsystem and permit evaluation of its performance (during ground testing and in-flight operations) and failure detection and recovery.

SS-288-R The power subsystem bus voltage and accuracy shall be selected based on the foreseen needs of the payload in order to optimise the system.

SS-289-R Both performance and cost shall be considered as the main drivers for optimisation.

SS-290-R The power system shall be capable of operating continuously under all operation condition of the mission including contingency situations.

SS-291-R No damage or degradation shall result from intermittent or cycled operation.

SS-292-R The power system shall support the connection of external sources during ground operation.

SS-293-R The EPS shall restart automatically and autonomously after a complete main bus loss when solar array power reappears.

SS-294-R The management of the power bus shall be autonomous and completely independent from any control by the on-board computer.

SS-295-R Essential functions (e.g. synchronisation or auxiliary power supply) shall not rely in centrally generated auxiliary functions.

SS-296-R Any EPS equipment shall be able to operate independently of any external synchronisation or auxiliary power supply.

7.1.6.6 Power Distribution and Protection

SS-297-R Non-switchable power lines shall be available for the vital functions of the spacecraft.

SS-298-R No single point failure within the power subsystem shall cause permanent over voltage, under voltage or short circuit of the power lines.

PROBA 3 / SRD


SS-299-R All DC/DC converters shall be over-voltage protected.

SS-300-R All latching protection devices in the power subsystem shall be re-settable.

SS-301-R All power lines shall be protected against short circuit and over-consumption.

SS-302-R It shall be possible to re-activate the power lines after a protection trip.

SS-303-R A software and autonomous hardware protection mechanism shall be implemented where non-essential loads and essential loads are switched off from the power bus in sequence when the power bus decreases towards a critical battery level.

SS-304-R The minimum level of protection shall be as defined below:

Switch-off:

When reaching 1st critical under voltage level, software switches off non essential loads as necessary,

When reaching the 2nd protection level, autonomous hardware protection switches off the power outlets (individually) for non essential loads,

When reaching 3rd protection level, autonomous hardware protection switches off the power outlets (individually) for essential loads. Switch off levels for essential loads shall guarantee that permanent damage voltage level for the selected battery is not reached.

Switch-on:

When restoring (increasing) bus voltage from the 3rd protection level, the essential loads shall autonomously restart when reaching a voltage level with a definedhysteresis to the switch off level,

When restoring (increasing) bus voltage from 2nd protection level, the non-essential loads shall be OFF, but autonomously be permitted to receive an ON command when reaching a voltage level with a suitable hysteresis to the switch off level.

SS-305-R The power consumption on each distributed line shall be available on board and in the telemetry.

SS-306-R The stability of current limiters shall be addressed taking into account the actual loads characteristic.

PROBA 3 / SRD


SS-307-R Any power line available from the power subsystem shall be protected against short circuit or overload appearing at the user’s side.

SS-308-R The overload and short circuit protection shall be achieved by current limiters provided with trip-off capability.

SS-309-N Note: Use of fuses shall be avoided.

SS-310-R Justification shall be provided in case fuses are used.

SS-311-R In case fuses are used, these shall be accessible and dismountable until the end of the integration.

7.1.6.7 Harness

SS-312-R The harness shall provide defined distribution and separation of all power supply lines, analogue and digital data lines, command and actuation pulse and stimuli lines between all units of the S/C sub-systems and those lines to the payloads/experiments, the test connectors, the safe/arm brackets and connectors and the umbilical connectors.

SS-313-R The harness shall be designed in accordance to AD 6 and AD 20 .

SS-314-R The harness shall transmit all electrical currents in a manner compatible with the requirements of the source and destination unit/interface.

SS-315-R The harness layout shall guarantee the minimum distance of the EMC classes as defined in AD 6 for segregation.

SS-316-R The mechanical construction of the harness shall assure the reliable operation of the spacecraft under all environmental conditions.

SS-317-R The stress, which occurs during manufacturing, integration, test, transport, launch preparation, launch and in-orbit operation shall cause no changes in the harness, which might affect the correct functioning of the system.

SS-318-R No piece of harness shall be used as a mechanical support.

SS-319-R Different connector classes shall be implemented in order to separate the different types of links: Power, Signal and Pyros.

SS-320-R Signal falling into different EMC classifications shall be assembled to separate connectors and cable bundles.

PROBA 3 / SRD


SS-321-R If requirement SS-320-R from above is not practicable, the separation shall be achieved by a row of unused pins and the cable shall split into their respective categories as soon as they leave the connector or connector backshell.

SS-322-R The shields of cables should not be used as return cables

SS-323-R All hot/return lines should be twisted together.

SS-324-R All harness and all box and bracket mounted connectors supplying power shall have socket contacts.

SS-325-R Where it is necessary to have a shield connection through a connector, separate pins shall be used.

SS-326-R The possibility of incorrect mating of connectors shall be avoided by design.

7.1.7 ELECTROMAGNETIC COMPATIBILITY REQUIREMENTS SS-327-R The satellite design shall be compliant with the EMC/RFC requirements

addressed by AD 6, sections 6 and 7.

SS-328-R The spacecraft design shall be compatible with applicable electromagnetic and plasma environments defined in AD 4, including LEOP and transfer up to the operational orbit.

SS-329-R All electric circuits shall be protected against the effects of Electrostatic Discharges as described in AD 31 paragraph .3.2.8.2.

SS-330-R Electromagnetic compatibility of the satellite and its constituent parts including Telemetry, Tracking, Commands and GPS localization devices, shall be ensured by design and verification.

SS-331-R The electromagnetic compatibility from SS-330-R above shall include effects of conducted as well as radiated interferences.

SS-332-R The satellite electrical compatibility with the test facilities and with the launcher and its environment, as specified in the relevant launch vehicle documentation, shall be ensured.

SS-333-R The GSE shall be electrically designed to comply with the spacecraft and the AD 32 on EMC to that necessary extent.

SS-334-R Electrical interface design shall ensure that the characteristics on both sides of each signal interface are compatible. This includes source and load impedances, the effects of the interconnecting harness and the

PROBA 3 / SRD


grounding network between both sides taking into account: common mode impedance, conducted and radiated susceptibility and emission.

7.1.8 COMMAND, CONTROL AND DATA HANDLING REQUIREMENTS

7.1.8.1 Definitions

SS-335-D The Data Handling Subsystem (DHS) is the Space Segment subsystem that provides the necessary commanding, monitoring and control functions required by the PROBA-3 Mission and System.

SS-336-D The DHS distributes to the various Space Segment subsystems, including instruments, the commands and acquires from them data for storage and for later transmission.

SS-337-D The DHS interfaces the Ground Segment through the Communication Subsystem to receive Telecommand and transmit Telemetry.

SS-338-D The DHS also provides the means for formation flying data exchange through the inter spacecraft link of the coarse metrology subsystem.

SS-339-D Unless otherwise specified, the DHS requirements refer to both PROBA-3 spacecraft.


SS-340-R Space and Ground Segment resources shall be sized such that telemetry and auxiliary information can be received on the ground in order to support all activities commanded from the ground within the response times required.

SS-341-R Telemetry data shall be provided, as necessary for all mission phases, for the Ground Segment to determine the status of the spacecraft subsystems, including the Coronagraph or guest payload (if any), in order to monitor the execution of nominal and anticipated contingency situations, including sufficient telemetry to evaluate the performance of the formation flying activities.

SS-342-R The telemetry available during the different mission phases shall be selectable via a number of configurable TM modes – for example, during extended operations phase no FF detailed performance TM will be required, and safe mode shall have a reduced applicable TM set.

PROBA 3 / SRD


SS-343-D In order to fulfil the PROBA-3 DHS definition the following general requirements are derived:

SS-344-R The DHS shall decode, validate and process the Telecommands (TC) received from the Communication subsystem and distribute them to the on-board applications, spacecrafts (part of the formation flying), subsystems and instruments for immediate or deffered execution.

SS-345-R The DHS shall collect the data from the various on-board applications, spacecraft ( part of the formation) subsystems and instruments. The data shall be conditioned, digitized and formatted for on-board utilisation or for Telemetry (TM) transmission to the Communication subsystem.

SS-346-R The DHS shall be in charge of the Space Segment control and monitoring as required for :

the Formation Flying as defined in chapter 5

the Coronagraph instrument as defined in chapter 6.

the on-board autonomy including the FDIR as defined in chapter 7.1.1.

the Ground Segment as defined in chapter 8

SS-347-R The DHS shall maintain a command history and event history log that is available to Ground on request.

7.1.8.3 Spacecraft Control Requirements

SS-348-R The PROBA-3 spacecraft shall provide visibility of its internal status, configuration and performance to the ground in accordance with the level of detail and the time delays specified for all mission phases and specified contingency operations, including subsequent diagnostic activities.

SS-349-R The control functions (telecommands) provided at each level of the PROBA-3 system hierarchy shall be capable of achieving the mission objectives under all specified circumstances.

PROBA 3 / SRD



SS-350-D Derived from the above general requirements the following functional requirements will apply:

SS-351-R The DHS shall perform the following functions:

Telecommand reception, decoding, validation and distribution

Telemetry acquisition, encoding, formatting and transmission

On-board data acquisition and storage

On-board time management and distribution

Spacecraft , Formation Flying and GNC management

Autonomy supervision and management

Failure Detection Isolation and Recovery (FDIR) management

SS-352-R The DHS shall implement the services from the Packet Utilisation Standard AD 25 and as tailored for the PROBA-3 in accordance with the present document.

SS-353-R The DHS TM and TC shall be packet oriented and shall comply with AD 26.

SS-354-R The DHS telemetry shall implement a Telemetry decoder compliant with AD 21 and AD 22.

SS-355-R The DHS Telecommand shall implement a Telecommand encoder compliant with AD 23.

SS-356-R The DHS shall provide a programmable data acquisition function capable to acquire and condition data from any spacecraft unit in digital and analogue form.

SS-357-R The DHS shall provide a data storage capability for Ground and on-board usage.

SS-358-R The data storage shall be used to store at least following data:

Instruments generated data

Storage of DHS software image

Spacecraft housekeeping

PROBA 3 / SRD


SS-359-R The DHS shall provide a time management function that shall generate, maintain and distribute a master clock used as the On-Board Time reference (OBT) for the formation.

SS-360-R The DHS shall provide the computational need compatible with the PROBA-3 mission and capable to execute all on board processing functions for :

TC, TM and Time Management functions handling,

The formation flying capability including GNC

The level of on-board autonomy and FDIR required for the mission

The instruments management.


SS-361-R The DHS data storage shall be dimensioned to be compatible with the Ground Segment coverage and the PROBA-3 operational scenario.

SS-362-R At least 16 Gbit (TBC) of storage data shall be provided by the DHS data storage at the End of Life (EoL).

SS-363-R On-board storage and buffer areas should be resizable to cater for non-nominal mission events.

SS-364-R The On-board operations schedule shall be sized such that it can store all commands/instructions for nominal operations (including one formation flying demonstration) for a week.

SS-365-R The sizing specified in SS-364-R above shall include margin for commanding overheads associated with realistic anomalies and spacecraft aging.

SS-366-R The capability shall be provided to determine at any point in the mission and with TBD accuracy, the remaining on-board resources that impact mission lifetime.

7.1.8.6 Design and Operational Requirements

SS-367-R No single command function executed at the wrong time or in the wrong configuration shall lead to the loss of the mission.

PROBA 3 / SRD


SS-368-R Except for explicitly agreed single point failures, it shall be possible to recover all on-board functions after a single failure within a specific function.

SS-369-R The DHS architecture shall comply with the recommendation of AD 20.

SS-370-R The DHS shall be designed according to AD 6 section 4.1.

SS-371-R The DHS Telemetry encoder design shall allow to separate data in different virtual channels according to:

Idle frames (VC#0)

The real-time generated house-keeping data (VC#1)

The stored house-keeping data (VC#2)

The instruments data

The dumped data (TBC)

SS-372-R Whilst operating in centralised or de-centralised mode, the spacecraft telemetry shall be managed by the master DHS.

SS-373-R Following certain failure conditions, the two spacecraft shall operate as independant spacecraft and shall communicate independantly with the Ground Segment.

SS-374-R The DHS Telemetry encoder shall allow the Ground to change downlink rate and encoding scheme.

SS-375-R The DHS Telecommand decoder shall be considered as an essential function of the Spacecraft as per definition of AD 6, i.e. the DHS Telecommand decoder shall not be switchable and shall be hot redundant.

SS-376-R The DHS Telecommand decoder design shall provide capability of direct ground commanding without onboard software processing.

SS-377-R The DHS shall allow logging of received Telecommand.

SS-378-R The DHS shall allow receiving direct or deferred telecommands. Deferred Telecommands shall be based on OBT, the time resolution and the spacing of differed Telecommand shall be defined and shall be compatible with the PROBA-3 mission.

PROBA 3 / SRD


SS-379-R The DHS shall communicate with on-board equipments and instruments in order to support monitoring and commanding in digital or analogue form.

SS-380-R The DHS shall acquire, time-stamp and condition housekeeping from the various equipments and instruments.

SS-381-R The acquisition rate and conditioning format shall be programmable.

SS-382-R The time-stamp shall be based on OBT.

SS-383-R The DHS data storage shall be accessible by the processor in reading and writing.

SS-384-R The DHS data storage shall be directly accessible in write mode by the PROBA-3 science instrument (Coronagraph) through a dedicated communication channel.

SS-385-R The DHS data storage shall provide a direct read access to DHS Telemetry virtual channels.

SS-386-R The DHS data storage shall allow for simultaneous and independent read and write access.

SS-387-R The DHS data storage system shall allow to allocate specific area for dedicated users.

SS-388-R Each area defined in SS-387-R from above shall be individually written, read or released.

SS-389-R The DHS data storage shall ensure the integrity of the stored data compatible with their utilisation and with telemetry frame rate rejection requirement.

SS-390-R The DHS data storage shall allow expansion of the memory size without impacting interfaces and functionality.

SS-391-R The DHS OBT shall be initialised at spacecraft power up, it shall guaranty monotonicity and shall not wrap-around during the whole mission duration.

SS-392-R The DHS shall allow to synchronise with the OBT the two PROBA-3 spacecraft.

SS-393-R The accuracy of the synchronisation defined in SS-392-R above shall be compatible with the Formation Flying requirements.

PROBA 3 / SRD


SS-394-R The DHS OBT shall allow to correlate the OBT and GPS time when available with an accuracy compatible with the mission requirements.

SS-395-R The DHS OBT shall allow to synchronise the on-board equipments with an accuracy compatible with the mission requirements.

SS-396-R The DHS shall provide the capability to store at least two (2) on-board SW images in non-volatile memory.

SS-397-R The DHS shall allow by direct ground commanding to reset the PROBA-3 spacecraft into known minimum start-up configuration.

SS-398-R The DHS shall be able to process the Coronagraph instrument’s data (TBC).

7.1.8.7 Redundancy

SS-399-R No reconfiguration of the spacecraft shall lead to a configuration where new single point failures are introduced.

SS-400-R On-board functions shall have well-defined inputs and outputs that are accessible from the ground for workaround solutions in the case of contingency operations.

SS-401-R All vital and hazardous functions shall be monitored by at least two independent parameters.

SS-402-R The DHS data storage design shall be redundant or based on mass memory blocks to allow graceful capacity degradation over life allowing fulfilling the mission required memory capacity at end of life.

7.1.8.8 Autonomy, FDIR and Safe Mode

SS-403-R The design of the space segment failure, detection, isolation and recovery (FDIR) function shall be such that all anticipated on-board failures can be overcome either by autonomous on-board action or by clear, unambiguous and timely notification of the problem to the Ground Segment.

SS-404-R Failure detection, isolation and recovery activities performed on-board shall be reported in an unambiguous manner to the Ground Segment

SS-405-R Where FDIR functions are based on several inputs (e.g. sensor readings and unit status), which are independently tested to determine

PROBA 3 / SRD


a failure condition, the capability shall be provided to enable and disable each such input by telecommand.

7.1.8.9 Testability

SS-406-R If a requirement is to be verified by test then the DHS shall provide access to the reference points needed to observe and test conformance to this requirement.

SS-407-R The DHS shall provide a test connector accessible from the Spacecraft skin connector allowing to have access to the full Telemetry and Telecommand.

SS-408-R The accessibility to the connector defined in SS-407-R above shall be possible during the whole system AIV activity including when integrated with the launcher.

SS-409-R The connector defined in SS-407-R above shall allow to test both hot redundant TC chains.

7.1.9 COMMUNICATION SUBSYSTEM REQUIREMENTS

7.1.9.1 Definitions

SS-410-D The Communication Subsystem (COMS) is the Space Segment subsystem responsible for the Radio Rrequency (RF) link with the PROBA-3 Ground Segment.

SS-411-D The Inter Satellite Link (ISL) is the Space Segment subsystem responsible for the Radio Rrequency (RF) link in between the two PROBA 3 spacecraft.

7.1.9.2 General

SS-412-R The COMS shall provide S-Band up and down-link capabilites with the PROBA-3 Ground Segment for each of the Proba-3 spacecraft and shall comply with AD 24.

PROBA 3 / SRD



SS-413-R The telemetry shall be in accordance with the TM Space Data Link Protocol AD 25 without Source Packet Segmentation.

SS-414-R The COMS shall provide omni-directional coverage simultaneous in up- and down-link during all mission phases.

SS-415-R Each COMS antenna shall be used for up and down-link and shall be right hand circular.

SS-416-R The bit rate for telecommand shall be 64 Kbits/s.

SS-417-R The data rate (including coding and frame overheads) for telemetry shall be selectable from 2MSymbols/s down to 256 KSymbols/s by the ground.

SS-418-R The downlink shall use BPSK modulation with suppressed carrier.

SS-419-R The COMS downlink transmitter shall be cold redundant.

SS-420-R The COMS downlink transmitter shall be capable to be turned on or off either by Ground or on-board commanding.

SS-421-R The COMS shall be capable to initiate downlink from Ground or on-board commanding.

SS-422-R The COMS uplink receiver shall be considered as an essential load, i.e. it shall not be switchable and shall be hot redundant.


SS-423-R The link budget calculations shall be performed according to AD 24.

SS-424-R The COMS downlink bit error rate shall be compatible with a frame rejection rate better than 10-7.

SS-425-R The COMS uplink bit error rate shall be better than 10-5.

SS-426-R The COMS shall be compatible with the pre-launch and launch RF environment.

SS-427-R The COMS shall demonstrate full performance in presence of the Coarse Metrology subsystem.

PROBA 3 / SRD


7.1.9.5 Inter Satellite Link

FF- XXX- R Each spacecraft shall embark an omni-coverage Inter Satellite Link (ISL) system.

FF- XXX- R For inter-satellite distances below 1 km:

The ISL data rate shall be better than 100 kbps (TBC), bi-directional data flow and BER<10-7.

The contribution of the ISL system to the GNC navigation latency shall be less than 100 msec (TBC)

FF- XXX- R For inter-satellite distances beyond 1 km:

The ISL data rate shall be better than 10 kbps (TBC), bi-directional data flow and BER<10-7.

The contribution of the ISL system to the GNC navigation latency shall be less than 2 sec (TBC)

FF- XXX- R The ISL system shall enable time synchronisation between the two spacecraft to accuracy better than 0.1 milliseconds.

FF- XXX- R The ISL system shall provide offset computation between spacecraft on-board clocks with an accuracy better than 20 ns (TBC).

7.1.9.6 Verification

SS-428-R The performance of the antenna shall be estimated in the presence of the spacecraft body.

SS-429-R An RF compatibility test shall be performed between the Ground Segment equipments and a represenative model of the COMS.

7.1.10 COMMAND AND CONTROL REQUIREMENTS SS-430-R The PUS services AD 25 listed in the following table shall be

implemented for Proba-3.

SS-431-R Unless marked “not supported” the PUS services shall be mandatory for the spacecraft and their applicability to the coronograph interfaces is as defined in the table with the following definitions (D):

PROBA 3 / SRD


SS-432-D Mandatory: The required element of the Service shall be implemented within the unit/subsystem.

SS-433-D Optional: The required element of the Service may be implemented within the unit/subsystem if needed for their operations.

SS-434-D Offered: The Service is a standard system Service implemented by the central Command & Control Function, which may be implicitly used for operations but does not require implementation in the unit/subsystem.

SS-435-D Not Applicable: These services are not applicable to the unit/subsystem.

Table 1 Applicable Proba-3 Packet Service Types

Service Type Service Name Applicability for Coronograph

Interfaces

1 Telecommand Verification Service Mandatory

2 Device Command Distribution Service Optional

3 Housekeeping and Diagnostic Data Reporting Service

Mandatory

4 Not used Not Applicable

5 Event Reporting Service Mandatory

6 Memory Management Service Mandatory


8 Function Management Service Optional

9 Time Management Service Mandatory


11 Onboard Operations Scheduling Service Offered

12 Onboard Monitoring Service Offered

13 Large Data Transfer Service Not Applicable (TBC)

14 Packet Forwarding Control Service Offered

15 Onboard Storage and Retrieval Service Offered

17 Test Service Mandatory

18 On Board Operations Procedure Service Offered

PROBA 3 / SRD


Table 1 Applicable Proba-3 Packet Service Types

Service Type Service Name Applicability for Coronograph

Interfaces

19 Event/Action Service Offered

7.1.11 GNC REQUIREMENTS

7.1.11.1 General

SS-436-R Unless otherwise specified, the GNC requirements refer to both PROBA-3 spacecraft.

SS-437-R All spacecraft GNC sensors and actuators shall have individual body-fixed refernce coordinate frames.

SS-438-R All GNC reference coordinate frames shall be specified with respect to the relevant spacecraft GFF.

SS-439-R The Flight Dynamics Database (FDDB) shall contain all GNC and propulsion system characteristics relevant for the control of the spacecraft in all operational phases (e.g. sensor alignment, thruster performance, etc).

SS-440-R The FDDB shall be in a format compatible with direct import and use in the Ground Segment.

SS-441-R The GNC shall provide hardware and associated on-board software to acquire, control and measure the required spacecraft attitude during all phases of the mission, and to control and monitor all the necessary velocity increments for the complete mission according to the specified system requirements.

SS-442-R The GNC shall provide during all the mission phases an autonomous capability to maintain the required attitude.

SS-443-R The GNC shall have the capabilty to perform autonomous attitude and orbit adjustement manoeuvres required by the mission operations and following timelines defined by ground during periods when ground contact is not available or ground response time beyond specified value.

PROBA 3 / SRD


SS-444-R During trajectory correction manoeuvre, the GNC subsystem shall be able to autonomously generate the guidance reference attitude, in the form of a constant inertial quaternion.

SS-445-R Completeness and continuity of the guidance attitude shall be ensured at Ground Segment level.

SS-446-R The control shall be stable in the presence of perturbing torques, spacecraft flexible modes, or liquid slosh during all mission phases and in all operational modes.

SS-447-R The GNC subsystem shall implement delta-V modes enabling the arrival at the target orbit.

SS-448-R As a minimum the GNC subsystem shall allow, in case of problems, uploading by Ground Control of the following parameters:

open-loop compensation torque initial value for the settling phase (for the first trajectory correction manoeuvre or significant evolution)

the velocity measurement method used to stop the manoeuvre

the mode time-out (limit for the Burn Firing Phase ending)

the commanded inertial attitude quaternion for the manoeuvre

the delta-V measurement axis value

the commanded delta-V value for each measurement method.

SS-449-R The GNC subsystem shall provide the capability to define, by ground telecommand, a new nominal/redundant configuration. Such a reconfiguration shall only be possible outside delta-V manoeuvres.

SS-450-R During the entire mission, the GNC subsystem shall provide the capability of thruster reconfiguration after thruster failure (continuous open or continuous closed).

SS-451-R The GNC subsystem shall allow modification of the thruster selection and modulation algorithms parameters to take into account variations of the centre of mass and inertias.

SS-452-R The GNC subsystem shall be able to autonomously detect and protect from blinding of STRs by Sun or planets or other bodies. In such event the GNC subsystem shall make attitude estimation based on IMU integration.

PROBA 3 / SRD



SS-453-R The GNC system shall provide the PROBA 3 platform with 3 axes attitude determination and control compliant with the FF and Coronagraph performance requirements.

SS-454-R The GNC system shall provide orbital determination of sufficient accuracy to meet mission requirements.

SS-455-R The GNC system shall provide a spacecraft Safe Mode based on simple and robust sensors and actuators.

SS-456-R In the Safe Mode identified in SS-455-R above the pointing performances shall be compatible with power, thermal and communications requirements.

SS-457-R The GNC system shall provide the means to calibrate the sensors and to compensate for calibration errors.

SS-458-R For all modes, the position/attitude controllers shall be designed with at least 6dB/30deg equivalent linear stability margins for all uncertainties and considering a perfect navigation and guidance and a one cycle delay.

SS-459-D For a MIMO system, it will be sufficient to ensure ||T||∞<2 and ||S||∞<2.

SS-460-R The central avionics shall provide the computational needs of both GNC and data handling.

SS-461-R A GNC function shall be provided to acquire, control and measure the required spacecraft attitude during all phases of the mission, and to produce, control and monitor all the necessary velocity Increment burns and wheel momentum off-loadings for the complete mission.

7.1.11.3 Design and Operational Requirements

SS-462-R Momentum offloadings shall be commandable from the ground.

SS-463-R The attitude of the spacecraft shall not be perturbed by momentum build up over a period of less than 48 hours (TBC).

SS-464-R It shall be possible to command any manoeuvre from the ground, i.e. no manoeuvre shall be exclusively automated.

PROBA 3 / SRD


7.1.11.4 Composite Operations Requirements

SS-465-R The GNC subsystem shall be able to maintain, during Safe Mode, the Lauch Composite or Satellite Stack, as appropriate, in a sunpointing attitude using a minimum of the on-board resources while ensuring power generation and ground communication.

SS-466-R During composite operations, the GNC system shall be capable of determining and controlling the attitude of the Launch Composite to support sun pointing and main PM engine firing.

SS-467-R During PM main engine firing mode as part of the Launch Composite operations, the angle between the actual and commanded thrust vectors shall be less than 1º. This requirement shall be met with 95% confidence.

SS-468-R During sun pointing mode as part of the Launch Composite operations, the attitude of the Launch Composite shall have an APE of less than 3º for each axis. This requirement shall be met with 95% confidence.

7.1.11.5 Verification Requirement

SS-469-R Information from all GNC actuators and sensors, as well as onboard GNC software states and processed data, shall be available on request in telemetry to allow the Ground to verify the correct performance of the Attitude Control, Orbit Control and Formation Flying algorithms.

7.1.12 SOFTWARE ENGINEERING REQUIREMENTS

7.1.12.1 General

SS-470-D This section covers the software embedded on the platform onboard computer(s).

SS-471-D It is an objective of PROBA3 to demonstrate the advantages of advanced software technology. In particular the intensive use of modelling technologies, formal verification, and automatic code generation shall be considered as the main drivers of the PROBA3 Software approach. Tools supporting quick generation of prototypes shall be favoured. Modelling shall concern not only mathematical algorithms but also interfaces (data) and behaviour (state machines).

PROBA 3 / SRD


SS-472-R The requirements of AD 18 shall be applicable.

SS-473-R The software shall provide all the functions as required by the mission requirement sections and the subsystem requirements sections

SS-474-R The onboard software shall be specified and designed using formal description techniques.

7.1.12.2 Software Specification

SS-475-R At system and subsystem level, operational scenarii shall be identified and described using Message Sequence Charts or Sequence Diagrams.

SS-476-R A logical architectural model of the software system shall be produced to identify all the system functions (also referred to as functional blocks) that will be implemented as onboard software applications.

SS-477-R The logical architectural model shall reveal provided and required interfaces of each functional block.

SS-478-R Application data that is exchanged between functional blocks shall be identified and captured in a Data Model that is independent from an implementation language.

SS-479-D At specification phase, the requirement SS-478-R from above means listing the data types names in a specific notation (e.g. ASN.1) and specifying the application semantics of this data (e.g. "Quaternion", "Error codes"). It is not expected, during specification phase, to have complete, precise data structure defintition yet but to formally identify them for future refinement.

SS-480-R The software interface requirement document (IRD) shall include architectural and data models of the system.

SS-481-R Binary encoding rules for data types that have to be exchanged between distant components shall be specified according to the system constraints (bandwidth, heterogeneousness of the components).

SS-482-D Standard compact binary encoding rules (e.g. PER from ASN.1) for which existing commercial tools can generate encoders and decoders shall be used, in order to facilitate generation of quick prototypes of the software.

PROBA 3 / SRD

issue 1_4 revision - July 10th 2008 P3-EST-RS-1001

page 100 of 127

SS-483-R Each interface revealed in the software system logical model shall be enriched with non-functional attributes (e.g. period of activation, deadline, reactivity constraint, etc.).

SS-484-R For each functional block, the description of the expected behaviour in both nominal and non-nominal cases shall be provided using a notation that can be used to make formal verifications once the complete behavioural models are available.

SS-485-R A selection of modelling languages and tools shall be performed to implement the functions of the software system, depending on their nature (event-based automata, synchronous calculation functions).

SS-486-R Selection of modelling languages and tools shall be made according at least to the following criteria:

language allows formal verification of functional properties (expected behaviour of the system);

automatic code generation is supported.

7.1.12.3 Software Design

SS-487-R Design of the functional blocks shall be done using the modelling languages and tools selected during the specification phase

SS-488-R Models of the software shall contain the complete description of the software (data, structure, and behaviour) in order to allow formal verification of functional properties independently from the implementation language.

SS-489-R An iterative development approach shall be followed in order to validate early models.

SS-490-R Mission-independent software (data handling, basic services) that was developed and validated for previous missions shall be reused to an extent to be agreed with the Agency.

SS-491-R The Data Model shall be completed with detailed description of the abstract data types that are used to represent the messages exchanged between independent functional blocks at runtime.

SS-492-R Data types used to describe information that is shared between independent software components (e.g. between satellites of the constellation or between ground and space) shall be constrained with respect to application semantics.

PROBA 3 / SRD


page 101 of 127

SS-493-D Examples for the requirement SS-494-R above are ranges that shall be defined for numerical types, optional fields shall be identified, etc.

SS-495-R Behavioural models (implementing the functional blocks) shall use the data types from the data model in order to ensure data consistency at system level.

SS-496-R Software Interface Control Documents (ICD) shall include the complete Data Model, together with the binary representation of the user data that has to be exchanged between independent components

SS-497-R The real-time distributed architecture of the software shall be derived from the logical model using the non-functional attributes associated to the functional blocks interfaces.

SS-498-R The real-time architecture of the software shall be captured using a notation that allows to graphically identify all tasks and their interactions.

SS-499-R A real-time operating system shall be selected to ensure that non-functional properties are always verified.

SS-500-R Mission independent software layers (Data Handling/Basic services) shall exhibit standard interfaces to the application layer in order to facilitate integration of automatically-generated code into the overall software architecture.

SS-501-R Experimental software, if any, shall be isolated from critical software.

SS-502-R Traceability between design and specification shall be ensured

7.1.12.4 Software Implementation

SS-503-R Manual code shall be limited to the development of low-level, hardware-dependent software.

SS-504-R Models of the functional blocks shall be converted to implementation code automatically using tools.

SS-505-R Automatically generated applications shall be integrated in the overall on-board software without manual modification of the code

SS-506-R A software budget shall be prepared and maintained.

PROBA 3 / SRD


page 102 of 127

SS-507-R The software budget shall cover the processing load, the code and data memory occupation and the response time margin for the critical real-time functions.

7.1.12.5 Software Maintenance During Flight

SS-508-R The software shall support periodic transmission of the acquired data to ground in predefined software controlled telemetry groups or packets.

SS-509-R The software shall have the capability to downlink any onboard parameter or any memory area upon request.

SS-510-R It shall be possible to dump the entire on-board software over a maximum of one (TBC) nominal, planned contact with the ground station.

SS-511-R With the exception of boot PROM software, all on-board software components shall be modifiable from ground without need of restarting the whole software and without affecting the system performance or disturbing unrelated ongoing operations.

SS-512-R Memory loads shall be permanently available on-board to avoid time-consuming re-loads from the ground following memory switch on.

SS-513-R Two copies of the software shall be available on board, one copy shall be stored in a non compressed format allowing partial patching.

7.1.12.6 Software Test Bed / Software Validation Facility

SS-514-R A specific tool for software integration and testing shall be provided.

SS-515-R The tool from SS-514-R above (SVF=Software Validation Facility) shall provide the capability to perform functional testing of the software in either open or closed loop in a simulated environment representative of the real spacecraft hardware for all aspects including time.

SS-516-R The tool from SS-514-R above (SVF=Software Validation Facility) shall be available for testing of new software before upload to the satellite.

SS-517-R In addition to the software validation as expressed in the requirement SS-515-R above, the compatibility of the new software with the current flight software and in particular the low-level software (interfacing with the spacecraft) shall be verifiable.

PROBA 3 / SRD


page 103 of 127

7.1.12.7 Software Validation Process

SS-518-R Validation of the software shall be done at both model and code level.

SS-519-R Verification and validation at model level shall guarantee that all functional properties of the system are verified.

7.1.12.8 Software Delivery and Acceptance Process

SS-520-R Each OBSW delivery shall be accompanied by delivery notes detailing

the configuration control information, updates, reasons for updates (SPR numbers) and any other information agreed with the Agency.

7.1.12.9 Software Verification Process

SS-521-R All on-board SW elements shall use a SW Validation Facility (SVF) running on an instruction-level simulator for testing.

SS-522-R HW, interfaces and environment shall be implemented into the SVF via simulation models.

SS-523-R For all on-board software, the relevant SVF shall support on-board software development and testing prior to integration with the flight hardware.

SS-524-R The relevant SVF shall support flight software maintenance.

SS-525-R The SVF shall support unit (white and black box), modules, IT, functional and validation test of the flight software.

SS-526-R The SVF shall include software simulation of the environment in which the software operates (e.g. GNC, data bus, TM/TC-interfaces, etc.) to present a flight-representative environment.

SS-527-R The SVF (and any supplementary simulations tools) shall be capable of supporting the operations preparation and ground segment testing and integration activities.

SS-528-R In particular, the SVF shall support the following functions:

Saving and restoring breakpoints,

Injecting failures,

PROBA 3 / SRD


page 104 of 127

Running at real time x TBD speeds (where TBD is greater than 1),

Forcing different orbital configurations.

SS-529-R The SVF shall be transportable.

SS-530-R The SVF shall include and support tests of GNC dynamic models.

SS-531-R The operational interface to the SVF shall be achieved via the satellite reference database (SRDB).

SS-532-R For SW-level testing of GNC functions, the SVF shall ensure the possibility that such GNC SW can be tested in closed loop.

7.1.12.10 Software Management Process

SS-533-R It shall be possible for the Ground Segment to update all mission software as required during the mission.

SS-534-R The format of the OBSW patch shall be in a format compatible with import to and processing by the PROBA-3 Ground Segment.

SS-535-R OBSW patches shall be initially loaded to a free memory area to allow verification of upload before activation.

SS-536-R Integrity of the memory area during load or dump operations shall be ensured by the on-board processes.

7.2 Spacecraft Operational Requirements

7.2.1 SPACECRAFT OPERABILITY SS-537-R The Satellites shall provide the capability to the Ground Segment to

command and program all their configurable items, in both nominal and contingency situations, in relation to:

Mission phases and modes of operations

Control of the performance of all satellite functions including the Coronagraph instrument

Exploitation of all satellite functions

Analysis and recovery from anomalies

PROBA 3 / SRD


page 105 of 127

Replacement of all or any part of the on-board software loaded in RAM and addition of SW patches

Replacement of all or any part of the on-board software loaded in EEPROM and addition of SW patches

SS-538-R Simultaneous on-board data recording (e.g. from Sun observation) and downlink shall be possible.

SS-539-R It shall be possible for the PROBA-3 Spacecraft to receive telecommands and transmit telemetry simultaneously with the Formation Flying demonstrations and Science measurements, whilst in visibility of the allocated ground station(s).

SS-540-R It shall be possible, whenever the satellites are in visibility from their command and control Ground Station to continuously monitor and control the satellites.

SS-541-R Either satellite shall be able to operate as the master spacecraft.

SS-542-R The mission operations shall be compatible with command and control from a single S-band Ground Station during commissioning and routine operations.

SS-543-R After each orbit raising/correction manoeuvre it shall be ensured that the signal of the spacecraft can be safely acquired at the Ground Station.

SS-544-R The requirement SS-543-R above shall be fulfilled even in the worst case scenario that the manoeuvre was accidentally not executed or was executed with twice (TBC) the amount of the nominal delta-v.

7.2.2 SPACECRAFT COMMANDABILITY

7.2.2.1 General

SS-545-R The satellites shall be able to receive and process a continuous uplink of any sequence of tele-command packets (with any combination of APIDs) at the nominal uplink rate in all of their operational modes (including Safe Mode).

SS-546-N Note: The requirement SS-545-R from above includes the case that all commands are foreseen for the same APID and they are of the same type.

PROBA 3 / SRD


page 106 of 127

SS-547-R Execution of vital functions (to be agreed by ESA), if commandable, shall be implemented by a nominal and a redundant tele-command, i.e. High Priority Command.

SS-548-R Vital functions shall only be executed after successful reception and validation of both independent tele-commands.

SS-549-R Commanding of hazardous functions shall be implemented by means of two independent tele-commands.

SS-550-R Hazardous functions shall only be executed after successful reception and validation of both independent tele-commands.

SS-551-N NOTE: This means an arm/safe or enable/disable command followed by an execute command.

SS-552-N EXAMPLE: Commands for propulsion system or electrical power system activation.

SS-553-R Redundant tele-commands shall be separately routed from their corresponding nominal tele-commands.

SS-554-R A tele-command packet shall contain a single tele-command function only.

SS-555-N Note: a tele-command function is an operationally self-contained control action. A tele-command function may comprise or invoke one or more low-level control actions

SS-556-R It shall be possible to individually command all on-board equipment directly from the Ground.

SS-557-R It shall be possible to command the satellites or any of their sub-systems into each of their operational modes by means of a single tele-command.

SS-558-R A tele-command that does not conform to the packet tele-command standard as defined in AD 25, and/or is not recognized as a valid PROBA-3 tele-command shall be rejected at the earliest possible stage in the on-board reception, acceptance and execution process.

SS-559-R It shall be possible to change on-board data or software parameters by means of dedicated tele-command(s)

SS-560-N Note: The general-purpose memory load tele-command shall not be used for the above. Use of this tele-command to fulfil specific instances of the above requirement may be acceptable if the data and software parameter locations remain fixed, independent of the software version

PROBA 3 / SRD


page 107 of 127

(i.e. if it can be defined as a dedicated command in the ground database, where the addresses are fixed in the command structure).

SS-561-R It shall be possible to re-program any on-board software, including the embedded software to an extent to be agreed with the Agency, via dedicated tele-commands.

SS-562-R Readouts of loaded on-board data or software parameters shall be requested via dedicated tele-command(s).

SS-563-N Note: The general-purpose memory dump tele-command shall not be used for the requirement SS-562-R from above.

SS-564-R The switching off of the Coronagraph instrument shall be executed as a result of:

command from Ground

an autonomous action initiated by the DHS, or

directly upon request from the instrument

SS-565-R Initialisation of a mode (at satellite, subsystem or unit level) shall include autonomous re-configuration of the necessary hardware and software, activation of a default periodic telemetry format configuration, a frequency of telemetry parameters acquisition, and all of the automatic processes required to achieve the mode, monitor its health status, and stay within in a stable manner.

7.2.2.2 Mission Timeline Management

SS-566-R During nominal operations when the spacecraft are being operated in ‘virtual spacecraft’/centralised mode the uploaded Master Mission Timeline (MTL) shall be interpreted by the master spacecraft such that the instructions required by each satellite are extracted from the master MTL, executable spacecraft commands are generated and distributed to the appropriate spacecraft.

SS-567-R The master spacecraft shall perform consistency checking of the master MTL to resolve resource or operations conflicts.

SS-568-R A plan summary (consisting of high level instructions) shall be downlinked upon completion of the MTL conflict checking.

SS-569-R The verified executable commands shall be distributed to the PROBA-3 spacecraft (in centralised mode).

PROBA 3 / SRD


page 108 of 127

SS-570-R The master spacecraft shall manage the intialisation of the MTL(s).

SS-571-R During decentralised operational modes, when the spacecraft are being operated as separate spacecraft, the two spacecraft shall receive and interpret individual MTLs and execute the instructions therein.

SS-572-R As it is possible that the spacecraft are being operated separately following anomalous behaviour of the spacecraft, the spacecraft shall have the capability to operate from either high level operational instructions or from low level commands.

SS-573-R For any on-board MTL, it shall be possible for the ground to:

Delete the entire on-board schedule,

Delete sections of the schedule,

Insert any command into the schedule,

Timeshift the entire schedule,

Specify operations/instructions in terms of relative times and delays,

Stop and start the schedule,

Request a report of the contents of the schedule

7.2.3 SPACECRAFT OBSERVABILITY SS-574-R The satellites shall provide in their housekeeping telemetry all data

required for the monitoring and execution of all nominal and foreseen contingency operations throughout the entire mission.

SS-575-R It shall be possible for the Ground to determine in all satellite modes, including safe mode, the status of the software and hardware of each on-board sub-system of any of the 2 satellites unambiguously from real-time housekeeping telemetry.

SS-576-R The requirement SS-575-R from above shall be met without knowing the history of the tele-commands, the history of autonomous on-board actions or information delivered in previous telemetry.

SS-577-R For elements in hot redundancy, telemetry shall be provided to enable an independent and unambiguous evaluation of the status of each chain.

PROBA 3 / SRD


page 109 of 127

SS-578-R For elements in redundancy, the loss or failure of one chain shall not prevent access to the telemetry of the other chain.

SS-579-R The availability of telemetry information shall be compatible with the required response times for monitoring and control activity implemented on ground.

SS-580-R Telemetry shall always be provided to unambiguously identify the conditions required for execution of all possible configuration-dependant tele-commands.

SS-581-N Note: A configuration dependant tele-command is defined as a tele-command that should only be executed if a particular subsystem or instrument condition is satisfied.

SS-582-R All satellite functions, the loss of which can lead to catastrophic or critical consequences, shall be observable by at least two independently obtained measurements.

SS-583-R All inputs and outputs to on-board autonomous processes shall be accessible to the ground via telemetry.

SS-584-R It shall be possible to include any of the commandable parameters such as monitoring and control thresholds, software tables and flags as well as any global variables in the software status telemetry.

SS-585-R The monitoring of all on-board events and parameters shall be automatic and their reporting within the housekeeping telemetry autonomous.

SS-586-R Housekeeping telemetry and event reports shall be accurately time stamped.

SS-587-R The PROBA-3 space segment shall maintain a health status report collected in what is defined hereafter as “essential telemetry”.

SS-588-R Essential (high-priority) telemetry enabling a reliable determination of the current status of the on-board vital equipment under all circumstances shall always be available for real-time downlink.

SS-589-R The essential telemetry shall be inserted in the housekeeping of both satellites in all modes of operations including Safe Mode.

SS-590-R In case of a Safe mode, the spacecraft shall continue to generate the essential telemetry report.

SS-591-R The reason for the triggering of the Safe Mode and the history of the defined events occurred before and after the detection of the failure

PROBA 3 / SRD


page 110 of 127

condition shall always be accessible in direct telemetry and stored in memory areas that can be later dumped and reset by the Ground.

7.3 Verification Requirements

7.3.1 GENERAL ASPECTS

7.3.1.1 Verification Objective

SS-592-D The objective of the verification programme is be to ensure and demonstrate to the customer that the FF satellites are fully compliant with the specified requirements, with margins and capable of fulfilling the mission objective.

SS-593-R The FF satellites shall therefore be verified and validated.

SS-594-R Purpose of the verification shall also be to assess the full compatibility of the Space Segment with the Ground Segment.

7.3.1.2 Verification Scope

SS-595-R The verification programme shall include all aspects of flight hardware and software and all aspects of GSE.

SS-596-R All associated equipment requested to fulfil the programme objective shall be included in the verication programme.

SS-597-R PROBA 3 performance verification shall be performed end-to-end, which shall be understood as involving all the system segments, i.e. the Space Segment, the Ground Segment and the tools which simulate the Space Segment.

SS-598-R The requirement verification shall be performed incrementally on all system segments at all levels of the design decomposition.

SS-599-R Formal close-out of verification actions at lower levels shall be a prerequisite for close-out at higher levels.

SS-600-R The verification process shall make use of tools and support facilities developed at various stages of the system development, for verification during development (performance analysis, design verification, software verification), qualification and acceptance.

PROBA 3 / SRD


page 111 of 127

SS-601-R The verification process shall include the system operations, i.e. the way the system is operated and provides its service when it is in operation.

SS-602-R The verification process shall ensure a sufficient level of independence from the design process by envolving as appropriate different teams and different hardware for testing from those used for design.

SS-603-R A pre-determined set of performance parameters shall be established for the verification of the system performance.

SS-604-R All segments, elements and verification tools shall implement telemetry, monitoring and control or data observability in order to ensure:

Evaluation of all necessary parameters associated with the pass / fail criteria of planned test;

Troubleshooting of anomalies down to at least replaceable-unit level;

Recording of sufficient information to allow the replication of the anomalous behaviour;

Implementation of tools to replay this data at the replaceable-unit level.

7.3.2 VERIFICATION APPROACH

7.3.2.1 General



7.3.2.2 Requirement identification and traceability

SS-607-R Requirements engineering shall be performed as per AD 1.

7.3.2.3 Requirement Attributes

SS-608-R The requirements shall have the attributes reported in AD 2 par 8 (i.e. justified, traceable, unique, single, verifiable, unambigous, referenced).

PROBA 3 / SRD


page 112 of 127

7.3.2.4 Verification Methods

SS-609-R The methods of verification shall be the ones reported in AD 3 par 4.2. (i.e. test, analysis, review of design, inspection or combinations thereof).

7.3.2.5 Level of Verification

SS-610-R The verification shall be based on the following levels:

Launch Composite: system formed by the Occultor S/C, Coronagraph S/C and Propulsion Module in case a PM is baselined.

Satellite Stack: system formed by the Occultor S/C and Coronagraph S/C

PROBA 3 satellites: each separate Occultor and Coronagraph satellite

Sub-system unit: Coronagraph instrument, Coarse Metrology unit, Fine Metrology unit, etc.

Equipment: individual component of sub-system (e.g. batteries, combustion chambers, nozzles, etc.)

7.3.3 MODEL PHILOSOPHY

7.3.3.1 Satellite System and Subsystem Models

SS-611-R A Proto-Flight Model (PFM) approach shall be applied to the satellite system.

SS-612-R The EMs and EQMs shall be linked to the ATB and STB and verified in an early stage of the sub-system development.

SS-613-R The choice of the number of models for the sub-systems shall be based on the TRL and agreed with the Agency.

SS-614-R For subsystems having a low TRL (less than 5) a full prototype approach shall be applied.

SS-615-R A structural thermal model STM for the composite satellite system shall be built and fully tested mechanically and thermally (mass properties,

PROBA 3 / SRD


page 113 of 127

modal survey, sine vibration, shock test, acoustic vibrations, thermal balance).

7.3.3.2 Simulators and Test Benches

SS-616-R The verification activity shall use dedicated test benches (SVF, ATB

and STB).

SS-617-D The System Validation Simulator is a software validation tool based on software validation facility (SVF) developed at ESA. It is a pure software system aiming at prototyping fligh software and algorithms (complete functional simulations).

SS-618-D The SVF is to be put in place at the beginning of the project and to be used in an iterative way through the development.

SS-619-D The software validfation facility used by the contractor should be derived from the software validation facility developed at ESA (TBC).

SS-620-R The SVF shall take into consideration the operational scenario.

SS-621-D The Avionic Test Bench (ATB) will be based on the SVF but including also hardware in the loop. As soon as sub-systems or units will be available (e.g. payloads, power, GNC, etc.) they will be included in the ATB and tested.

SS-622-D The ATB is expected to be put in place in the early development and shall be used in an iterative way.

SS-623-D The System Test Bench (STB) is a further evolution of the SVF and ATB to include all sub-system hardware. It will include a model of the core computer and will allow the simulations of all inputs/outputs.

7.3.3.3 Decoupling of Payload and Satellites

SS-624-R The scientific guest payload, being intended as a “guest payload” onboard the two satellites, shall not be used by the GNC of the satellites and in general in any satellite modes apart from a dedicated payload observation mode.

SS-625-R The interface of the payload to the satellites shall be simplified to a level to be agreed with the Agency and the design shall be such that

PROBA 3 / SRD


page 114 of 127

the payload can be accommodated in a very late stage of the assembly.

7.3.4 GSE SS-626-R The RF suitcase model (provided by the prime contractor) or equivalent

test equipment shall comprise flight representative hardware sufficient to test all up- and down-links for both functional and performance characteristics.

SS-627-R A dedicated interface unit (provided by the prime contractor) shall support direct interfacing of the Ground Segment to the spacecraft on the on-ground AIV environment (by-passing the ground station).

SS-628-R The Ground Support Equipment shall be planned and adequate for use for both AIV and operational spacecraft monitoring and control activities.

7.3.5 VERIFICATION DATA BASE SS-629-R A common data base of verification procedures shall be established

and maintained throughout the project’s lifecycle.

SS-630-R The SVF and ATB shall run the verification procedures from the common database.

7.3.6 SATELLITE REFERENCE DATA BASE SS-631-R A model based approach shall be implemented.

SS-632-R The models of the satellite shall be maintained in a central Satellite Reference Data Base (SRDB).

SS-633-R Operational sequences/procedures shall be in a commonly agreed format that supports activities during all phases of the spacecraft AIV, operations preparation and operations.

7.3.7 GROUND SEGMENT COMPATIBILITY TESTS SS-634-R The following tests are required, as a minimum, to demonstrate

compatibility of the PROBA-3 spacecraft with the Ground Segment, in stack, virtual or individual modes:

The RF Compatibility Test – to demonstrate compatibility of the spacecraft with the ground station,

PROBA 3 / SRD


page 115 of 127

The System End-to-End Test – to demonstrate compatibility of the spacecraft with the Ground Segment.

8 GROUND SEGMENT REQUIREMENTS

8.1 General GS-1-R The Ground Segment shall make use of existing systems as agreed

with the Agency.

GS-2-R The Ground systems shall support the following activities:

Monitoring and control activities of the PROBA-3 spacecraft in all mission phases,

Mission planning activities of all PROBA-3 activities,

Communications with the Space Segment,as required throughout the mission.

On-board Software Maintenance,

Formation flying operational instruction preparation,

Evaluation of formation flying operational performance,

Doppler measurements, calculation of spacecraft orbital position and orbit prediction,

GPS calculations as specified

GS-3-R The Ground systems shall include interface and test tools required to support activities in preparation phases, specifically AIV, SVT and pre-launch activities (space and ground).

GS-4-R The Space to Ground Interface document shall include full link budget analysis and packet structure definition in order to ensure Ground Segment compatibility with the PROBA-3 spacecraft, as specified in this document, during all mission configurations.

GS-5-R The Ground Segment shall be designed such that it is compatible with the operations framework outlined in AD 36, particularly regarding the task distribution.

PROBA 3 / SRD


page 116 of 127

GS-6-R During the all operations phases, the 15-m ESA station at Redu shall be used.

GS-7-N Note: The 15-m ESA station at Villafranca could be used as backup (TBC).

GS-8-R During nominal operations the telecommunication period shall be used to uplink the telecommands for later execution and to dump the stored data as well as real-time transmission of science and housekeeping data.

8.2 Ground Station Characteristics GS-9-N Note: In the development of the Ground Segment the Prime Contractor

may assume the following characteristics of the Ground Station as a given:

GS-10-D The primary ground station for use with the PROBA-3 mission will be compatible with the complete range of capabilities (frequencies, modulation & coding) of the spacecraft stack and the two individual spacecraft.

GS-11-D The Ground Station will support archiving of the downlinked real time telemetry for deferred transfer to the operational centre for a period of 3 days (TBD).

GS-12-D The Ground Station will support the receipt of telecommands a short (TBD) period of time prior to the expected uplink time.

GS-13-D The telecommands will then be uplinked to the spacecraft during the planned visibility.

GS-14-D The ground station will support the collation of the downlinked playback telemetry, auxiliary data and payload data such that it can be transferred to the operational centres via a low cost link (e.g the internet).

GS-15-D The ground station will support Spiral search and Autotrack modes.

GS-16-D The ground station will have the capability to send the Doppler measurement data and autotrack data to the operational centre via a low cost link (e.g the internet).

GS-17-D During operational phases, the data received at the ground station will be available at the operational centre within 3 days (TBC).

PROBA 3 / SRD


page 117 of 127

GS-18-N Note: The description GS-17-D from above implies no commitment on data return.

GS-19-D It will be possible to operate the ground station in a local mode or a remote mode.

GS-20-D The ground station will support automated operations.

8.3 Monitoring and Control GS-21-R The Ground Segment shall be able to automate all routine pass

activities in order uplink the MTLs and activate the downlink.

GS-22-R The Ground Segment shall be able to support all necessary monitoring and control operations in all spacecraft modes.

GS-23-R It shall be possible to perform spacecraft monitoring and control activities via a remote client interface to the spacecraft monitoring and control system based on a geographical separation of TBD kilometres.

GS-24-R The Ground Segment shall be able to autonomously change configuration as necessary i.e. an autonomous spacecraft reconfiguration from ‘virtual’ spacecraft mode to individual spacecraft operations shall be supported autonomously by the Ground Segment.

GS-25-R The Ground Segment shall have the capability to distribute all HKTM, anomaly and event reports, command histories and science data over the internet for access by geographically remote registered users.

GS-26-R The Ground Segment shall have the allow this data to be exported in text files (TBC) for import into compatible users’ data processimg tools.

GS-27-R An office-based (PC) system shall be able to acquire telemetry over the internet for off-line processing of telemetry, including access to history files.

GS-28-R The Ground Segment shall automatically (regularly, by standing order, or by request) generate reports based on configurable templates, accessing archived telemetry and history files.

GS-29-R It shall be possible to perform WOLs automatically (on-board) or manually (controlled from the ground).

8.4 Mission Planning

PROBA 3 / SRD


page 118 of 127

GS-30-R The Ground Segment shall provide the capability to collate all operational requests from the formation flying control service, the flight control team and the payload authority.

GS-31-R The mission planning systems shall support the operations concept, particularly concerning the geographically distributed planning responsibilities.

GS-32-R The mission planning systems shall communicate over the internet such that the tiered mission planning concept is supported and information regarding the spacecraft planning can be disseminated to all interested parties.

GS-33-R The Ground Segment shall be able to produce MTLs in a format compatible for direct import into the mission control system and uplink to the spacecraft for all spacecraft modes.

GS-34-R The Ground Segment shall provide the capability to generate a Master MTL or individual spacecraft MTLs, (containing either high level instructions or executable level commands), as compatible with the PROBA-3 space segment (TBD).

GS-35-R The mission planning systems shall provide the capability to produce all executable plans/schedules required for the autonomous operations of the ground system during routine operations phases.

8.5 On-Board Software Maintenance GS-36-R The Ground Segment shall provide the capability to import authorised

OBSW patches from the Prime Contractor, e.g. by e-mail or internet.

GS-37-R The Ground Segment shall support the archiving and configuration control of the OBSW patches.

GS-38-R The Ground Segment shall support the comparison of the imported OBSW patch with the locally held copy of the current OBSW version, in order to identify the differences and generate the commands needed to uplink the OBSW.

GS-39-R The generated patch commands shall be compatible with the Space Segment in accordance to AD 25.

GS-40-R The Ground Segment shall support the generation of the necessary commands to request the dump of the uploaded OBSW memory area.

GS-41-R The generated dump commands shall be compatible with the Space Segment in accordance to AD 25.

PROBA 3 / SRD


page 119 of 127

GS-42-R The Ground Segment shall support the comparison of the dumped memory areas with the uploaded memory areas in order to verify the successful upload of the patch.

GS-43-R The Ground Segment shall generate the required command(s) to activate the OBSW patch.

8.6 Flight Dynamics GS-44-R The Ground Segment shall be able to perform orbit determination and

prediction based on the Doppler data collected by the designated Ground Station (TBC).

GS-45-R The Doppler data collected during the course of nominal, planned ground station contacts shall be sufficient to perform orbit determination and prediction, prior to and following manoeuvres.

GS-46-R The Ground Segment shall be able to incorporate GPS data and station tracking data, when available, into the orbit determination and prediction calculations.

GS-47-R The Ground Segment shall be able to calculate all necessary ground station predictions required to operate the PROBA-3 prime ground station and the identified LEOP stations.

GS-48-R The Ground Segment shall be able to calculate all orbit events predictions required for the safe operation of the PROBA-3 mission.

GS-49-R The Ground Segment shall support the preparation of optimised manoeuvres to:

Reach the target orbit,

Achieve commissioning phase objectives,

Prepare any orbit maintenance operations,

Recover from safe mode(s),

Rendezvous manoeuvre planning

Put the spacecraft in the required orbits as required for specified operational phases,

Prepare the satellites for end of life operations.

PROBA 3 / SRD


page 120 of 127

GS-50-R The Ground Segment shall have the capability to generate the commands (or command parameters) required for all necessary spacecraft or GNC functions, in the format compatible for processing by the mission planning system, and subsequent uplink to and execution by the spacecraft in all mission phases.

GS-51-R The commands necessary for all necessary GNC functions shall include, but shall not be limited to:

Preparation of attitude commands and GNC support parameters,

Preparation of manoeuvre commands (or command parameters),

Preparation of wheel offloading commands.

GS-52-R The Ground Segment shall be able to route the manoeuvre commands (or command parameters) including any necessary ancillary information to the Ground Segment element responsible for preparing the MTLs.

GS-53-R The Ground Segment shall be able to route the ground station prediction information to the Ground Segment element responsible for the Ground Station operations and scheduling.

GS-54-R The Ground Segment shall have the capability to manage propellant book-keeping, including maintaining separate deltaV budgets and mass properties of the spacecraft.

8.7 Formation Flying GS-55-R The Ground Segment shall have to capability to select, retrieve and

import into the necessary system, flight dynamics and formation flying relevant TM for further processing and analysis.

GS-56-R The Ground Segment shall have the capability to:

Evaluate the health status and performance of on-board sensors and actuators

Evaluate the performance of formation flying activities,

Calibrate sensors and thrusters as necessary.

GS-57-R The Ground Segment shall have the capability to import and reference GNC and propulsion system characteristics from a Flight Dynamics Database (FDDB).

PROBA 3 / SRD


page 121 of 127

GS-58-R The Ground Segment shall be able to incorporate data from the coronagraph into the FF performance evaluation calculations when applicable.

GS-59-R The Ground Segment shall have the capability to prepare FF commands based on FF operational requests from the Formation Flying Exploitation Centre (FFEC).

GS-60-R The FF commands shall be in a format compatible with import into, and processing by, the mission planning system, and subsequent uplink to and execution by the spacecraft.

GS-61-R The Ground Segment shall have the capability to verify the generated operational products.

GS-62-R The required test tool to verify the generated operational products shall make use of test tools and simulators developed for other validation purposes and maximisation of this usage shall be demonstrated to and agreed with the Agency

9 OPERATIONS REQUIREMENTS

9.1 General OP-1-R The Ground Systems support to the Proba-3 operations concept shall

be compatible with the framework presented in AD 36.

OP-2-D The mission operations proper commence at separation of the satellite stack from the launcher vehicle and continue until the end of the mission (extended operational phase), when ground contact with the satellite is aborted.

OP-3-R The mission shall be operated in an ‘off-line’ mode. This implies:

All necessary commands/instructions required for mission operations for the following week shall be prepared on ground and uplinked during a routine scheduled pass.

The spacecraft shall store all HK TM and event data, including FF auxiliary data, and coronagraph measurement data for downlink during the routine scheduled passes.

All data shall then be analysed off-line, on ground.

PROBA 3 / SRD


page 122 of 127

OP-4-R During nominal activities the communications from/to the ground shall be to/from the master spacecraft and the master scheduling and data management shall be managed by the master spacecraft.

OP-5-R Under certain circumstances during the nominal operations phase, the two spacecraft shall provide the technical capability to be operated as independent individual spacecraft.

OP-6-R The PROBA-3 spacecraft shall continue in a nominal operations mode, in the absence of ground contact, including the generation of mission products, for a minimum period of one week, assuming a number of TBD formation flying demonstrations in this period.

OP-7-N Note: The prime ground station for all mission phases has been identified in chapter 8.1.

OP-8-R No critical operations or contingency operations during the nominal operations phase shall require ground intervention in less than one week following the notification to ground of the event.

OP-9-R The operations of the Coronagraph instrument shall have no operations dependencies that imply ground intervention over and above that required for the platform (including FF) operations, i.e. the Coronagraph shall not drive the mission planning concept.

9.2 Operations Preparation OP-10-R All executable nominal operations procedures and identified and

agreed executable contingency recovery procedures for all mission phases shall be included in a validated (electronic) Flight Operations Plan.

OP-11-R Databases (SRDB, FDDB, etc.) delivered by the prime contractor in an electronic format, as required to operate the mission from the delivered Ground Segment infrastructure, shall be validated against requirements to be agreed with the Agency.

OP-12-R OBSW as required to operate the mission from the delivered Ground Segment infrastructure, shall be validated by the prime contractor.

OP-13-R All electronic deliverables shall be annotated and under configuration control such that the purpose, context and applicability of the item is unambiguosly identified.

PROBA 3 / SRD


page 123 of 127

9.3 Operational Validation OP-14-R The correct operational performance of all industry provided operations

and ground infrastructure, including adequacy of personnel, shall be validated.

OP-15-R The operational validation activities shall be executed based on an Operational Validation Test Plan, agreed with ESA.

10 ACRONYMS AAE Absolute Attitide Error AAME Absolute Attitude Measurement Error AAMS Absolute Attitude Measurement Stability AD Applicable Document AIV Assembly, Integration and Verification AL Acceptance Load AOCS Attitude and Orbit Control System APE Absolute Pointing Error APID Application ID ASIC Application Specific Integrated Circuit ATB Avionics Test Bench ARaSS Absolute Radiometer and Sun Sensor BOL Begin of Life BPSK Binary Phase Shift Keying CDR Critical Design Review COG Centre of Gravity COMS Communication Subsystem COTS Commercial Off The Shelf CPS Chemical Propulsion System CPU Central Processing Unit CS Coronagraph Spacecraft CTMM Coupled Thermal Mathematical Model DDVP Design Development and Verification Plan DHS Data Handling System DOF Degree of Freedom DTMM Detailed Thermal Mathematical Model ECI Earth Centred Inertial (frame) ECSS European Cooperation for Space Standardisation EDAC Error Detection and Correction EED Electro-Explosive Device EEPROM Electrically Erasable Programmable Read-Only Memory EM Engineering Model EMC Electromagnetic Cleanliness EOL End of Life

PROBA 3 / SRD


page 124 of 127

EPS Electrical Power System EQM Engineering Qualification Model ESA European Space Agency ESATAN European Space Agency Thermal Analysis Network ESD Electrostatic Discharge ESOC European Space Operations Centre ESTEC European Space Technology Centre ESTRACKESA Tracking Stations Network FAR Flight Acceptance Review FCS Formation Centre Spacecraft F2S Formation Second Spacecraft FDDB Flight Dynamics Data Base FDIR Failure Detection Isolation and Recovery FF Formation Flying FFEC Formation Flying Exploitation Centre FMECA Failure Modes, Effects and Criticality Analysis FOP Flight Operations Plan FOS Factor of Safety FOSD Factor of Safety - Design FOSU Factor of Safety - Ultimate FOSY Factor of Safety - Yield FOV Field of View FST Formation Station Keeping GFF Geometric Fixed Frame GNC Guidance Navigation and Control GPS Global Positioning System GS Ground Station GSE Ground Support Equipment GSEG Ground Segment HAM High Accuracy Metrology HEO High Elliptical Orbit HK Housekeeping HPAP High Precision Attitude and Pointing HPM High Precision during Motion H/W Hardware ICD Interface Control Document ID Identifier IOD In Orbit Demonstration IRD Interface Requirements Document ISD Inter Satellite Distance ISL Inter Satellite Link IT Information Technology KA Aceptance Factor KP Project Factor KM Model Factor KQ Qualification Factor

PROBA 3 / SRD


page 125 of 127

LAM Laboratoire d’Astrophysique de Marseilles LAN Local Area Network LC Launch Composite LCDA Launcher Coupled Dynamic Analysis LCM Long distance omnidirectional Coarse Metrology system LED Light Emitting Diode LEOP Launch and Early Operation Phase LET Linear Energy Transfer LISA Laser Interferometric Space Antenna LL Limit Load LOS Line of Sight LPF LISA Pathfinder LPM LISA Pathfinder Propulsion Module LSEG Launch Segment LVLH Local Vertical Local Horizontal MIMO Multiple Input Multiple Output MIP Mission Implementation Plan MIRD Mission Implementation Requirements Document MOS Margin of Safety MLI Multi-Layer Insulation MRD Mission Requirements Document MTL Mission Timeline NDI Non Distructive Inspection OBCP On Board Control Procedure OBDH On Board Data Handling OBSM On Board Software Monitoring OBSW On Board Software OBT On Board Time OIRD Operations Interface Requirements Document OPS Operations OPSE Occulter Position Sensor OS Occulter Spacecraft PA Product Assurance PC Personal Computer PDR Preliminary Design Review PI Principal Investigator PLF Payload Frame PM Propulsion Module PROBA Project for On-Board Autonomy PROM Programmable Read-Only Memory PUS Packet Utilisation Standard PVT Position Velocity Time P3 PROBA 3 QL Qualification Loads QM Qualification Model RAM Random Access Memory

PROBA 3 / SRD


page 126 of 127

RBF Rotating Body Frame RD Reference Document RDME Relative Displacement Measurement Error RDMS Relative Displacement Measurement Stability RF Radio Frequency RFC Radio Frequency Compatibility ROF Rotating Orbit Frame RPE Relative pointing Error RSS Root Sum Square RV Rendez-vous (experiment) SA Solar Array SADM Solar Array Drive Assembly S/C Spacecraft SEB Single Event Burn-Out SECDED Single Error Correction and Double Error Detection SEE Single Event Effect SEGR Single Event Gate Rupture SEL Single Event Latch-up SET Single Event Transient SEU Single Event Upset SOC Science Operations Centre SOW Statement of Work SPS Shadow Position Sensor SRD System Requirements Document SRDB Satellite Reference Data Base SS Satellite Stack SSC Swedish Space Corporation SSEG Space Segment SSMM Solid State Mass Memory STB System Test Bench STF Sun Target Frame STM Structural Thermal Model STR Star Tracker SVF Software Validation Facility S/W Software TAS Thales Alenia Space TBC To be confirmed TBD To be defined TBW To Be Written TC Telecommand TCS Thermal Control System TM Telemetry TMM Thermal Mathematical Model TRL Technology Readiness Level TRP Temperature Reference Point VC Virtual Channel

PROBA 3 / SRD


page 127 of 127

VEGA Vettore Europeo di Generazione Avanzata WOL Wheel Off Loading XEUS X-ray Evolving-Universe Spectroscopy

YSTEM EQUIREMENTS OCUMENTemits.sso.esa.int/emits-doc/ESTEC/AO-1-5763-AD8-P3-EST-RS-1001-i… ·...

Documents

Transcript of YSTEM EQUIREMENTS OCUMENTemits.sso.esa.int/emits-doc/ESTEC/AO-1-5763-AD8-P3-EST-RS-1001-i… ·...