Ref.

Ares(2016)5751603 - 04/10/2016

TeSeR
Technology for Self-Removal of Spacecraft
Grant agreement no: 687295 Project Start: 1 February 2016
Project Coordinator Airbus DS GmbH Project Duration: 36 Months

WP 2
Deliverable D2.3 System and subsystem requirements document
WP Leader UNI BWM Task Leader UNI BWM
Due date M8, 30.09.2016
Delivery date 30.09.2016
Issue 1.0
Editor (authors) Kostas Konstantinidis, Alexandra Wander, Roger Förstner
Contributors Nikolas Schmelz
Verified by Philipp Voigt
Document Type Report
Dissemination Level PU (Public)

The TeSeR Consortium consists of:

Airbus DS GmbH (Project Coordinator) ADS Germany
Aalborg University AAU Denmark
Beazley Furlonge Ltd Beazley United Kingdom
D-Orbit SRL D-Orbit Italy
GomSpace APS GomSpace Denmark
Hyperschall Technologie Göttingen GmbH HTG Germany
PHS Space Ltd PHS United Kingdom
University of Surrey Surrey United Kingdom
Universität der Bundeswehr München UNI BWM Germany
University of Strathclyde USTRAT United Kingdom
Weber-Steinhaus & Smith WSS Germany

This project has received funding from the European

Union’s Horizon 2020 research and innovation
programme under grant agreement No 687295.
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 2/20

Change Record
Issue Date Section, Page Description of Change
1.0 30.09.2016 First Issue
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 3/20

Table of Contents
1 Introduction ............................................................................................................................................. 4
1.1 Scope.................................................................................................................................................. 4
1.2 List of Abbreviations.................................................................................................................... 5
1.3 Definitions ....................................................................................................................................... 7
1.4 Applicable Documents ................................................................................................................ 8
1.5 Reference Documents ................................................................................................................. 8
2 Post-Mission Disposal module system and subsystems definition ...................................... 9
3 PMD module System requirements .............................................................................................. 10
4 PMD module subsystem requirements ....................................................................................... 13
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 4/20

1 Introduction

1.1 Scope
The goal of this document is to identify and list the system and subsystem requirements for the
Post-Mission Disposal (PMD) module of the TeSeR project. These requirements are derived from
the high level and user requirements, as given in [AD3]. This document mainly aims to identify
the design driving requirements and will therefore focus on those.
We separate in three PMD module design cases:
• Prototype: refers to the module that shall be built in a laboratory environment within
the TeSeR project in order to test and verify selected TeSeR project selected
requirements.
• Basic: refers to the module as shall be built for its first deployment in space. The focus
for this case will be on maximizing reliability (for example by minimizing complexity) in
order to build customer confidence in the new PMD module. For these reasons higher
TRL technologies are to be considered for this module, and a low degree of on-board
autonomy is foreseen.
• Advanced: refers to the module as it will be built for the removal needs of future
spacecraft and space infrastructure. Such an advanced version should be made available
after customer confidence in the basic version is established. Longer term technologies
can be considered for this design case and a higher degree of on-board autonomy is
foreseen.
In this document we investigate the requirements for the basic PMD module case.
These requirements can then serve as basis for the requirements of the other two design cases
in the future. Since we focus on the basic case, we will only derive system and subsystem
requirement from the requirements listed in [AD3] (“shall” statements) and not the goals
(“should” statements).
Due to the early stage of the project several requirements have a TBD instead of a defined
number or a range. Due to the iterative nature of the work needed for space systems design, we
propose to submit one or more document updates in the duration of TeSeR.
Notes:
• Established requirements have a format of e.g. SYS-101. Pending requirements have a
format SYS-XXX (Requirement type identifier followed by a dash and three X)
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 5/20

1.2 List of Abbreviations

AD Applicable Document
ADCS Attitude Determination and Control Subsystem
ADR Active Debris Removal
AO Atomic Oxygen
AOCS Attitude and Orbit Control subsystem
AU Astronomical Unit
CDH Command and Data Handling subsystem
CDM Concept & Design Meeting
CONOPS Concept of Operations
EC European Commission
ECSS European Cooperation for Space Standardization
EDBDS Electrodynamic Boom Deorbiting System
EDT Electrodynamic Tether
EOL End-Of-Life
EOM End-Of-Mission
EPS Electrical Power Subsystem
ESA European Space Agency
ESOC European Space Operations Centre
ESTEC European Space Research and Technology Centre
EU European Union
FDIR Fault Detection, Isolation and Recovery
FP Final Presentation
FP7 Framework Programme 7
GA Grant Agreement
GEO Geostationary Orbit
GNC Guidance, Navigation, and Control subsystem
HEO High Earth Orbit
IADC Inter-Agency Space Debris Coordination Committee
ISO International Organization for Standardization
KO Kick-Off
LEO Low Earth Orbit
MEO Medium Earth Orbit
MM Micrometeoroids
MRR Mission Requirements Review
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 6/20

MS Milestone
MTR Mid-Term Review
NA Not Applicable
OD Orbit Determination
P/L Payload
PBS Product Breakdown Structure
PM Progress Meeting
PMD Post-Mission Disposal
PR Prototype Review
RAMS Reliability, Availability, Maintainability, Safety
RD Reference Document
ReVuS Reducing the vulnerability of space systems
RS Removal Subsystem
S/C Spacecraft (satellites and rocket bodies)
SDSS Self-deployable Deorbiting Space Structure
SE Systems Engineering
SPADES Solid Propellant Autonomous Deorbit Systems
SPOUA South Pacific Ocean Uninhabited Area
SOH State of Health
TBC to be confirmed
TBD to be determined
TBR to be refined
TC Telecommand
TCS Thermal Control Subsystem
TeSeR Technology for Self-Removal of S/C
TM Telemetry
TPR Transfer Phase Review
TRL Technology Readiness Level
TTC Telemetry, Tracking and Control subsystem
UK United Kingdom
UN United Nations
UNOOSA United Nations Office for Outer Space Affairs
WP Work Package
WPD Work Package Description
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 7/20

1.3 Definitions

End-of-life Point in time at which the system has lost one or more critical functionalities, thus
making the system no longer operational.
End-of- Point in time at which the mission has been completed, but the S/C or PMD
mission module retains full functionality. Can refer both to the S/C and the module.
Host The spacecraft that carries the PMD module.
spacecraft
Removal The removal of a S/C (spacecraft) implies that it is moved away from its
orbit either by de-orbit (enforcing the S/C to re-enter the Earth atmosphere) or
by re-orbit (enforcing the S/C to move into another less crowded orbit). The force
required to remove the S/C is provided by devices on board of the S/C (e.g.
propulsion system or a deployable structure using the atmospheric drag).
Platform See “PMD module platform”
PMD System which is attached to a S/C to control the removal in case of failure
module (e.g. loss of contact and/or loss of control) or at nominal end of operation.
PMD Part of the PMD module including all subsystems except from the Removal
module Subsystem. It interfaces to the host S/C and to the Removal Subsystem.
platform
Removal Subsystem of the PMD module which includes the device for removal (e.g.
subsystem propulsion, sail, balloon, tether, etc.). It has an interface to the PMD module
platform.
Small and Re-entry analyses show that small S/C (mass below 0.5t to 1t) are
large destroyed during re-entry and cause no harm on ground. Thus uncontrolled re-
spacecraft entry is allowed. Large S/C (above 0.5t to 1t) are not fully destroyed during re-
entry and may cause harm on ground, thus a re-entry into the South Pacific Ocean
Uninhabited Area is usually required. To ease the reading the threshold for small
S/C is set to <1t, and for large S/C >1t but it is no fix value and we are fully aware
of that for each S/C a re-entry analysis has to be done to decide if controlled
re-entry is required or if uncontrolled re-entry is allowed.
Spacecraft Satellite or launcher upper stage.
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 8/20

1.4 Applicable Documents

[AD1] TeSeR: “Technology for Self-Removal of Spacecraft”, Grant Agreement no. 687295,
20.10.2015.
[AD2] TeSeR project deliverable D2.7: “Interface Definition Document for removal
module/removal subsystem interface”, 30.09.2016
[AD3] TeSeR project deliverable D1.1: “High level user and mission requirements”, 12.05.2016

1.5 Reference Documents

[RD1] NASA Systems Engineering Handbook, NASA/SP-2007-6105 Rev1, December 2007
[RD2] Olivier de Weck. 16.842 Fundamentals of Systems Engineering, Fall 2009.
(Massachusetts Institute of Technology: MIT OpenCourseWare), http://ocw.mit.edu
(Accessed 20 Jun, 2016)
[RD3] Space Mission Analysis and Design, J. R. Wertz (ed.), Kluwer Academic Publishers, 1991
[RD4] NASA Fault Tree Handbook with Aerospace Applications, August 2002,
https://www.hq.nasa.gov/office/codeq/doctree/fthb.pdf
[RD5] Nancy Leveson, An STPA Primer Version 1, August 2013,
http://sunnyday.mit.edu/STPA-Primer-v0.pdf
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 9/20

2 Post-Mission Disposal module system and subsystems definition

An example of a Product Breakdown Structure (PBS) for a fully fledged and fully independent
PMD module is shown in Figure 2-1. The PMD module comprises of the usual space vehicle
subsystems plus the Removal Subsystem (RS). The PMD module interfaces to the host spacecraft
(S/C) via a first interface (IF-SC) and the PMD module platform interfaces to the RS via a second
interface (IF-RS) #2.

Depending on the results of this project it might be that some subsystems (e.g. thermal control,
attitude control) are not required, e.g. due to a share of resources of the host S/C as long as it is
active or because the RS is simple and does not require all subsystems.

Figure 2-1: Exemplary Product Breakdown Structure for a fully fledged and fully independent PMD module.
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 10/20

3 PMD module System requirements

System requirements are derived from the mission requirements as given in [AD3] and listed in
Table 3-1. In [AD3] a draft of the system requirements was given, which we used as a starting
point. For the reasons mentioned in Sec. 1.1 only the requirements (“shall” statements) and not
the goals (“should” statements) listed in [AD3] are taken into account for this document.

Table 3-1: PMD module System requirements

# Requirement Justification Comment

SR-010 The PMD module shall be attached to a
S/C on ground via a standardized
interface IF-SC.
SR-030 The PMD module shall be compatible
with different S/C via a standard
interface IF-SC.
Higher Level Req.: MR-010, n/a
MG-020, MR-070, MG-080
In a first step the PMD
module shall be designed to
attach it to a S/C on ground,
e.g. during integration phase.
Thus the module becomes an
external subsystem
specifically designed for
PMD.
Higher Level Req.: MR-010, It might be also
MG-020, MR-070, MG-080 possible to
To ensure that the PMD attach several
module can be attached to as PMD modules to
many S/C as possible. a S/C.

SR-050 The design of the PMD module shall be Higher Level Req.: MR-010, It might be also
scalable in size and mass so that it can MG-020, MR-070, MG-080 possible to
be used to remove different S/C. To ensure that the PMD attach several
module is versatile and can PMD modules to
be attached to S/C of a S/C.
different size, mass and orbit.
SR-070 The PMD module shall have at least one Higher Level Req.: MR-010, Depending on
standard interface IF-RS which allows MG-020, MR-070, MG-080 the results of
the attachment of different removal To ensure that the PMD the TeSeR
subsystems. module is versatile and can project different
be used to remove S/C of and/or multiple
different size and orbit. E.g. a removal
controlled de-orbit of large subsystems
S/C requires usually a might be
propulsion system. For an attached to the
uncontrolled de-orbit of a PMD module.
small S/C a drag
augmentation device might
be sufficient.
SR-080 The PMD module shall be able to Higher Level Req.: MR-090 We should
remove a S/C at any time with a success This is a downscaled/relaxed investigate if the
rate of 90% (TBC) version of SG-080. With this “at any time”
we do not need to remove stipulation also
S/C “independent of S/C has to be
status”, but remove S/C for relaxed
most of the EOL cases that we
expect to encounter
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 11/20

# Requirement Justification Comment

SR-100 It shall be possible to remotely activate Higher Level Req.: MR-100, In case of a
the PMD module. MR-110 highly advanced
To ensure that the PMD fully
module can be used in case autonomous
the S/C is out of control. and automatic
PMD module
everything from
failure detection
to final PMD
manoeuvre
could be
controlled fully
automatically
from the PMD
module without
ground station
involvement.
However for the
moment this
concept seems
unrealistic.
SR-120 The PMD module shall perform the PMD Higher Level Req.: MR-100
only after a command from ground. Requirement transferred as
is from higher level
SR-130 The PMD module shall not increase the Higher Level Req.: MR-110
operational risk of the host spacecraft.

SR-140 The PMD Platform shall not release any Higher Level Req.: MR-050
objects larger than TBD mm
SR-150 The PMD module shall be able to Higher Level Req.: MR-010,
generate and store electrical power MR-030
according to power budget TBD
SR-160 The PMD module shall be able to Higher Level Req.: MR-010,
distribute electrical power to its MR-030
subsystems according to their power
needs as defined in (TBD).

SR-170 The PMD module shall provide a Higher Level Req.: MR-010,
thermally controlled environment to its MR-030
subsystems compatible with their
survival temperature limits.

SR-180 The PMD module shall provide a Higher Level Req.: MR-010,
thermally controlled environment to its MR-030
subsystems compatible with their
operational temperature limits.

SR-190 The PMD module shall enable Higher Level Req.: MR-010,
communication with Ground as MR-030
required to operate the PMD module.

SR-200 The PMD module shall enable the Higher Level Req.: MR-010,
performance of orbit changes and MR-030
change of attitude depending on the
host S/C and RS used.

SR-210 The PMD module shall be able to host Higher Level Req.: MR-010, A convenient
its subsystems and the RS with a mass MR-030 way to put this
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 12/20

# Requirement Justification Comment

of up to TBD kg. could be as a
percentage of
the S/C mass
SR-220 The PMD module shall provide data Higher Level Req.: MR-010,
processing and storage capabilities to MR-030
its subsystems.

SR-230 In case the PMD module is sharing the Higher Level Req.: MR-110
resources of the host S/C, the PMD
module shall use no more resources
than the host-SC can spare at any given
time
SR-240 The PMD module shall not increase the Higher Level Req.: MR-060
probability of a catastrophic collision Requirement transferred as
with other space objects over the is from higher level
disposal lifetime.
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 13/20

4 PMD module subsystem requirements

The requirements for the various subsystems are derived from the system requirements as
listed in Table 3-1.

Table 4-1: PMD module TTC subsystem requirements

Comment/Verificatio
# Requirement Justification n
TTC- The TTC subsystem shall be able to Higher Level Req.: SR-
010 establish a link to Earth independent of 100, SR-190
the host S/C attitude In case a) the S/C is not
operational and b) to
not impose operational
requirements to the
host S/C (for antenna
pointing)
TTC- The TTC subsystem shall be compatible Higher Level Req.: SR- Possible requirement:
020 to [TBD Protocols] Ground Stations. 100, SR-190 Same type of ground
stations as host S/C.
How much effort is
needed to adjust TTC
to another ground
station network
(protocols, SW etc)?
TTC- TTC system shall be able to receive data Higher Level Req.: SR- 1 kbps is a first
030 at a data rate of 1 kbps (TBC). 100, SR-190 approximation for
“low” data rates for
command uplink
(Table 11-16 of [RD3])
TTC- The TTC system shall be able to transmit Higher Level Req.: SR- Low data rates are
040 data at a data rate1 kbps (TBC). 100, SR-190 expected, but TBD. 1
Operators should be kbps is a first
aware of PMD module approximation for
status in order to know “low” data rates for
if it can be activated. health and status
downlinking (Table 11-
PMD module should be
16 of [RD3])
able to send at least
attitude and att. rate
data in order to plan for
RS operations when S/C
is no longer operational
TTC- The TTC subsystem shall be scalable to Higher Level Req.: SR-
050 accommodate different RS. 070
TTC- The TTC subsystem shall be scalable to Higher Level Req.: SR-
060 account for removing different S/C. 050
TTC- The TTC subsystem shall not interfere Higher Level Req.: SR-
070 with host S/C communications 230
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 14/20

Table 4-2: PMD module CDH subsystem requirements

# Requirement Justification Comment/Verification

CDH-010 The CDH subsystem shall be able to Higher Level Req.: SR- Small amount of data
gather, store, and forward PMD module 100, SR-220 expected, TBD
State of Health (SOH) data. Operators should
know whether the
PMD module is going
to work
CDH-020 The CDH subsystem shall be able to Higher Level Req.: SR-
gather, store, and forward RS module 100, SR-220
State of Health (SOH) data. Operators should
know whether the
PMD module is going
to work
CDH-030 The CDH subsystem shall be able to Higher Level Req.: SR- For an advanced
receive RS module State of Health 070, SR-220 module this data
(SOH) data via IF-RS as described in Operators should be transfer could be also
[AD2]. aware of RS status and realized with a
whether it is going to contactless method, e.g.
work a wireless connection
thus not via IF-RS.
CDH-040 The CDH subsystem shall be able to Higher Level Req.: SR-
decrypt, verify, execute, and store a 100, SR-220
PMD module turning on command.

CDH-050 The CDH subsystem shall be able to Higher Level Req.: SR-
decrypt, verify, execute and store a 100, SR-220
removal initiation/RS activation
command.
CDH-060 The CDH subsystem shall be able to Higher Level Req.: SR-
forward a removal initiation/RS 100
activation command via IF-RS.
CDH-070 The CDH subsystem shall be scalable to Higher Level Req.: SR-
accommodate different RS. 070
CDH-080 The CDH subsystem shall be scalable to Higher Level Req.: SR-
account for removing different SCs. 050

Table 4-3: PMD module EPS subsystem requirements

# Requirement Justification Comment/Verification

EPS-010 The EPS subsystem shall provide power Higher Level Req.: SR-
to the RS during all mission phases as 150, SR-160
defined in [AD2]. Power for periodically
waking up RS from
hibernation and check
health, power RS
during PMD operations
(this is peak load, TBD)
EPS-020 The EPS subsystem shall power the PMD Higher Level Req.: SR- Peak power ~ 200W
module platform during all mission 150, SR-160 (TBR)
phases according the the power budget Power for periodically
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 15/20

# Requirement Justification Comment/Verification

TBD. waking up from
hibernation and
remaining on stand-by
until commanded to
hibernate again, power
all other subsystems
during PMD operations
EPS-030 The EPS subsystem shall be scalable to Higher Level Req.: SR-
accommodate different RS. 070
EPS-040 The EPS subsystem shall provide power Higher Level Req.: SR- For an advanced
to the RS via IF-RS as defined in [AD2] 070, SR-150, SR-160 module this could be
done via contactless
power transfer, e.g.
laser thus not via IF-RS.
EPS-050 The EPS subsystem shall be scalable to Higher Level Req.: SR-
account for removing different SC. 050
EPS-060 The EPS subsystem shall be scalable to Higher Level Req.: SR-
account for both de-orbiting and re- 050
orbiting SC

Table 4-4: PMD module TCS subsystem requirements

# Requirement Justification Comment/Verification

TCS-010 The TCS subsystem shall manage the Higher Level Req.: SR- Design cases:
PMD module thermally during all mission 170, SR-180 Hot case: PMD module
phases as defined in TBD document modelled as box on
reflective plane under
permanent
illumination. Cold case:
in permanent shadow
TCS-020 The TCS subsystem shall manage the RS Higher Level Req.: SR-
thermally during all mission phases as 170, SR-180
defined in [AD2]
TCS-030 The TCS subsystem shall be scalable to Higher Level Req.: SR-
accommodate different RS 070
TCS-040 The TCS subsystem shall be scalable to Higher Level Req.: SR-
account for removing different S/C. 050
TCS-050 The TCS subsystem shall have a thermal Higher Level Req.: SR-
connection to the RS via IF-RS as defined 070, SR-170, SR-180
in [AD2]

Table 4-5: PMD module ADCS Sensor subsystem requirements

# Requirement Justification Comment/Verification

ADCS- The ADCS Sensor subsystem shall sense Higher Level Req.: SR-
SEN- attitude and rotation rates with an 200
010 accuracy as described in [AD2]
ADCS- The ADCS Sensor subsystem shall Higher Level Req.: SR-
SEN- generate attitude control commands with
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 16/20

# Requirement Justification Comment/Verification

020 an accuracy as defined in [AD2] 200
ADCS- The ADCS Sensor subsystem shall send Higher Level Req.: SR-
SEN- attitude and rotation rate data to the 200
040 C&DH subsystem.
ADCS- The ADCS Sensor subsystem shall send Higher Level Req.: SR-
SEN - attitude control commands to the ADCS 200
050 Actuator subsystem.
ADCS- The ADCS Sensor subsystem shall be Higher Level Req.: SR-
SEN - scalable to account for removing different 050
060 SC.
ADCS- The ADCS Sensor subsystem shall be Higher Level Req.: SR-
SEN - scalable to accommodate for different RS 070
070 types

Table 4-6: PMD module Structures and Mechanisms requirements

# Requirement Justification Comment/Verification

SM-010 The PMD module structures shall Higher Level Req.: SR- Typical loads such as
withstand loads in all mission phases as 080 e.g. during launch and
defined in [AD2] S/C operations, but also
loads induced by RS, e.g.
C-RS thruster forces
and vibrations
SM-020 The PMD module structures shall be Higher Level Req.: SR-
scalable to accommodate different RS. 070
SM-030 The PMD module structures shall be Higher Level Req.: SR-
scalable to account for the removal of 050
different S/C.
SM-040 There shall be no detachable parts in the Higher Level Req.: SR-
PMD module larger than TBD mm 140
Detachable parts can
generate additional
space debris
SM-050 The PMD module structures shall be Higher Level Req.: SR-
physically connected to IF-SC 010, SR-030

SM-060 The PMD module structures shall be Higher Level Req.: SR-
physically connected to IF-RS 070

Table 4-7: PMD module ADCS Actuator subsystem

# Requirement Justification Comment/Verification

ADCS- The ADCS Actuator subsystem shall Higher Level Req.: SR-
ACT- receive attitude control commands by the 200
010 ADCS Sensor subsystem
ADCS- The ADCS Actuator subsystem shall Higher Level Req.: SR-
ACT- implement attitude control commands by 200
020 the ADCS Sensor subsystem
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 17/20

# Requirement Justification Comment/Verification

ADCS- The ADCS Actuator subsystem shall be Higher Level Req.: SR-
ACT-- scalable to accommodate different RS. 070
030
ADCS- The ADCS Actuator subsystem shall be Higher Level Req.: SR-
ACT-- scalable to account for the removal of 050
035 different S/C.
ADCS- The ADCS Actuator subsystem shall be Higher Level Req.: SR-
ACT - able to de-tumble the S/C to RS 200
040 operational attitude and rotation rates
before RS activation, as defined in [AD2]
ADCS- The ADCS s Actuator ubsystem shall be Higher Level Req.: SR-
ACT - able to control the required attitude and 200
050 rotation rates during RS operation as
defined in [AD2]
ADCS- Residuals of a possible propellant used in Higher level
ACT - ADCS Actuator subsystem shall be less requirement SR-140
060 than TBD mm

Table 4-8: RS subsystem requirements

# Requirement Justification Comment/Verification

RS-010 The RS shall generate forces necessary Higher Level Req.: SR-
for PMD 080
As foreseen in the
CONOPS for each RS
RS-020 The RS shall transfer removal forces to Higher Level Req.: SR-
IF-RS 070, SR-080
RS-040 The RS shall be able to send RS module Higher Level Req.: SR-
State of Health (SOH) data via IF-RS as 070
defined in [AD2]
RS-050 The RS shall be able to send telemetry Higher Level Req.: SR-
data to the PMD module via IF-RS as 070
defined in [AD2]
RS-060 The RS shall be scalable to account for the Higher Level Req.: SR-
removal of different S/C. 050
RS-080 Residuals of a possible propellant used in Higher level
the RS shall be less than TBD mm requirement SR-140
RS-090 The RS shall have a probability of Higher Level Req.: SR-
activating without being commanded < 230
TBD %

Table 4-9: Interface IF-S/C requirements

# Requirement Justification Comment/Verification

IF1-010 IF-SC shall withstand mechanical loads in Higher Level Req.: SR-
all mission phases as defined in [AD2] 010, SR-030, SR-080
IF1-020 IF-SC shall be physically connected to the Higher Level Req.: SR-
PMD module structure 010, SR-030, SR-080
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 18/20

# Requirement Justification Comment/Verification

IF1-030 IF-SC shall transfer removal forces from Higher Level Req.: SR-
the PMD module to the S/C 010, SR-030, SR-080
IF1-040 IF-SC shall be physically connected to the Higher Level Req.: SR-
S/C structure 010, SR-030, SR-080

Table 4-10: Interface IF-RS requirements

# Requirement Justification Comment/Verification

IF2-010 IF-RS shall withstand mechanical loads in Higher Level Req.: SR-
all mission phases as defined in [AD2] 080
IF2-020 IF-RS shall transfer removal forces from Higher Level Req.: SR-
the RS to the PMD module 070, SR-080
IF2-030 IF-RS shall be able to forward a removal Higher Level Req.: SR- For an advanced
initiation/RS activation command from 070, SR-080 module this data
the PMD module to the RS transfer could be also
realized with a
contactless method, e.g.
a wireless connection
thus not via IF-RS.
IF2-040 IF-RS shall transfer power from the PMD Higher Level Req.: SR- For an advanced
module to the RS as defined in [AD2] 070, SR-080 module this power
transfer could be also
realized with a
contactless method, e.g.
laser thus not via IF-RS.
IF2-050 IF-RS shall provide a thermal connection Higher Level Req.: SR-
between the PMD module and the RS 070, SR-080
IF2-060 IF-RS shall physically connect the RS to Higher Level Req.: SR-
the PMD module structure 070, SR-080
IF2-080 The RS shall be able to send RS module Higher Level Req.: SR-
State of Health (SOH) data via IF-RS as 070, SR-080
defined in [AD2]
IF2-090 The RS shall be able to send telemetry Higher Level Req.: SR-
data to the PMD module via IF-RS as 070, SR-080
defined in [AD2]

Table 4-11: Operations requirements

# Requirement Justification Comment/Verification

OPS- It shall be possible for the operators to be Higher Level Req.: SR- The logic behind the
020 made aware of the status of the PMD SR-080 two S/C orbits period
module within 2 S/C orbits (TBC) Coming from SR-080, before uploading
especially the “at any command in this and
time” part following entries, is that
we want to allow for at
least one ground station
overpass for downlink
of necessary telemetry
and one ground station
overpass for uplink of
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 19/20

# Requirement Justification Comment/Verification

any commands
OPS- It shall be possible for the operators to be Higher Level Req.: SR-
030 made aware of the status of the RS within SR-080
2 S/C orbits (TBC) as described in [AD2] Coming from SR-080,
especially the “at any
time” part

OPS- It shall be possible for the operators to be Higher Level Req.: SR- See Platform ops in
040 made aware of the status of the PMD SR-080 [AD2]
module at periodic intervals (TBC) as The operators should
described in [AD2] be aware of the status
of the PMD module and
whether it can perform
the PMD at the
required time

OPS- The operators shall be able to send an Higher Level Req.: SR- See Platform ops in
050 activation command to the PMD module SR-080, SR-100 [AD2]
within a period of two orbits (TBC) from Coming from current
any given time. CONOPS
OPS- The operators shall be able to send a Higher Level Req.: SR- See Platform ops in
060 activation/go back to stand-by command SR-080, SR-100 [AD2]
to the PMD module within a period of two Coming from current
orbits (TBC) after the PMD module has CONOPS
been activated
OPS- The operators shall be able to send a Higher Level Req.: SR- See Platform ops in
070 PMD initiation command to the PMD SR-080, SR-100 [AD2]
module within a period of two orbits Coming from current
(TBC) after the PMD module has been CONOPS
activated.
OPS- The operators shall be able to send a Higher Level Req.: SR- See Platform ops in
080 PMD initiation command to the PMD SR-080, SR-100 [AD2]
module within a period of two orbits Coming from current
(TBC) after the PMD preparation phase CONOPS
has been completed
OPS- The operators shall be able to send Higher Level Req.: SR- See Platform ops in
090 commands necessary for PMD to the PMD SR-080, SR-100 [AD2]. In case of a 25
module during PMD operations (TBC) Coming from current year removal this
CONOPS. requirement might not
be applicable.
OPS- The PMD module shall not increase the Higher Level Req.: SR- The appropriate
100 operational risk of the host spacecraft. 130 reliability analysis
Higher level (FTA, FMECA [RD4],
requirement taken as is STPA [RD5]) will be
performed on the PMD
platform in order to
demonstrate this
OPS- The PMD module shall have a probability Higher Level Req.: SR- The appropriate
110 of initiating PMD without being 230 reliability analysis
commanded < TBD % (FTA, FMECA [RD4],
STPA [RD5]) will be
performed on the PMD
 TeSeR D2.3
Title: System and subsystem requirements document
Issue, Date i1.0, 30.09.2016
Page 20/20

# Requirement Justification Comment/Verification

platform in order to
demonstrate this

Table 4-12: Draft requirements to host-S/C

# Requirement Justification Comment/Verification

HSC- The host S/C shall passivate its ADCS Higher Level Req.: SR-
010 before the initiation of the PMD phase 150
Automatic processes on
the host-S/C (if left
active after EOL), will
try to counteract any
torque applied to the
S/C. These have to be
therefore deactivated
before PMD operations
initiation
HSC- The host S/C shall fully passivate itself Higher Level Req.: SR-
020 before the initiation of the PMD phase in 150
case the PMD phase takes longer than 1 This is required by ISO
year. TBD.

------- End of document -------