Error! Unknown document property name.
esoc
E u r o p e a n
S p a c
R o b e r t - B o
D
6
4
2
9
3
G
e
r
T
+
4
9
(
F
+ 4 9
( 0
w
w
w
.
File Based Operations Study
Statement of Work
Prepared by
Reference
Issue
Revision
Date of Issue
Status
Document Type
Distribution
Error! Unknown document property name.
Error! Unknown document property name.
Error! Unknown document property name.
Error! Unknown document property name.
Error! Unknown document property name.
Error! Unknown document property name.
Error! Unknown document property name.
e
s
0
)
e
O p e r a t i o n s
C e n
c h - S t r a s s e
D
a
r
m
s
t
a
m
a
n
)
6
1
5
1
9
6 1 5 1
9 0 4
s
a
.
i
n
t r e
5
d
t
y
0
0
9 5
t
Error! Unknown document property name.
TABLE OF CONTENTS:
1 INTRODUCTION ....................................................................................... 4
1.1 Purpose and Scope of the Document ................................................................................4
1.2 Background of the Project................................................................................................. 5
1.3 Objectives of the Activity ..................................................................................................6
1.3.1 Space Segment ................................................................................................................ 8
1.3.2 Ground Segment ........................................................................................................... 10
1.3.3 Operations Scenarios to be Considered ........................................................................ 11
1.4 References ....................................................................................................................... 19
1.4.1 Applicable Documents .................................................................................................. 19
1.4.2 Reference Documents .................................................................................................. 22
1.4.3 Definition and Terms ....................................................................................................23
1.4.4 Acronyms and Abbreviations ....................................................................................... 24
2 ASSUMPTIONS, CONSTRAINTS AND CUSTOMER FURNISHED ITEMS .. 25
2.1 Assumptions ....................................................................................................................25
2.2 Constraints ......................................................................................................................25
2.2.1 General Constraints.......................................................................................................25
2.2.2 Intellectual Property Rights Constraints ......................................................................25
2.2.3 SDE Constraints ............................................................................................................25
2.2.4 Baseline Constraints ..................................................................................................... 26
2.2.5 Implementation Constraints ........................................................................................ 26
2.2.6 Other Constraints ......................................................................................................... 26
2.2.7 Third Party Products Constraints ................................................................................. 27
2.3 Customer Furnished Items ............................................................................................ 28
3 STUDY REQUIREMENTS ........................................................................ 30
3.1 User Requirements ......................................................................................................... 31
3.2 Functional requirements ............................................................................................... 34
3.2.1 Space Segment .............................................................................................................. 34
3.2.2 Ground Segment ...........................................................................................................35
3.3 Development and demonstration requirements ........................................................... 38
3.4 Interface requirements ................................................................................................... 41
3.5 Resources requirements ................................................................................................ 42
3.5.1 Space Segment .............................................................................................................. 42
3.5.2 Ground Segment .......................................................................................................... 42
3.6 Design requirements ...................................................................................................... 43
3.7 Implementation requirements ...................................................................................... 44
3.8 Security and Privacy requirements .................................................................................45
3.9 Quality requirements ..................................................................................................... 46
3.10HMI requirements .......................................................................................................... 47
3.11 Reuse and reusability requirements .............................................................................. 48
3.12 Verification, Validation and Acceptance Requirements ............................................... 49
4 WORK TO BE PERFORMED ..................................................................... 51
4.1 Project Logic .................................................................................................................... 51
4.2 Project Phases ................................................................................................................. 51
Page 2/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
4.2.1 WP-01, Management .....................................................................................................52
4.2.2 WP-02, Requirements Engineering ..............................................................................54
4.2.3 WP-03, Architecture and Interface Design .................................................................. 55
4.2.4 WP-04, Design and Implementation ............................................................................56
4.2.5 WP-05, Provisional Software Acceptance ..................................................................... 57
4.2.6 WP-06, Final Software Acceptance............................................................................... 57
4.2.7 WP-07, Warranty ......................................................................................................... 58
4.3 Meetings ..........................................................................................................................59
4.4 Work Location and Environment .................................................................................. 60
5 DELIVERABLES, SCHEDULE AND MILESTONES ................................... 61
5.1 Deliverables ..................................................................................................................... 61
5.2 Schedule and Milestones ................................................................................................ 67
Page 3/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1
INTRODUCTION
1.1
Purpose and Scope of the Document
The purpose of this document is to provide the technical Statement of Work (SOW) for the
“File Based Operations Study” referred from now on as “FiBOps”.
This document describes the activities to be executed and the deliverables required by the
European Space Agency as part of the Project.
It will become part of the contract and shall serve as an applicable document throughout
the execution of the Project (with possible amendments recorded during the Kick-Off
meeting).
The document is structured as follows:





Chapter 1 defines the background, objectives and documents applicable to the
project.
Chapter 2 defines the assumptions, constraints and CFIs applicable to the project.
Chapter 3 defines the requirements applicable to the project.
Chapter 4 defines the phases and management organisation applicable to the
project.
Chapter 5 defines the deliverables, schedule and milestones applicable to the
project.
Page 4/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.2
Background of the Project
ESA missions are currently operated using packets in accordance with the ECSS Packet
Utilisation Standard (ECSS E-70-41, AD-0032). In the recent past, missions have been
increasingly moving to off-line operations concepts. With file transfer increasingly
becoming common functionality for ESA missions recently launched and in development
(Rosetta, Mars Express, Venus Express, BepiColombo, Gaia), data files are being used
more and more e.g. for the upload of sets of telecommands onto the on-board Mission
Timeline, memory maintenance or upload of On-board Control Procedures. However, on
the downlink, missions still continue to transmit data on a packet-by-packet basis.
Operations at packet-level on the downlink are considered adequate for engineering type
of data (housekeeping, command verification, events), which are made available in near
real-time on the ground as there is direct visibility between control centre and the
controlled space asset. For this type of data, a packet carries operational information
independently from its contents and thus represents more than just a transfer layer.
Science data however are not normally processed in near real-time and normally not at the
control centre. For this type of data, the formatting into packets is not much more than an
additional transfer layer that is not really justified. On the end user side, the packets are
anyhow immediately broken up to reconstruct the scientific data that they carry. For this
type of data, it seems that moving to a file based approach, where each file is formed of a
self-consistent set of data (e.g. one image) would simplify the downlink operation as well
as the distribution to the end user while enabling on-board post-processing of the data and
selection of the data sets to be returned to ground. Similar considerations can be made for
other on-board generated products used for spacecraft ‘maintenance’ operations (e.g.
memory dumps, reports, etc.).
The use of a file based data delivery is made possible by the availability of standardised file
transfer protocols. The ECSS Packet Utilisation Standard (ECSS E-70-41) specifies the
TM/TC interface for large data transfer (Service 13), including specific guidelines on how
to define a closed-loop protocol using the TM/TC interface, however without standardising
the management and the utilisation of files resulting from the data transfer managed via
Service 13. CCSDS has defined a standard for File Delivery Protocol (CFDP), which has
been made applicable at ESA. Both standards can be operated open-loop (i.e. transfer not
ensuring completeness) or closed-loop (i.e. transfer with automatic detection of missing
parts and request for retransmissions, thus ensuring completeness). The CFDP standard
even opens the door to transmission via way-points (e.g. relay/orbiter type of mission).
The use of closed-loop file transfer protocol brings some additional operational advantages
compared to the file based downlink as it automates the retransmission of lost data
elements. Such an automated retransmission capability may be mandatory when the
space-ground link is not sufficiently reliable e.g. when using a Ka-band downlink, as this
link is strongly weather-dependent.
Page 5/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
Future ESA missions will also involve complex topologies which potentially include multihop and multi-agency scenarios. For these types of missions, the adoption of files as a basic
mechanism to deliver/receive data is of paramount importance.
Page 6/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.3
Objectives of the Activity
This activity is intended to demonstrate the feasibility of end-to-end file based operations,
based on the concept described in [AD-0002], and using the RASTA test bed to simulate
the spacecraft functionality and S2K for control system functionality. It should be noted
that the intention is not to further investigate the suitability of CFDP (this has already been
covered in RD-0004), but rather to look at the changes to the ground and space segments
that need to be made to support the use of file based operations. With this in mind CFDP
shall be used as the mechanism for transporting all files required. Essentially the aims of
the project are to develop/study:





a set of upgrades to Packet Utilisation Services (PUS) to provide File Utilisation
Services (FUS)
analyse the use or not of the CFDP meta data to control the transfer
underlying use of (raw) CCSDS packet or PUS packet (makes quite some difference
in overhead and maybe in the ESOC ground infrastructure)
Verification that the file a packet store services are complete for ops purposes
detailed user scenarios and metrics to be measured
The following phases/tasks are foreseen in the course of the study:







Requirements Engineering
Architecture and Interface Design
Design and Implementation
Provisional Software Acceptance
Final Software Acceptance
Warranty
Flexibility
With respect to the Requirements Engineering this will involve expanding on some of the
concepts outlined in [AD-0002] and this Statement of Work, detailing the outcome in
Technical Notes as specified later in this document. These technical notes will then be used
to derive some of the software requirements required for the demonstration.
It is anticipated that an iterative methodology will be adopted with respect to the design
and implementation of the software so as to ensure that the delivered product is in line
with the goals of the demonstration.
As noted above the purpose of the study is to demonstrate the feasibility of end-to-end file
based operations. It shall be assumed that it is an ESA mission that is being dealt with and
that the Packet Utilisation Standard is implemented on all space assets in the scenarios to
be investigated as is the Spacecraft On-board Interface Services (SOIS). This latter can be
thought of as providing file and packet store services that provide the basis for file
management services on-board. The file utilisation services that are the main topic of the
study will make use of the file management services provided by SOIS.
Page 7/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
Appendix B of [AD-0002] provides a set of requirements that have been identified as being
necessary to support file based operations. These cover aspects of file based operations
related to file utilisation on ground, file utilisation on-board, file management and access
and file transfer.
Page 8/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.3.1
Space Segment
From these requirements in Appendix B of [AD-0002] the conceptual protocol stack
shown in the following figure has been derived. It can be seen from this that what is
envisaged involves an extension to the current PUS services and expose the functionality of
CFDP, SOIS and File Utilisation (FUS) via new PUS services.
PUS Svcs
1-N
File Transfer File Mngt.
PUS Svcs PUS Svcs
File Util.
PUS Svcs
Application
PUS
CFDP
File
Utilisation
SOIS
Transport
Network
Data Link
Space Packet Protocol
TM Space
Data Link
Prox 1. Space
Data Linkl
TC Space
Data Link
COP1
Conv. Code
Physical
AOS Space
Data Link
RS. Code
Turbo Code TM Frame Sync
CLTU & PLOPsl BCH Code
Radio Frequency and Modulation
Figure 1: CCSDS Space/Ground Communications Protocol Stack Showing PUS,
SOIS and FUS
NOTE: Encapsulation packets are not shown on the above figure as they are not
(Some details of lower layers omitted)
considered in the scope of this study.
Access to CFDP services can either be or from PUS services or by commands sent directly
to the CFDP entity. The reason for this is that while the direct approach is more efficient
(less overhead) there are occasions where it may be necessary to access the CFDP
functionality from other PUS services. This could be the case for example if it is required to
Page 9/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
send CFDP commands from the on-board queue (e.g. as time-tagged commands), a
possible scenario where this may be required is described in section 1.3.3.2.
The family of CCSDS SOIS standards is in charge of defining on-board interfaces involving
the complete spacecraft, with the goal to improve the process of spacecraft development
and integration as well as the quality of the finished product. It also aims at facilitating the
adoption of new hardware and software technologies supporting international on-board
interface interoperability. Particularly relevant to File based Operations is the SOIS
Standard defining the File and Packet Store Services [AD-0031].
As with the CFDP functionality it is believed that the SOIS File and Packet Store Services
will need to be available via PUS services.
The File Utilisation Services (FUS) have been identified by the File Based Operations
Working group and requirements for these are specified in Appendix B.2 of [AD-0002].
These form one of the core activities of the study. Access to the FUS is expected to be
provided by extensions to the PUS.
Page 10/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.3.2
Ground Segment
As well as extensions to the functionality of the on-board systems there will also need to be
enhancements to the ground segment to support file based operations, this forms the other
main activity of the study.
The following figure (derived from [AD-0002]) shows the high-level view of the various
components involved in the file based operations support in the future mission control
system infrastructure. From this it has been identified that in order to support file based
operations a number of new applications are required. The user requirements of these are
described in Section 3 of this document.
File Transctn.
Manager
File Transctn.
History Log
File Recptn.
History Disp.
File Transmn.
History Disp.
On-board File
Store
Browsr.
User Applications supporting Ground/Space Files Exchange
File Transactions
Processor
Transactions
History Log
S/C File
Store Image
TM
Data
File Transactions API
Files
Files
Utilisation
Apps
File Delivery
Ground File
Store
Protocol
Command
Source
TM packets
TM Receiver & Distributor
TC Handler & Releaser
Network Interface (SLE Service User)
Figure 2: High-level architecture of the Control System components supporting
File based Operations
NOTE: The above figure shows the architecture as it would be when fully implemented.
For the purposes of this study adaptors will be required to interface the S2K TM receiver
and TC Releaser directly to RASTA via space packets (see SR-0038).
One of the drivers behind the above high-level architecture is the “File Transactions” API.
The intention here is that an API should be provided such that it is possible to operate on
the files on both ground and space in the same manner. The operations that need to be
provided by this API are as per the SOIS services described in [AD-0031].
Page 11/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.3.3
Operations Scenarios to be Considered
This section defines the various monitoring and control scenarios which are considered as
relevant to the study. Section 5.4.2 of [AD-0002] provided the starting point for these.
Some modifications have however been made and the following scenarios are considered
relevant to this study:
1. Spacecraft Control with direct access to uplink/downlink
2. Spacecraft Control with direct access to uplink/downlink. File Delivery to ground
station
3. Spacecraft Asset Control via Relay
The proposed approach for the above scenarios is described in the following sections.
Page 12/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.3.3.1 Spacecraft Control with direct access to uplink/downlink
This scenario is taken from Section 5.4.2.1 of [AD-0002] and is illustrated in the following
figure.
PUS
CFDP Class 1 or 2
PUS
CFDP
CFDP
SLE
PUS
SLE
TM/TC
Terrestrial
Bearer
Terrestrial
Bearer
TM/TC
SLE Protocols
Over TCP/IP
Control Centre
CCSDS Space Link Protocols
Ground Station
Spacecraft
Figure 3: Proposed solution for file based Spacecraft Control operations
Figure 3 above shows the proposed solution to accommodate file based operations in the
standard scenario of spacecraft monitoring and control based on a ground station network
ensuring direct uplink and downlink visibility. The proposed solution is based on the
following data exchange protocols:




SLE (over TCP/IP) between Control Centre and Ground Station. This ensures
complete compatibility with the existing ground infrastructure and also crosssupport capabilities. It should be noted that in this solution the SLE Protocols
dealing with TM Frames and TC CLTUs can still be used i.e. the adoption of packet
level protocols is not imposed;
CCSDS Space Packets between Ground Station and Spacecraft. Again, this ensures
complete compatibility with the existing ground infrastructure and also crosssupport capabilities;
Packet based Services (PUS) between the Control Centre and spacecraft;
CCSDS File Delivery Protocol operated in closed-loop and/or open-loop between
Control Centre and Spacecraft. This enables a peer-to-peer relationship between
Control Centre and Spacecraft for the exchange of files in both directions. The
natural choice for this protocol is CFDP but restricted to its basic operations i.e.
without multi-hop capability.
The solution proposed above is based on a clear separation of the protocols between the
Control Centre and the Spacecraft (namely, PUS and CFDP) and the protocols between the
Page 13/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
service provider and the mission assets (namely, SLE and TM/TC Packets over the Space
Link).
Page 14/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.3.3.2 Spacecraft Control with direct access to uplink/downlink. File Delivery
to ground station.
This scenario is based on Section of 5.4.2.1 of [AD-0002] but is modified in that downlink
of the files may be terminated at the groundstation. This implies that there needs to be a
CFDP entity at the groundstation, however due to operational concerns direct uplink of
CFDP PDUs from the groundstation is not permitted. Instead these PDUs would be
forwarded to the OCC for uplink via the control system commanding chain.
Such a scenario is similar to that which exists for some current Earth Observation where
payload data (and stored housekeeping data) is downlinked via X-band to the
groundstation, where it is received and stored by the payload data system. The payload
data is then transmitted to the data processing centre without passing through the OCC.
(The stored housekeeping data is stored in files of telemetry frames that are retrieved by
the control system at the OCC and “played back” into the system after the pass). It should
also be noted that some passes may be downlink only, i.e. there is no uplink during the
pass.
This is illustrated in the following figure.
PUS
CFDP Class 1 or 2
CFDP
(Downlink only)
PUS
CFDP
CFDP
SLE
CFDP
PUS
SLE
TM/TC
Terrestrial
Bearer
Terrestrial
Bearer
TM/TC
CFDP PDUs for Uplink via OCC
TBD Protocol
CCSDS Space Link Protocols
SLE Protocols
Over TCP/IP
Control Centre
Ground Station
Spacecraft
Figure 4: Proposed solution for file based Spacecraft Control operations. File Delivery to
ground station
Figure 4 above shows the proposed solution to accommodate file based operations in the
scenario of spacecraft monitoring and control based on a ground station network ensuring
Page 15/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
direct uplink and downlink visibility, but that also may terminate downlink of files at the
groundstation
The proposed solution is based on the following data exchange protocols:






SLE between Control Centre and Ground Station. This ensures complete
compatibility with the existing ground infrastructure and also cross-support
capabilities. It should be noted that in this solution the SLE Protocols dealing with
TM Frames and TC CLTUs can still be used i.e. the adoption of packet level
protocols is not imposed;
CCSDS Space Packets between Ground Station and Spacecraft. Again, this ensures
complete compatibility with the existing ground infrastructure and also crosssupport capabilities;
Packet based Services (PUS) between the Control Centre and spacecraft;
CCSDS File Delivery Protocol operated in closed-loop and/or open-loop between
Control Centre and Spacecraft. This enables a peer-to-peer relationship between
Control Centre and Spacecraft for the exchange of files in both directions. The
natural choice for this protocol is CFDP but restricted to its basic operations i.e.
without multi-hop capability.
Additionally the use of a File Delivery Protocol operated in closed-loop and/or
open-loop between the Spacecraft and the Ground Station, with the modification
that there is no direct generation of CFDP PDUs in the groundstation as received
CFDP PDUs are forwarded to the OCC for processing and generation of uplink
CFDP PDUs to be sent via the telecommand chain of the Control System.. The
natural choice for this protocol is CFDP but restricted to its basic operations i.e.
without multi-hop capability.
The use of a TBD protocol to forward received File Delivery Protocol PDUs from the
groundstation to the OCC.
The following figure (Figure 5) illustrates a functional view of this scenario. From this it
can be seen that there are some issues that need to be considered:
1.
2.
3.
If it is not possible to downlink a file completely during a pass with a particular
groundstation then the remainder of the file must be downlinked during
subsequent passes with that groundstation.
If a file has been downlinked to a particular groundstation then any requests for
retransmission of parts of that file must be executed when the spacecraft is in
communication with that groundstation.
Some groundstation passes may take place with downlink only, i.e. no uplink occurs
during the pass.
One solution to these may be to use the capability that CFDP has that allows the status of
the link to any particular CFDP entity to be set in the local CFDP entity MIB. Thus if the
link status of a CFDP entity is such that downlink is possible then the on-board CFDP
entity would downlink the appropriate CFDP PDUs. This may also resolve the issue of
Page 16/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
Payload
Data System
Packetiser
File
Store
G/S 1
CFDP
Entity
CFDP
User
TMTCS
CFPD PDU
Forwarder
MCS
TM Chain
TC
Chain
MIB
TC Time
Tagger ?
CFDP
Entity
File
Store
CFDP
User
MIB
GS 1 CFPD GS 2 CFDP
PDUs
PDUs
Payload
Data System
G/S 2
TMTCS
CFDP PDU
Receiver
Packetiser
File
Store
CFDP
Entity
CFDP
User
CFDP PDU
Forwarder
MIB
downlink only passes, as the appropriate CFDP PDUs (for retransmission, requesting file
downlink etc.) could be uplinked some time previously.
Figure 5: File based Spacecraft Control operations. File Delivery to ground station,
functional view.
There are still some open issues with this, the most obvious being how the status of the link
from the on-board CFDP entity to the CFDP entity at any particular groundstation is
determined. One approach may be to have an on-board application that monitors the
status of the TM and has access to orbit information that enables it to determine which
groundstation is visible, this may be insufficient however in the event that more than one
groundstation used by the mission is visible at the same time.
As can be seen there are still a number of issues with this scenario where further analysis is
required.
Page 17/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.3.3.3 Spacecraft Asset Control via Relay
This scenario is described in Section of 5.4.2.2 of [AD-0002] and is illustrated in the
following figure. Note that what if contained here is somewhat modified from the solution
proposed in section 5.4.2.2 of [AD-0002]. This is because there is currently on-going
activity in CCSDS to define a terrestrial file transfer mechanism. In view of this, and since
the purpose of the study is to investigate file based operations, not to worry about how the
files get from A to B, it is assumed that some form of terrestrial file delivery mechanism is
used to transfer files between the Space Asset Control Centre and the Relay Control Centre.
For the purposes of the study the terrestrial file delivery mechanism can be assumed to be
SFTP. Delivery of metadata associated with the file can be achieved by storing this in an
XML file and tarring this together with the file to be delivered via SFTP. This will require a
small application at the Relay Control Centre that is responsible for;


On reception of a file from the Space Asset Control Centre untarring the file, and
inserting the data file into CFDP. The associated metadata extracted from the XML
file shall either be inserted into CFDP using the CFDP metadata capability or sent
via PUS depending on the outcome of a trade-off to be carried out as part of this
study.
NOTE: The file received from the Space Asset Control Centre could contain two
sets of metadata:
1. The first being data for the ground segment related to the processing of the
file on the ground (e.g. timing constraints on when the file should be
uplinked etc.)
2. The second being data for the spacecraft related to the processing of the file
on-board.
On delivery of a file for the Space Asset Control Centre extracting the appropriate
metadata either from CFDP or delivered via a PUS service (depending on the result
of the trade-off), insert these into an XML file and tar this with the data file
received.
There are also additional consideration that apply to the relay. It is not sufficient to assume
that use of files to the Space Asset will provide all the commanding/telemetry capabilities
required. For instance in the event that the space asses is in a safe mode it will not have the
capability to process files. In this situation the Relay will need to be able to send direct
commands to the space asset. This could be achieved by transmitting a file containing the
required command to the relay which then extracts them and transmits them to the Space
Asset as PUS TCs when the Relay has visibility of the Space Asset. Similarly it is necessary
to consider the case of the Relay receiving PUS TM from the Space Asset which it then
constructs into a file which is then downlinked to the Relay Control Centre via CFDP, from
where it can be delivered to the Space Asset Control Centre using a terrestrial file transfer
protocol.
There may also be the case where TC and TM packets are routed via the relay, i.e. TC
packets sent from the relay control centre are routed to the space asset via the relay and
TM packets from the space asset are routed to the relay control centre , again via the relay.
Page 18/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
PUS
PUS
CFDP Class 1 or 2
PUS
CFDP
CFDP
SLE
Terrestrial
Bearer
Space
Asset
Control
Centre
SLE
Terrestrial
Bearer
Terrestrial File
Transfer Protocol
Terrestrial
Bearer
PUS
PUS
CFDP
CFDP
File Proc.
CFDP Store & Forward
TM/TC
SLE Protocols
Over TCP/IP
Relay
Control
Centre
CFDP Class 1 or 2
TM/TC
Proximity-1
Proximity-1
Proximity-1
CCSDS Space
Link Protocols
Ground Station
PUS
Relay
Space
Asset
Figure 6: Proposed solution for file based Space Asset Control operations via a Relay in
space
Figure 6 above shows the proposed solution to support monitoring and control operations
of space assets which are not directly visible from their Control Centre (i.e. they rely on a
data relay in space). The proposed solution is based on the following data exchange
protocols:










All communication with the Space Asset is via the Relay
Communication links are disjoint so that all data sent to and from the Space asset
must first be stored on the Relay
The Space asset control centre prepares files containing PUS based commands,
Direct TCs and files.
The Space asset control centre receives files containing PUS based TM, Direct TM
and files
The communication associated with the operation of the Relay is based on real-time
Packet TM/TC and CFDP file transfer
The underlying transfer service for CFDP is the Space packet protocol
the use of terrestrial file delivery mechanism between the Space Asset Control
Centre and the Relay Control Centre. For the purposes of the study this can be
assumed to be SFTP. The exchanged files shall be accompanied by metadata which
describe the required delivery service. It is assumed that this metadata is delivered
in an XML file that is tarred with the data file.
The Relay CC receives files from the Lander CC, these are transmitted to the orbiter,
along with meta data, using CFDP.
At the Relay the received files are processed by an onboard application and,
depending on content and meta data, sent to the space asset using CFDP or the
packet service of the Prox-1 protocol
The return direction is similar: The relay receives files and space packets from the
space asset. These are transmitted to the Relay CC using CFDP. The Relay CC
forwards the files using a terrestrial file transfer protocol
Page 19/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.

A number of trade-offs need to be considered by the study:
o The use of CFDP class 1 or 2
o The store and forwarding function within the relay. Note that CFDP class 3
and 4 are not proposed for use and the SFO is probably best replaced by a
dedicated application able to deal with both files and direct TM/TC
o The format and contents of the meta data associated with the file transfer
o The use of meta data transfer capability of CFDP (message to user)
The following diagram shows a more detailed view of the various interactions in this
Files
File, SPP,
Direct TM/TC proxy
(mission specific app)
PUS
Packets
Direct
TM/TC
Files
Space - Ground
CCSDS Protocols
Files
Terrestrial
Networks
CSTS
File
Forward/
Return
CSTS
File
Forward/
Return
CFDP
CFDP
SPP
SPP
TM, TC, AOS
CSTS
Ground File
Transfer Services
Terrestrial Networks
TM/TC,
AOS
CFDP
CFDP
SPP
SPP
CFDP
SPP
Direct
TM/TC
Prox-1
Prox-1
Relay
CFDP, Space Packet
and TM/TC/AOS
Frame services
CFDP
SPP
Packet
SAP
TM, TC, AOS
Cod. RF & Mod
Relay CC
Spacelink
PUS
Packets
Lander - Orbiter
CCSDS Protocols
Packet
SAP
Cod. RF & Mod
Space Asset
CC
Files
File, SPP,
Direct TM/TC Proxy
(mission specific application)
Prox-1
Space Asset
CFDP, Space Packet
and Prox-1 Frame
services
Spacelink
scenario.
Figure 7: File based Space Asset Control operations via a Relay in space – interactions.
Page 20/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.4
References
1.4.1 Applicable Documents
The following documents are to be considered as applicable to the Project:
Id
Title
Reference
Ver.
Date
AD-0001 ECSS-E-ST-40C Space
QMS-EIMO-GUID-CKL- 1.0
engineering - Software: Tailoring 9500-OPS
for Ground Segment Systems
07.2009
ECSS-Q-ST-80C Space product
assurance - Software product
assurance: Tailoring for Ground
Segment Systems
AD-0002 File Based Operations Concept
QMS-EIMO-GUID-CKL- 1.2
9501-OPS
09.2011
EGOS-GEN-FbO-RP1.0
0001
TEC-EDD-2007.13-AVS- 1.15
OSAL-ICD
07.01.10
AD-0003 Operating system Abstraction
layer
AD-0004 GR-CPCI-AT697 Development
Board User Manual
AD-0005 RASTA Interface Board FPGA
User’s Manual
AD-0006 RASTA interface board RTEMS
device drivers
AD-0007 RASTA TMTC Board FPGA User’s
Manual
AD-0008 TM/TC Onboard Stack Library
Interface Control Document And
Design Notes
AD-0009 File and Packet Store Services Interface Control Document
AD-0010 File and Packet Store Services Software User Manual
AD-0011 S2K-R5.4.x Document Pack
AD-0012 EUD 2.x Document Pack
AD-0013 CFDP 1.x Document Pack
AD-0014 FARC 2.1.x Document Pack
AD-0015 ESOC Generic Ground Systems:
Development Requirements
Specification
http://www.atmel.com/d Rev. 2005-11-16
yn/products/product_car 1.1
d.asp?part_id=3178
1.1.0 May 2010
1.2.1. March 2012
0
1.0.7 Feb. 2009
TEC-EDS-2010.68-AVS- 1.2
OTMTC-ICD
TEC-EDD-2010.77-AVS- 1.5
FPSS-ICD
TEC-EDS-2010.85-AVS- 1.3
FPSS-SUM
EGGS-ESOC-GS-SRS1001
1.1.1
2009-12-15
2011-01-30
31.10.2008
Page 21/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
Id
Title
Reference
Ver.
Date
AD-0016 ESOC Generic Ground Systems:
System Configuration Baselines:
Part 1 - Procedures
EGGS-ESOC-GS-SCD1002
1.0
16.09.08
ESOC Generic Ground Systems:
System Configuration Baselines:
Part 2 - Software Package
Specification
EGGS-ESOC-GS-SCD1002
1.1
23.07.10
ESOC Generic Ground Systems:
System Configuration Baselines:
Part 3 - Baseline Definitions
AD-0017 License disclaimer
AD-0018 EGOS namespace conventions
EGGS-ESOC-GS-SCD1002
1.3
04.08.11
Disclaimer
Proposal for EGOS
Namespace Convention
BSSC 2005(2)
BSSC 2004(3)
1.5
1.1
19.09.08
01.02.08
1.0
1.0
03.03.05
31.03.05
EISD-EPNS-00003
2.2.1 28.09.04
AD-0019 Java Coding Standards
AD-0020 Design & Style Guide for XML
Data and Schema
AD-0021 Implementation Of The ESA
Network Security Policy
AD-0022 Software Configuration
Management Plan
AD-0023 Implementation Of The ESA
Network Security Policy for OPSNET
AD-0024 Software Quality and Coding
Rules
EGOS-GEN-GEN-CMP- 1.2
1001
DOPS-COM-POL-34555- 2.3
OPS-ECT
EGOS-QA-XX-TN-9007
11.09.09
09.11.07
1.5
09-06-2009
Draft
C
1.2
2010-03-25
AD-0025 SCOS-2000 System regression
test automation
AD-0026 EGOS Template Guidelines
egos-mcs-s2k-tn-5003
EGOS-GEN-GEN-TN0xyz
3.0
2007-11-01
AD-0027 Project Tracking BIRFSW ICD
EGOS-GEN-BIRFSWICD-1001
EGOS-STU-BIRFSW-TN1002
http://www.scrum.org/st
orage/scrumguides/Scru
m%20Guide.pdf
EGOS-NIS-NCTR-ICD0002
CCSDS 873.0-R-2
1.1
18.01.10
2.4
16.11.2010
AD-0028 Project Tracking BIRFSW MPR
AD-0029 Ken Schwaber, Jeff Sutherland:
The SCRUM Guide
AD-0030 NIS/NCTRS Volume 2- Detailed
interface Definition: MCS
AD-0031 Spacecraft Onboard Interface
Services (SOIS) – File and Packet
Store Services
2010
4.0.2 06.11.2009
2
Jan 2011
Page 22/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
Id
Title
Reference
Ver.
AD-0032 Ground systems and operations — ECSS-E-70-41A
A
Telemetry and telecommand
packet utilization (PUS)
AD-0033 CCSDS File Delivery Protocol,
CCSDS 727.0-B-4
Recommended Standard, Blue
Book
AD-0034 ESA Security Directives
ESA/ADMIN/IPOL(2008
)6, Annex 2
Date
Jan. 2003
Jan. 2007
2008-10-20
Page 23/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.4.2 Reference Documents
The following documents are to be considered as reference to the Project:
Id
Reference
Ver.
RD-0001 Spacecraft Onboard Interface
Services (SOIS) – Informational
Report
RD-0002 CCSDS Space Packet Protocol
Title
CCSDS 850.0-G-1
1
June 2007
Date
CCSDS 133.0-B-1
1
Sept. 2003
RD-0003 CCSDS Report – Overview of
Space Communication Protocols
RD-0004 Ground Segment Data System
Architecture to Support CFDP,
DTN and IP – FINAL REPORT
CCSDS 130.0-G-2
2
Dec. 2007
SSL/CFDPB/RP/001
1.2 Feb. 2011
Page 24/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.4.3 Definition and Terms
Term
Definition
”Reference
Model”
A reference model is a notion used in standard conceptual models. It is
an abstract representation of the entities and relationships involved in a
problem space, and forms the conceptual basis for the development of
more concrete models of the space, and ultimately implementations.
A reference architecture provides a proven template solution for an
architecture for a particular domain. It also provides a common
vocabulary with which to discuss implementations, often with the aim
to stress commonality. Reference architectures can be defined at
different levels of abstraction. A highly abstract one might show
different pieces of equipment on a communications network, each
providing different functions. A lower level one might demonstrate the
interactions of procedures (or methods) within a computer program
defined to perform a very specific task.
A specific instance of a reference architecture tied to specific standards,
technologies, implementations, deployments, or other concrete
selection of options and attributes.
Collection of "shallow and wide" tests affecting all areas of the system
without too much detail. They aim at validating basic features of the
system (i.e. does it start-up? does it load a file, etc)
Software deliveries used for early validation and review.
Two different types of Software Predeliveries are considered.
 Mock-ups: used at early stages of the development to ensure
functional correctness
 Intermediate deliveries: used to ensure functional and product
assurance correctness
Note access to Software Predeliveries may be provided via ”Work
Results”, remote access to the development environment (WebEx-alike
tools)
Virtual Appliances are pre-built, pre-configured, ready-to-run
enterprise applications packaged with an operating system inside a
virtual machine. Customers can easily install and deploy these preintegrated solution stacks. This speeds up time to value and simplifies
software development, distribution, and management.
(http://www.vmware.com/appliances/learn/overview.html)
Third Party Product is any software, (e.g. proprietary software or open
source software, including also but not limited to software tools,
libraries, code, designs, etc.) and associated items for which ESA does
not have the full usage, exploitation and distribution rights. For the
avoidance of doubt, Third Party Product shall include any existing
software and associated items of the Contractor or of the
subContractors.
“Work Results” mean all results of Contractor’s and/or any Sub-
”Reference
Architecture”
”Concrete
Architecture”
”Smoke Test”
”Software
Predeliveries”
”Virtual
Appliance”
”Third Party
Product”
”Work Results”
Page 25/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
Contractor’s work rendered under this Project.
Page 26/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
1.4.4 Acronyms and Abbreviations
Acronym / Abbreviation
Description
CFI
ECC
EGOS
ESA
ESOC
GSS
GSMC
GSSS
HCI
HMI
IPR
ITAR
MCS
M&C
MOI
NIS
OCC
OPSNET
OS
RID
S/C
SDD
SDE
SOW
SUM
TBC
TBD
TBS
TRP
TO
Customer Furnished Item
ESTRACK Control Centre
ESA Ground Operation System
European Space Agency
European Space Operations Centre
Ground Segment Systems
Ground Station Monitoring and Control
Ground Segment Systems Stakeholders
Human Computer Interaction
Human-Machine Interface
Intellectual Property Rights
International Traffic in Arms Regulations
Mission Control System
Monitoring and Control
Mission Operations Infrastructure
Network Interface System
Operations Control Centre
(ESOC) Operations Communications Network
Operating System
Review Item Discrepancy
Spacecraft
Software Design Document
Software Development Environment
Statement Of Work
Software User Manual
To be confirmed (by the Agency)
To be determined (by the Contractor)
To be specified (by the Agency)
Technology Research Programme
Technical Officer
Page 27/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
2
ASSUMPTIONS, CONSTRAINTS AND CUSTOMER
FURNISHED ITEMS
2.1
Assumptions
AR-0001
New versions of applicable documents may be provided at KO.
2.2 Constraints
2.2.1 General Constraints
CR-0001
All requirements in the ESOC Generic Ground Systems: Development
Requirements Specification [AD-0015] shall be applicable to the work subject
of this SoW.
2.2.2 Intellectual Property Rights Constraints
CO-0001
It is of critical importance that the Contractor understands and adheres to
the fact that all source code, test tools, harnesses, input data samples and test
script procedures to be delivered as part of this work shall be delivered at
each milestone as Operational Software with full ESA Intellectual Property
Rights.
2.2.3 SDE Constraints
CO-0002
IBM Rational Change (CFI-SWI-0001) shall be used, to generate/manage
SPR/SCR related information.
Page 28/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
2.2.4 Baseline Constraints
CO-0003
Initial development of the system shall start on SLES 11 using the baseline
from the EGGS System Configuration Document (AD-0016) compatible with
the version of S2KR5 agreed at K/O.
Note: this is expected to be S2K5.4. In this case the applicable baselines as
described in ESOC Generic Ground Systems: System Configuration
Baselines: Part 3 - Baseline Definitions Document (AD-0016) will be;
CO-0004

Platform baseline
SLES11-064-ESOCL01-I1R0

Application baseline
EGOS-X86-064-OPS-I1R0 (for run-time)

Application baseline
development)
EGOS-X86-064-OPS-I1R0 (for
Any changes that are desired to the baselines (e.g. change of version of
product, addition of new product) must be agreed in advance, in writing by
ESA. As this requires the approval of the IBCCB requests for changes must be
submitted in good time with detailed supporting information as to why the
change is required. It must not be assumed that a requested change will be
agreed to by ESA.
2.2.5 Implementation Constraints
CO-0005
The User Interface shall be exclusively based on the EGOS User Desktop, see
AD-0012.
2.2.6 Other Constraints
CO-0006
The Contractor shall not distribute any Project deliverable without prior
written authorization of the ESA TO. This applies both to internal deliveries
within the Consortia (to be used in other ESA or non-ESA contracts) as well
as to external deliveries to other organizations and/or ESA units.
CO-0007
All activities, reports, correspondence, deliverables and tools covered by this
SoW shall be in British English.
Page 29/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
2.2.7 Third Party Products Constraints
CO-0008
Only 3rd party products according to AD-0016 may be used in the work
results. All other 3rd party products have to be authorised by the ESA
Technical Officer before use. If non-authorised 3rd party products are used,
ESA will reject the delivery.
The use of additional 3rd party products shall be discussed with the ESA
Technical Officer during technology evaluation. The use of additional 3rd
party products has to be authorised in writing by the ESA Technical Officer
after approval by the necessary ESA bodies. This restriction shall not limit
the initial creative phase but applies to any software implemented as part of
this activity and to be delivered to ESA.
US products falling under ITAR regulations cannot be used.
Page 30/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
2.3 Customer Furnished Items
CFI-0001
CFI-0002
CFI-0003
CFI-0004
CFI-0005
CFI-0006
CFI-0007
ESA is committed to provide only the items listed in Table 2-1 Customer
Furnished Items.
Following reception of a CFI to be integrated, the Contractor shall assess its
completeness and correctness. The outputs of this analysis shall be officially
reported to ESA in the form of a CFI Acceptance Report by the Contractor.
Also completeness of the associated documentation data package shall be
covered.
Following CFI Acceptance, the Contractor shall be fully responsible for the
completeness and the accuracy of the documentation of the final product also
for cases where the CFI’s to be integrated have incomplete or missing
documentation.
Note: in such cases ESA will provide all existing supporting information
available, e.g. TN, Software Release Document, DCRs, emails. It can
however be assumed that the main CFI’s to be integrated will be delivered
along with the required technical documentation.
All problems found by the Contractor in CFI’s shall be raised as Problem
Reports (e.g. SPR’s) using the applicable Change Management System (CFISWI-0001).
Access to SDE tools is granted for the sole purpose of fulfilling the
requirements of this Project and will be subject to the conditions of the tool
provider and /or any agreements signed between ESA and the tool provider.
Access to SDE tools/licenses requires the setup of local infrastructure and
remote access to license managers.
Access to SDE tools will be provided only after the Contractor has signed the
relevant agreement
Page 31/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
CFI Identifier
Description
Delivery Date
Documentation
CFI-DOCThe latest available version for all applicable documents (see ML-KO
0001
1.4.1)
CFI-DOCBIRF Excel Template for monthly reporting
ML-KO
0002
Software Infrastructure
CFI-SWISoftware to be reused: (SLES 11 baseline)
ML-KO (TBC)
0001
 S2K-R5.4.x
 EUD 2.x
 CFDP 1.x
 FARC 2.1.x
CFI-SWIAccess to IBM Rational Change server for Change
ML-KO
0002
Management
CFI-SWIFor the Linux based RASTA Emulator system:
ML-KO
0003
 A C-language version of the SOIS file and packet store
interfaces together with a C-language API
 CCSDS packet routing software
 JAVA based CFDP software as per CFI-SWI-0001
above.
 Support for installation
For RASTA:






A C-language version of the SOIS file and packet store
interfaces together with a C-language API
RTEMS OSAL version
CCSDS packet routing software
Mass memory unit
Access and support to the RASTA fixed and portable
systems
CFDP
Table 2-1 Customer Furnished Items
Page 32/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3
STUDY REQUIREMENTS
The objective of this study is to provide an end-to-end demonstration of file based
operations, based on concepts described in [AD-0002] and tailored in Section 1.3 of this
Statement of Work. In particular the following scenarios shall be considered.
SR-0001
The study shall provide an end-to-end demonstration of file based
operations, based on concepts described in [AD-0002] and tailored in
Section 1.3 of this Statement of Work, In particular the following scenarios
shall be considered:
1. Spacecraft Control with direct access to uplink/downlink (see section
1.3.3.1 of this document)
2. Spacecraft Control with direct access to uplink/downlink. File Delivery
to ground station (see section 1.3.3.2 of this document)
3. Spacecraft Asset Control via Relay (see section 1.3.3.3 of this
document)
SR-0002
For the purposes of the study it can be assumed that the protocol for file
transfer to be used between the Control Centre and the Space Asset is CFDP.
SR-0003
The space asset shall be modelled by using the ESTEC Reference Architecture
System Test-bed for Avionics (RASTA). [AD-0003 - AD-0010]
SR-0004
All requirements specified in Appendix B of [AD-0002] shall be taken into
account in the study.
These requirements cover aspects of file based operations related to file
utilisation on ground, file utilisation on-board, file management and access
and file transfer.
Page 33/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.1
User Requirements
This section outlines high level user requirements extracted from [AD-0002].
SR-0005
The Files Transaction Manager shall enable a privileged user to initiate the
files transactions (e.g. to uplink a file) and to control the status of on-going
transactions, including the ones related to reception of files. This application
shall support operations at transaction level such as
start/stop/suspend/resume/abort as well as the inspection of the lower levels
(e.g. the reception/transmission of PDUs).
SR-0006
The Files Reception History Display (equivalent to the TM Packets History
Display), shall be able to show the history of all files received from the Space
Segment along with their attributes/status.
SR-0007
The Files Transmission History Display (equivalent to the Command History
Display), shall be able to show the history of all transmitted files along with
their attributes and transmission status.
SR-0008
The File Browser of the On-board File store (equivalent to the File Browser of
the control system file store), shall support the user interactions in the area of
on-board files browsing and management (e.g. delete, create directory,
downlink, etc.). This application will be fed by the underlying image of the
on-board file store and will generate appropriate commands for managing
the real on-board file store.
SR-0009
The Files Transaction Processors shall support all processing required to
manage file transactions. It will receive requests from the user applications
and interact with the file delivery protocol engine to request the uplink of files
and to be notified of the reception of files. It will also maintain the status of
each transaction and feed the relevant information to the history log and the
ground image of the on-board file store.
SR-0010
The Files Transaction History Log is the equivalent of the TM/TC Packet
History Archive. It shall contain one record per file transaction (in both
directions) containing all relevant details, including a link to the ground file
store (see below) where the file is archived (which can be activated by the
relevant user application in order to open the corresponding file). It is
planned to implement this history log using the Packet ARChive (PARC),
similarly to all other operational logs in the ESOC Mission Control System
infrastructure.
Page 34/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
SR-0011
The S/C File store Image shall be responsible for maintaining a mirror image
of the on-board file store. This image is updated on the basis of ground
requests (considering their confirmation status) and on the basis of relevant
reports received from the spacecraft. The image is meant to serve the needs of
visualising the content of the on-board file store and to generate file
management operations requests to be submitted to the spacecraft. It is the
responsibility of this application also to maintain an image of the TC Files
which have been uploaded to the spacecraft for delayed (on-request)
execution.
SR-0012
The S/C file store model shall support two different views of the on-board file
store:
1.
Assumed, i.e. what the contents of the on-board file store would be
assuming that outstanding transactions are successfully completed.
2.
Confirmed, the actual status of the files as determined by S/C
reports. In this case it should be clearly distinguished between
those file that have been successfully transferred, those with errors
(or being retried), those “in transit”, i.e. for which that status is not
yet known and those “queued” either on-board or on the control
system.
See also SR-0028
SR-0013
The S/C file store model will be present on the control system and also
potentially at external entities (e.g. Payload Data centre). It shall thus be
possible to replicate the S/C file store remotely from the control system.
SR-0014
Operations on a remote (from the control system) model of the S/C file store
model shall be replicated on the control system version of the model only
after these have been authorised by a user with appropriate privileges on the
control system.
SR-0015
Operations authorised/rejected on the control system shall then be used to
update the S/C file store model at the originating external entity.
SR-0016
Due to security/data confidentiality reasons it shall be possible to restrict the
files in the S/C file store model which are available to any particular external
entity.
SR-0017
The Ground File store shall provide the file storage and retrieval services to
control centre applications. It will receive reconstructed files from the File
Delivery Protocol engine it will support the retrieval of ground files for upload
purposes as well as for utilisation purposes. The intention is to base the
implementation of this file store on the existing File ARChive (FARC), which
enables a centralised management and distributed access to files.
Note: The ESA CFDP implementation already contains a FARC File Store
Interface.
Page 35/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
SR-0018
The file services available in the S/C file store image and the ground file store
shall be the same as are available in the SOIS Packet Store Services as
described in [AD-0031].
Note: This is so it is straightforward to model the on board file store on the
ground system.
SR-0019
The Files Utilisation Applications represent all the ground applications that
need the received files to perform their job and/or generate files for upload to
the spacecraft. An example of this application is the On-board S/W Manager,
which will need to dump files in order to update the ground image of the onboard memory and generate patch files in order to update the real on-board
memory. Other files utilisation applications will generate TC files which are
destined to the On-board Scheduler for time-tagged execution or uploaded to
the spacecraft for delayed execution (on-request).
SR-0020
File based operations shall be capable of being used in earth orbit as well as
interplanetary missions. Thus the system must be capable of handling one
way light times of several tens of minutes.
Page 36/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.2 Functional requirements
3.2.1 Space Segment
SR-0021
An analysis shall be carried out on the new PUS services required to expose;
1. CFDP functionality
2. SOIS functionality
3. File Utilisation functionality
The results of this trade-off shall be documented in a technical note and later
fed into the software requirements for implementation.
SR-0022
An analysis shall be carried out into the trade-off between using the CFDP
metadata functionality to carry the metadata associated with a files or
delivering this via a PUS service.
The result of this analysis shall be documented in a technical note and later
fed into the software requirements for implementation.
SR-0023
A Software Requirements Specification document for the space segment shall
be produced based on an analysis of the user requirements specified above,
the concept detailed in File Based Operations Concept document [AD-0002]
and the technical note produced as specified in requirements SR-0021 and
SR-0022 above.
SR-0024
The Software Requirements Specification shall prioritise the software
requirements for the space segment as follows:

Essential
operations.
Essential for the demonstration of end-to-end file based

Desirable
operations.
Desirable for the demonstration of end-to-end file based

Unnecessary Unnecessary for the demonstration of end-to-end file
based operations.
NOTE: It is expected that only the essential functionality will be
implemented in RASTA during the course of the study
Page 37/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
SR-0025
As part of the activity the required parts of the PUS functionality shall be
implemented. This shall include sufficient functionality to:
1. Manage the on-board file store (using the SOIS functionality as per
SR-0021)
2. Transfer files (using CFDP functionality as per SR-0021)
3. Process the files (using the File Utilisation functionality identified as
per SR-0021)
4. Anything else required to support the above functionality.
NOTE: currently work is on-going on revising the PUS specification. In
particular additional file store management functionality is expected to add.
It should be foreseen that inputs from the PUS working group be
incorporated into the study activities as these become available.
NOTE: any services identified as necessary for the purposes that are not
covered by either the current PUS specification or the proposed updates to
this should be implemented as a mission specific extensions to the PUS.
3.2.2 Ground Segment
SR-0026
An analysis shall be carried out on;

An appropriate means of replicating the S/C file store model from the
control system to external entities

How change requests on the S/C file store model at the external entity
should be transferred and queued at the Control Centre for
authorisation

How the information regarding the status of requested changed (i.e.
authorised/rejected) should be returned to the originating external
entity and used to update the S/C file store model.
The result of this analysis shall be documented in a technical note and later
fed into the software requirements for implementation.
SR-0027
An analysis shall be carried out on how to restrict the files available to any
particular external entity. The results of this analysis shall be documented in
a technical note and later fed into the software requirements for
implementation.
Page 38/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
SR-0028
One of the key aspects in file operations is providing an intuitive user
interface. With this in mind an analysis shall be carried out on how best the
user should interact with the system, e.g. by dragging and dropping a file
from the model of the S/C file store to the ground store (or vice versa). It
should be bourn in mind that dragging and dropping of the files will actually
result in the generation of commands (that must be authorised before the
operation is carried out) and telemetry that actually carry out the required
operations. A clear mechanism for identifying the state (and location) of each
file must therefore be defined. This needs to take into account at least the
following;
1. Location of file
2. Status of file, e.g.

Static (i.e. file is in one location and no operation has been
requested)

Pending (an operation on the file has been requested)

Authorised (an operation on the file has been authorised)

Active (an operation on the file has been started)

Successful (the operation on the file has completed successfully)

Failed (the operation on the file has failed)
The results of this analysis shall be documented in a technical note and later
fed into the software requirements for implementation.
SR-0029
It shall be possible to systematically dump all files that have been queued onboard.
SR-0030
It shall be possible to uplink and downlink multiple files concurrently.
SR-0031
For the Spacecraft Control with direct access to uplink/downlink. File
Delivery to ground station (see section 1.3.3.2 of this document) an analysis
shall be carried out into the best manner in which commands from the CFDP
entity at a groundstation can be uplinked to the spacecraft via the OCC TC
chain and executed such that the required retransmission of parts of a file is
carried out to the appropriate groundstation.
Also the analysis shall give consideration to the case of executing file
downlink via CFDP to a groundstation when there are no commanding
activities during the pass.
The results of this analysis shall be documented in a technical note and later
fed into the software requirements for implementation.
Page 39/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
SR-0032
A Software Requirements Specification document for the ground segment
shall be produced based on an analysis of the user requirements specified
above, the concept detailed in File Based Operations Concept document [AD0002] and the technical notes produced as specified in requirements SR0026, SR-0027, SR-0028 and SR-0031 above.
SR-0033
In addition to the new applications identified in the user requirements
section above a number of other existing applications (e.g. TM Receiver &
Distributor, TC Handler & Releaser, Network Interface) may require
modifications in order to serve the needs of file based operations.
For example, the support of Delayed TC Files (i.e. the TC Files uploaded to
the spacecraft whose execution can be requested multiple times by ground)
will likely require modifications in the processes that support command
execution verification.
An analysis of the changes required shall be carried out and the results
incorporated into the Software Requirements Specification document.
SR-0034
Once the Software Requirements Specification document has been reviewed
and accepted a Software Design Document shall be produced.
SR-0035
Once the Software Design Document has been reviewed and accepted the
system shall be implemented.
Page 40/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.3 Development and demonstration requirements
As a final task of the study the contractor shall demonstrate the operation of file based
operations using the test-bed infrastructures of the Agency located at ESOC and ESTEC.
This provides a realistic demonstration using ground and flight representative hardware.
This section provides guidance and recommendations on a development approach which
may be used by the contractor to achieve this goal.
The RASTA system is located at ESTEC and provides a realistic flight hardware and
software avionics environment for test-bedding activities. The core system consist of a
Leon based processor and RTEMS 4.8 software environment. All application software is
coded in C. A baseband CCSDS compliant space link is provided which allows CCSDS
packet level interfaces to ground and flight software applications. RASTA may be
connected to the ESOC infrastructure using IP based connectivity.
Included as part of the existing RASTA is a C implementation of the CCSDS SOIS file and
packet store services providing access to a local mass memory. A version of the CCSDS file
delivery protocol CFDP offering class 1 and class 2 capabilities is also available. PUS based
services to support file based operations are not available and these shall be provided as
part of this study.
An overview of the RASTA configuration relevant to this study and identifying the software
modules to be provided as CFI or developed by the contractor is shown below.
Page 41/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
TM/TC
Drivers
TM/TC
Board
PUS services
GRMON
CFDP
TM/TC
drivers
SERIAL
LINK
Ground TMTC
Drivers
SOSI File and packet
store services
ETH
PUS
services
SPACE
LINK
CFDP
MMU Module
ON-BOARD
DOMAIN
ETHERNET
DEBUG
HW Interfaces
LINK to ESOC
GROUND
TMTC Board
SW modules (to be) provided by ESA
SW modules missing
ETHERNET
Linux PC
Figure 8: Overview of the RASTA Configuration Relevant to this Study.
As the RASTA infrastructure will only be used in the final part of the study, the following
development steps are suggested.



All major software development related to RASTA is performed under Linux on a
commercial PC. For this the Agency will make available a Linux version of the file
and packet store services together with an system software to ease final porting
(OSAL – operating system abstraction layer and packet router) .
The Linux PC version is used as a substitute for the RASTA based version for all
testing with the ESOC based infrastructure.
Once all software has undergone preliminary acceptance, a port of the software is
made to the RASTA system for final acceptance and demonstration
The port to RASTA may either be performed directly on the RASTA system at Estec on via
an intermediate step whereby the agency makes available as CFI a stand-alone RASTA
system.
The above steps represent the Agency’s recommended approach but alternative solutions
may be proposed by the contractor.
SR-0036
The software delivered for final acceptance and demonstration must be able
to be run on the RASTA system.
Page 42/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
SR-0037
The final acceptance and demonstration must be end-to-end, involving both
RASTA and the MCS.
Page 43/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.4 Interface requirements
SR-0038
The RASTA system (and the Linux based RASTA emulator) generates space
packets containing Telemetry data and also expects to receive Telecommands
contained in space packets. Currently the MCS expects to receive TM and
produces TCs as described in the NIS/NCTRS – MCS ICD [AD-0030]. In
view of this adaptors shall be provided such that the MCS can successfully
interface with the RASTA system.
NOTE: The adaptors will be required to provide the functionality for the
S2K releaser and packetiser to directly interface to RASTA via space
packets.
Page 44/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.5
Resources requirements
3.5.1 Space Segment
SR-0039
Software developed for the Linux RASTA Emulator shall use the Ubuntu 10.4
or later operating system
SR-0040
Software developed for or ported to RASTA shall be compliant with the
capabilities of AD004. It shall be written in C and operate under RTEMS 4.8.
3.5.2 Ground Segment
3.5.2.1 Computer Hardware Requirements
SR-0041
The hardware baseline shall be compliant with a hardware baseline specified
in [AD-0016], part 3, that is compatible with the version of S2K to be used in
the activity.
3.5.2.2 Computer Software Requirements
SR-0042
The software baseline shall be compliant with a platform baseline specified in
[AD-0016] part 3, that is compatible with the version of S2K to be used in the
activity.
SR-0043
The software baseline shall be compliant with an application baseline
specified in [AD-0016] part 3, that is compatible with the version of S2K to be
used in the activity.
Page 45/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.6 Design requirements
SR-0044
Third Party Products adhering to international standards (e.g. CORBA) shall
be utilised within the scope of features documented in the applicable
standard.
Note: this is required in order to be able to replace a Third Party Product by
an equivalent one with minimal effort.
Note: if applicable, i.e. the Third Party Product adheres to an international
standard.
SR-0045
All classes shall be stereotyped as Platform Dependent or Platform
Independent
Page 46/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.7
Implementation requirements
SR-0046
Namespace conventions shall be compliant with AD-0018.
SR-0047
Java source code shall be compliant with coding conventions as per AD-0019.
SR-0048
XML source code shall be compliant with coding conventions as per AD0020.
SR-0049
There shall be no dependency introduced into any MICONSYS application on
any of the components developed for this study, i.e. MICONSYS shall be able
to function without any of the components developed for this study being
present.
NOTE: This does not imply that no changes to MICONSYS applications are
permitted, merely that they should be implemented in such a way that the
they do not depend on the new components being present.
SR-0050
The new components developed for this study should have no direct
dependencies on the underlying protocol implementation (e.g. CFDP,
TM/TC, PUS).
Page 47/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.8 Security and Privacy requirements
SR-0051
The system shall be compliant with the ESA Security Policy specified by AD0021 and AD-0023.
Page 48/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.9 Quality requirements
SR-0052
100% Requirements Test Coverage shall be achieved.
Note: i.e. All Software Requirements shall be fully verified/validated.
Page 49/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.10 HMI requirements
SR-0053
Mock-ups of any required HMIs shall be provided and these shall be iterated,
taking into account input from ESA on the proposed layouts.
Page 50/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.11 Reuse and reusability requirements
SR-0054
The Control System shall be based on the latest available version at kick-off of
the SLES 11 based S2KR5 software.
SR-0055
The Ground file store shall be based on the existing File ARChive (FARC)
SR-0056
The File Transaction History Log shall be based on the existing Packet
ARChive (PARC)
SR-0057
The user interface shall be built on top of the Egos User Desktop (EUD)
SR-0058
The ESOC CFDP implementation shall be used.
SR-0059
The ESTEC RASTA implementation shall be used to model the space
segment.
NOTE: As previously indicated it is suggested that the Linux based RASTA
Emulator system nay be used during the development process, with the final
delivery being ported to the actual RASTA system.
Page 51/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
3.12 Verification, Validation and Acceptance Requirements
SR-0060
Test Cases shall contain a level of detail that allows their execution by a tester
having only “User” knowledge of the application; i.e. without the need of a
developer team member support.
SR-0061
Test Cases shall unambiguously provide the values of the expected results
and state the required input data. Whenever adequate, input data shall be
prepared as computer stored Test Data Sets to allow faster execution of tests
and full reproducibility.
SR-0062
Testing shall include, as a minimum:
SR-0063

Nominal cases: test of expected results

Error cases (semantic and syntax): test of boundary and special
conditions, including the provocation of all possible return conditions,
including all return codes and exceptions that can be thrown.

Performance/Stress Testing: test of system limits.

System Interfaces: full test of system interfaces.
System testing shall include, as a minimum:

Build process

Functional Test: this test verifies the proper functional behaviour of
the system.

Performance Tests: this test verifies the proper performance of the
system.

Long Duration Test (minimum 48 hours): this test verifies the stability
of the system for a long period of time.

Stress Tests: this test verifies the proper behaviour of the system at or
beyond its value limits.

Robustness Tests: this test verifies the proper handling of error
conditions.
SR-0064
System Testing shall reach, at least, 30% of automation.
SR-0065
The Contractor shall be responsible for the production of any items required
to support testing, including test harnesses, input data samples, command
procedures.
Page 52/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
SR-0066
The Contractor shall produce a set of test scenarios, to be agreed by ESA,
based on the Use case scenarios described in section 4.2 of [AD-0002] and
the varios trade-off carried out during the course of this study, to
demonstrate the feasibility of the File Based Operations concept presented in
[AD-0002].
These shall be documented as part of the Software Validation Specification
[EGOS-GEN-FiBOps-SVS-1001].
Page 53/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
4
WORK TO BE PERFORMED
4.1
Project Logic
SL-0001
The Software Engineering methodology shall be compliant with AD-0001 and
in particular Tailoring Type 4 as described in AD-0001 shall be applicable to
the ground segment software developed for this project.
SL-0002
The Software Engineering methodology shall be compliant with AD-0001 and
in particular Tailoring Type 4 as described in AD-0001 shall be applicable to
the space segment software developed for this project.
SL-0003
The project shall follow the SCRUM [AD-0029] approach. In particular,

The ESA Technical Officer will take the role of the Product Owner. The
ESA Technical Officer shall be supported by a Product Owner Proxy on
the Contractor’s side.

A product backlog and sprint backlogs shall be maintained.

Sprint Planning Meetings, Sprint Review Meetings and Sprint
Retrospective meetings with participation of the whole team (i.e. not
just the Project Manager or SCRUM Master) shall be held.

There should be an identified SCRUM Master at the Contractor’s side.
Note: It may not be possible to apply SCRUM fully to all project phases. For
example, a daily SCRUM with a large team with low individual team
member allocation to the project makes little sense. So, SCRUM should be
tailored according to project phase and team composition. Nevertheless, the
main elements should be kept (high customer involvement; openness to
changes throughout the whole project; sprint deliveries and related
meetings; SCRUM roles).
SL-0004
Each sprint shall not take more than six working weeks.
SL-0005
As part of the proposal the bidder should produce a draft product backlog.
4.2 Project Phases
SP-0001
The Project organisation shall include the following WP.







WP-01, Management
WP-02, Requirements Engineering
WP-03, Architecture and Interface Design
WP-04, Design and Implementation
WP-05, Provisional Software Acceptance
WP-06, Final Software Acceptance
WP-07, Warranty
Page 54/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
SP-0002
Each WP (with the exception of the Management and warrenty WPs) shall be
broken down into several sprints following the SCRUM methodology (see also
[AD-0029]).
Note: Sprint Review Meetings for WP2, WP3 and WP5 will review achieved
WP results as demonstrated by the state of the documents to be produced
and the methodologies applied. Review Meetings for WP4 will include
review of the software and should be accompanied by sprint deliveries of
working software. User feedback gathered during these review meetings
will be taken into account and may lead to modification of future tasks to be
performed. This will be discussed at the sprint planning meetings.
Note: Sprint Review Meetings may be combined with formal review
meetings.
4.2.1
WP-01, Management
MGT-0001 The following Input to the Work Package shall be considered:
 All applicable documents;
 All reference documents;
 The Statement of Work (this document);
 Minutes of the kick-off meeting.
MGT-0002 Perform general project management ensuring proper control over schedule,
cost and quality according to AD-0001
MGT-0003 Provide complete visibility to the Agency of all aspects of the work.
MGT-0004 Implement the appropriate management communication lines and ensure a
single management authority for all tasks.
MGT-0005 Perform sub-Contractor(s) management
MGT-0006 Perform risk management, identifying potential risks propose meaningful
ways to mitigate them and review the risk status during the different Project
phases.
MGT-0007 Produce and maintain the Software Development Plan, EGOS-GEN-FiBOpsSDP-1001
Note: content template defined by AD-0001
MGT-0008 Produce and maintain the Software Configuration Management, EGOS-GENFiBOps-SDP-1001
Note: content template defined by AD-0001
Note: configuration management requirements specified by AD-0022 shall
be applied.
Page 55/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
MGT-0009 Produce and maintain the Software Product Assurance plan, EGOS-GENFiBOps-SDP-1001
Note: content template defined by AD-0001
MGT-0010 Monthly production of the Monthly Progress Report, EGOS-GEN-FiBOpsMPR-yymm.
Note: BIRF should be used for progress reporting. The content template
defined by AD-0028 shall be used. The latest version of the template will be
provided at ML-KO.
MGT-0011
Note: the Monthly Progress Report shall be delivered not later than five
working days after the end of the reporting month.
As required, produce the Meeting Minutes, EGOS-GEN-FiBOps-MIN-tnnn
Note: this document shall include (non-exhaustive list):
 List of the participants
 Agreements
 Actions
Note: Minutes of Meetings shall be taken by in real time and they must be
signed off at the end of the meeting. Afterwards, the Contractor shall
distribute the minutes, in electronic format, not later than two working days
after the meeting.
MGT-0012 Support / attend meetings as per section 4.3
MGT-0013 Delivery of Documentation Items – Management as per Table 5-1
Documentation Delivery Items – Management (at different milestones)
MGT-0014 The Project Manager shall ensure information, also within his consortium is
only distributed according to the Agency’s rules and regulations (see AD0034) and on a need-to-know basis. Sensitive information shall only be
distributed upon prior written confirmation of the Agency’s Technical Officer
to named individuals.
Note: NDAs have to be signed before any sensitive information is
distributed.
Note: Sensitive information is any information marked as ESA CLASSIFIED
or ESA UNCLASSIFIED – PRIVILEGED.
Note: It is currently not expected that any sensitive information is necessary
for the execution of this study.
MGT-0015 The standard requirements in Appendix 3, Section 1 and 2 of the Contract
shall be applicable to this activity
Page 56/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
4.2.2 WP-02, Requirements Engineering
RQE-0001
The following Input to the phase shall be considered:
 All applicable documents;
 All reference documents;
 The Statement of Work (this document).
 Minutes of the kick-off meeting.
RQE-0002 The purpose of this WP is to define the main concepts, requirements, use
cases of the system and the software to be reused.
RQE-0003 Identify use cases and associated requirements to be supported, by involving
a representative group of end users.
RQE-0004 Produce the technical note, EGOS-GEN-FiBOps-TN-1001, containing the
results of the analysis of the trade-offs in the space segment specified in
requirements SR-0021 and SR-0022.
RQE-0005 Produce the technical note, EGOS-GEN-FiBOps-TN-1002, containing the
results of the analysis of the trade-offs in the ground segment specified in
requirements SR-0026, SR-0027, SR-0028 and SR-0031.
RQE-0006 Analyse and refine the Study Requirements specified in Section 3.
RQE-0007 Produce the Glossary, EGOS-GEN-FiBOps-GLO-1001
Note: this document shall include:
 Definition of terms
 Acronyms
RQE-0008 Produce the Document Control List, EGOS-GEN-FiBOps-DCL-1001
Note: this document shall include:
 Applicable documents (DocID, Title, Reference, Issue, Date)
 Reference documents (DocID, Title, Reference, Issue, Date)
RQE-0009 Produce the Software Requirements Specification, EGOS-GEN-FiBOps-SRS1001
Note: content template defined by AD-0001
RQE-0010
Produce the Interface Control Document (1/2), EGOS-GEN-FiBOps-ICD1001
Note: content template defined by AD-0001
Note: as part of this WP, the document shall specify the main interfaces of
the system at high level.
Note: the Contractor is encouraged to deploy mechanisms/tools to enable
automated generation / synchronisation of this document and the software
code
RQE-0011
Deliver the PRJ 0.1.0 delivery package (ML-SWRRD) at least 10 working days
before the review meeting.
Page 57/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
RQE-0012
Perform / support the SW Requirements Review (ML-SWRR)
RQE-0013
Deliver PRJ 0.2.0 delivery package (ML-SWRRU) within 10 working days
after the review meeting.
4.2.3 WP-03, Architecture and Interface Design
ARD-0001
The following Input to the phase shall be considered:
ARD-0002
 Inputs/outputs of previous WP’s.
The purpose of this WP is to define the ”Concrete Architecture” and
interfaces of the system supporting the System Concept..
ARD-0003
Produce user interface mock-ups (see SR-0053) to demonstrate/understand
the possibilities offered by the candidate architecture and technology
ARD-0004
Produce the Software Design Document (1/2), EGOS-GEN-FiBOps-SDD1001.
Note: content template defined by AD-0001.
Note: as part of this WP, the document shall detail the ”Concrete
Architecture” of the system.
Note: the Contractor is encouraged to deploy mechanisms/ tools to enable
automated generation / synchronisation of this document and the software
code
ARD-0005
Produce the Interface Control Document (2/2), EGOS-GEN-FiBOps-ICD1001
Note: content template defined by AD-0001
Note: as part of this WP, the document shall specify all interfaces of the
system at detail level.
Note: the Contractor is encouraged to deploy mechanisms/ tools to enable
automated generation / synchronisation of this document and the software
code
ARD-0006
Update and maintain existing deliverable items as per
ARD-0007
Deliver the PRJ 0.3.0 delivery package (ML-PDRD) at least 10 working days
before the review meeting.
Perform / support the Preliminary Design Review (ML-PDR)
Deliver the PRJ 0.4.0 Delivery package (ML-PDRU) within 10 working days
after the review meeting.
ARD-0008
ARD-0009
Table 5-2.
Page 58/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
4.2.4 WP-04, Design and Implementation
DSI-0001
DSI-0002
DSI-0003
The following Input to the phase shall be considered:
 Inputs/outputs of previous WP’s.
The purpose of this WP is to perform:
 Software Design
 Coding and Documentation
 Unit Testing
 Integration Testing
 System Testing
Produce the Software Design Document (2/2),EGOS-GEN-FiBOps-SDD1001.
Note: content template defined by AD-0001
Note: as part of this WP, the document shall specify the Detailed Design of
the system.
Note: Note: the Contractor is encouraged to deploy mechanisms/ tools to
enable automated generation / synchronisation of this document and the
software code
DSI-0004
Produce the Software Validation Specification, EGOS-GEN-FiBOps-SVS-1001
Note: content template defined by AD-0001
Note: this requirement refers only to test cases, test
procedures/specification, and expected result.
DSI-0005
DSI-0006
DSI-0007
DSI-0008
DSI-0009
DSI-0010
DSI-0011
Produce the User Manual shall be documented in
1001
EGOS-GEN-FiBOps-SUM-
Note: content template defined by AD-0001.
Produce the Software Presentation material, EGOS-GEN-FiBOps-PRE-1001
Note: this document shall include:
 Background system information;
 Operational environment;
 Functions of the system;
 Technical information (platform, interfaces, standards, …);
 Known limitations/problems
Produce the Software Release Document, EGOS-GEN-FiBOps-SRelD-1001
Note: content template defined by AD-0001
Produce the Software Problem Report, EGOS-GEN-FiBOps-SRelD-1001
Note: content template defined by AD-0001
Update and maintain existing deliverable items as per Table 5-2.
Deliver the PRJ 0.5.0 delivery package (ML-CDRD) ) at least 10 working days
before the review meeting.
Perform / support the Critical Design Review (ML-CDR)
Page 59/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
DSI-0012
Deliver the PRJ 0.6.0 delivery package (ML-CDRU) within 10 working days
after the review meeting.
4.2.5 WP-05, Provisional Software Acceptance
PA-0001
PA-0002
PA-0003
The following Input shall be considered:
 Inputs/outputs of previous WP’s.
The purpose of this WP is for ESA to perform the validation of the system in
the Infrastructure Integration Environment.
Perform PRJ 1.0.0 Test Readiness Review
Note: ESA may request to attend the TRR.
PA-0004
PA-0005
PA-0006
Deliver PRJ 1.0.0 Delivery package (ML-AR1D)
Install PRJ 1.0.0 Delivery package (ML-AR1D) in ESOC and ESTEC’s
integration environment.
Perform PRJ 1.0.0 Provisional Software Acceptance Test (P-SAT) against the
Technical Specification at ESOC’s premises.
Note: This task Is to be performed by ESA representative(s).The Contractor
shall support ESA representative(s) during P-SAT if requested.
PA-0007
Perform / support the Acceptance Review 1 (ML-AR1)
PA-0008
Implement requested updates iterating from PA-0003 to PA-0007 until
declaration by ESA of Provisional Acceptance (ML-AR1C).
Note: Provisional Acceptance will be declared by ESA subject to non
existence of Critical OR Urgent problems.
Note: a complete delivery package, increasing the unplanned version ID,
shall be produced per iteration.
Note: current scheduled date of ML-AR1C shall be considered only for initial
planning purposes. Final date depends on the number of iterations from PA0003 to PA-0007.
4.2.6 WP-06, Final Software Acceptance
FA-0001
FA-0002
FA-0003
FA-0004
The following Input shall be considered:
 Inputs/outputs of previous WP’s.
The purpose of this WP is for ESA to perform the validation of the system
(checkout) in the Operational Environment.
In the event that the development of the space segment software has been
carried out on the Linux RASTA Emulator (see section 3.3) migrate this to
run on the actual RASTA hardware.
Update PRJ 1.0.0 Delivery package according to PA-0008
Page 60/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
FA-0005
Perform PRJ 1.1.0 Test Readiness Review.
FA-0006
FA-0007
Note: ESA may request to attend the TRR.
Deliver PRJ 1.1.0 Delivery package (ML-AR2D)
Install PRJ 1.1.0 Delivery package (ML-AR2D) in ESOC’s integration
environment.
FA-0008
Perform / support the Acceptance Review 2 (ML-WAS).
FA-0009
Implement requested updates iterating from FA-0004 to FA-0008 until
declaration by ESA of Final Acceptance (ML-WAE).
Note: Final Acceptance will be declared by ESA subject to correction of all
non-compliances
Note: a complete delivery package, increasing the unplanned version ID,
shall be produced per iteration.
Note: current scheduled date of ML-WAE shall be considered only for initial
planning purposes. Final date depends on the number of iterations from FA0004 to FA-0008.
FA-0010
4.2.7
The Contractor shall support the Software Presentation at ESOC, including a
live presentation of the developed software.
WP-07, Warranty
WA-0001
The Contractor shall provide a three-month warranty work package to begin
at the date of successful Final Software Acceptance.
WA-0002
The warranty period shall cover the correction of any errors found in the
deliverables, including software, configuration or data documentation.
WA-0003
Until the end of the warranty period, the Contractor shall be responsible to
fix all errors found in the deliverables.
WA-0004
The Contractor shall implement a sound approach to Corrective
Maintenance, in particular, to ensure that critical and urgent anomalies, as
identified by the Configuration Control Board are resolved within two
working days.
Page 61/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
4.3
Meetings
ME-0001
The Kick-off meeting, performed to signal the beginning of the project,
addresses management and technical issues.
ME-0002
Monthly Progress Meetings, performed on a monthly basis, address
managerial issues.
Note: these Meetings shall be supported by the documentation identified in
MGT-0010 and MGT-0011
ME-0003
Sprint Planning Meetings shall be held at the beginning of each sprint.
ME-0004
Sprint Review and Sprint Retrospective Meetings shall be held at the end of
each sprint.
ME-0005
Technical Meetings will be held as required if requested by the Contractor or
the Agency.
ME-0006
Formal Review Meetings, performed as per AD-0001, address the formal
review of deliverable items.
ME-0007
Note: Formal review meetings should be combined with Sprint
Demonstration Meetings whenever possible.
The standard requirements in Appendix 3, Section 3 of the Contract shall be
applicable to this activity.
Page 62/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
4.4
Work Location and Environment
WL-0001
Meetings and other activities shall be at the locations defined in Table 4-1
Work Location and Environment.
WL-0002
The main part of the work shall be done off-site (i.e. not at ESOC).
Milestone
Meeting/Activity
Description
ML-KO
Kick off
ML-SWRR
SW requirements review
ML-PDR
Preliminary design review
ML-CDR
Critical Design review
ML-AR1
Preliminary Acceptance
review
ML-AR2
Final Acceptance Review
ML-PRE
Final Study Presentation
Regular Meetings
Sprint Planning, Sprint
Review and Sprint
Retrospective Meetings
Location
Comments
ESOC
ESOC
ESOC
ESOC
ESOC
ESOC
ESOC
ESOC
Technical Meetings
ESOC
Monthly Progress Meetings
ESOC
Face-to-face meetings are
required for the first sprints.
After that WebEx or videoconference may be used if
meeting at ESOC is not
possible.
In case a meeting at ESOC is
not possible, WebEx or videoconference may be used.
In case a meeting at ESOC is
not possible, WebEx or videoconference may be used.
Table 4-1 Work Location and Environment
Page 63/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
5
DELIVERABLES, SCHEDULE AND MILESTONES
5.1
Deliverables
5.1.1.1 Delivery Items
5.1.1.1.1
DD-0001
Documentation Delivery Items
In accordance with the requirements specified in Section 4, the Contractor
shall create/update/review all documentation items listed in Table 5-1 and
Table 5-2
Legend:
C: Created, U: Updated, R: Reviewed
yymm: year/month, yyww: year/week
tnnn:
t=0 Kick Off Meeting, t=1 Monthly Progress Meeting, t=2 Technical
Coordination Meeting,
t=3 SWRR, t=4 PDR, t=5 CDR, t=6 AR1, t=7 AR2, nnn= 001 – 999 Id.
DD-0002
All produced documents shall use the standard EGOS document template
(see [AD-0026]) or those specified in [AD-0001] as appropriate and follow
the documentation guidelines specified in [AD-0026] providing all
mandatory Microsoft Word property fields.
DD-0003
All produced documents shall bear an ESA Security Marking according to
AD-0034. The ESA Technical Officer shall decide the applicable marking.
Note: For this activity it is assumed that all produced documents shall be
‘ESA UNCLASSIFIED – For official use’ per default.
DD-0004
For new documents created under the present activity the document
reference, issue and revision numbers shall comply with the numbering
scheme defined in AD-0022.
The Contractor shall request to ESA Technical Officer the document
references required.
DD-0005
Documents produced by the Contractor shall have a change log that allows
tracing the implemented changes within the document.
DD-0006
Documentation Data Packages (e.g. all the documents provided as input to a
Review Meeting) shall contain a ‘Documentation Configuration Control List’’
providing for each delivered document the following information:
 Unique Document Reference (short and full)
 Document short ID
 Document Title
 Document Version
 Approval status.
Page 64/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
DD-0007
All the documentation shall be provided in computer readable format. All
documentation shall be delivered in PDF format. Along with the PDF format
copy, an editable electronic copy of all documentation (Microsoft Word,
PowerPoint …) shall also be provided to the Agency. All computers
formatting must be agreed with the Agency.
DD-0008
Documents (electronic and otherwise) shall be totally self-contained, i.e.,
figures, diagrams, etc. shall be inserted/embedded within the text, where
they are needed.
DD-0009
The Contractor shall deliver the documentation in electronic format with an
electronic signature.
DD-0010
The documents delivered to the Agency for approval shall be signed by the
Contractor’s Technical Responsible, the Project Manager and the QA
Manager.
DD-0011
The Contractor shall ensure that electronic documents do not contain any
harmful code (e.g. virus).
DD-0012
The Contractor shall insert the following copyright statement on the first
page following the cover page of any document for which ESA owns the IPR:
"The copyright of this document is vested in the European Space Agency.
This document may only be reproduced in whole or in part, stored in a
retrieval system, transmitted in any form, or by any means e.g.
electronically, mechanically or by photocopying, or otherwise, with the
prior permission of the Agency."
DD-0013
The Contractor shall insert the following copyright statement (with the years
set as applicable) in the footer of each page of any document for which ESA
owns the IPR, including the cover page, using a font size of 8:
"© Copyright European Space Agency, 20xx"
For both documentation and software “xx” shall indicate each year, in which
the document/software was created, modified and/or updated.
DD-0014
The Contractor shall insert the following copyright statement in all software
files as a comment in the header:
"© Copyright European Space Agency, 20xx"
For both documentation and software “xx” shall indicate each year, in which
the document/software was created, modified and/or updated.
NOTE: This requirement applies only to the files in which the copyright
statement can technically be inserted without corrupting the file (e.g. source
code files).
Page 65/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
DD-0015
The reference to a copyright shall mention each and every year, when a
document or software was created and when a modification was made to a
document or software, e.g.:
"© Copyright European Space Agency, 20xx"
For both documentation and software “xx” shall indicate each year, in which
the document/software was created, modified and/or updated.
ML-WAS
ML-AR1
ML-CDR
ML-PDR
ML-SWRR
Documentation Description
Item
ML-KO
The standard requirements in Appendix 3, Section4 of the Contract shall be
applicable to this activity with the following exceptions:
 A Brochure (4.1.6) is not required.
 A Project Web Page (4.4) is not required.
Event
driven
DD-0016
EGOS-GENSoftware
C/R/U U/R/U U/R/U U/R/U U/R/U U/R/U
FiBOps-SDP-1001 Development
Plan
Software
Configuration
Management
Plan
Software
Product
Assurance
Plan
EGOS-GENMonthly
C/R/U
FiBOps-MPRProgress
yymm
Report
EGOS-GENMeeting
C/R/U
C/R/U C/R/U C/R/U C/R/U C/R/U
FiBOps-MIN-tnnn Minutes
Table 5-1 Documentation Delivery Items – Management
Page 66/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
EGOS-GENFiBOps-GLO-1001
EGOS-GENFiBOps-DCL-1001
EGOS-GENFiBOps-TN-1001
Glossary
Document
Control List
Space Segment
Trade-off
Analysis.
EGOS-GENGround Segment
FiBOps-TN-1002
Trade-off
Analysis.
EGOS-GENSoftware
FiBOps-SRS-1001
Requirements
Specification
EGOS-GENInterface Control
FiBOps-ICD-1001
Document
EGOS-GENSoftware Design
FiBOps-SDD-1001 Document
EGOS-GENSoftware
FiBOps-SVS-1001
Validation
Specification
EGOS-GENSoftware User
FiBOps-SUM-1001 Manual
EGOS-GENSoftware Release
FiBOps-SRelD-1001 Document
Configuration
and Installation
Guide
Software Problem
Report
EGOS-GENFinal Study
FiBOps-PRE-1001 Presentation
MLWAS
ML-AR1
MLCDR
Description
MLPDR
Documentation
Item
MLSWRR
Error! Unknown document property name.
C/R/U U/R/U U/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U
C/R/U U/R/U U/R/U
Table 5-2 Documentation Delivery Items - Technical
Page 67/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
5.1.1.2 Software Delivery Items
The generic term “Software” in this SOW in the broad sense and refers to any kind of
software/firmware “code” developed under this contract; e.g. “C” Code software as well as
UNIX/Linux scripts etc.
Table 5-3 Software Deliverables shows the software deliverables together with the release
numbers to be used.
Delivery Set
(see AD-0015)
Sprint
Deliveries
Documentation
Source
0.<x>.0
M-DEM
1.0.0
issue-x
1.0.0
issue-x
M-AR
1.1.0
issue-x
1.1.0
issue-x
Table 5-3 Software Deliverables
Note: The Documentation Delivery Set should be included on the Source Delivery Media
as well.
DS-0001
The deliverable software shall be managed as specified in the Software
Configuration Management Plan [AD-0022].
DS-0002
The Contractor shall deliver all Software Delivery Items according to Table
5-3 Software Deliverables.
DS-0003
Any copyright statements rules defined in Section 5.1.1.1.1 shall be fully
applicable here.
DS-0004
The Contractor shall submit the software to ESA on delivery media like CDROM(s) or DVD(s) to be agreed with the ESA TO.
Page 68/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
DS-0005
For all software developed under this contract the source code shall be
delivered. This includes all files required to build the system (e.g. "include"
and "make" files, design files for CASE tools, etc.) as well as all test software
used for acceptance testing.
The list of software items specified here is tentative only:







DS-0006
Both source code and executable of the application software/firmware;
Software needed for system installation;
Any test software and Simulators developed for testing (e.g. test
scripts, test data, etc.);
Target platforms' system software (e.g. additional software tools
needed for correct operation of the system, etc.);
Any 3rd Party Products software required to run the application and to
develop the system is deliverable.
The Software Development Environment (SDE) and CASE tools used
for development.
Clear instructions on how to compile, install and deploy the developed
software.
The Contractor shall provide with every software delivery milestone virtual
machines (based on VMWARE) containing all the software necessary for this
project already installed and running.
NOTE: This only applies for software intended for the ground segment and
the Linux RASTA Emulator.
DS-0007
For further details on the Agency’s requirements for Operational Software
reference is made to Part II of the GCC.
Page 69/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
5.2
Schedule and Milestones
SM-0001
SM-0002
SM-0003
The Contractor shall establish a schedule that is consistent with the planned
start of work and milestones identified in Table 5-4.
Any deviation shall be identified and duly justified.
The Contractor shall monitor the major milestone schedule indicated in Table
5-4. Any deviations shall be duly justified.
Each payment shall be subject to acceptance by ESA, the conditions for
‘successful’ acceptance being obtained by a certificate sent by the Technical
Officer.
Milestone
ML-KO
ML-TND
Description
Kick-Off Meeting
Timeline
2012/07/16
Payment
WP-02, Requirements Engineering
Initial delivery of TNs specified in SR-0026,
ML-KO + 2
SR-0027 and SR-0028
Months
2012/09/16
ML-TNR
Review meeting for TNs
ML-TND + 2
Weeks
2012/09/30
ML-TNU
Delivery of updated TNs
ML-TNR+ 2
Weeks
2012/10/14
MLSWRRD
PRJ 0.1.0
ML-SWRR delivery packages
for review
ML-KO+ 4
Months
2012/11/16
ML-SWRR
SW Requirements Review (SWRR)
ML-SWRRD +
2 Weeks
2012/11/30
MLSWRRU
PRJ 0.2.0
ML-SWRR delivery packages
update
ML-SWRR+2
Weeks
30 %
2012/12/14
ML-PDRD
WP-03, Architecture and Interface Design
PRJ 0.3.0
ML-PDR delivery packages for
ML-KO + 8
review
Months
2013/03/16
Page 70/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
Milestone
ML-PDR
Description
Preliminary Design Review (PDR)
Timeline
ML-PDRD + 2
Weeks
Payment
2013/03/30
ML-PDRU
PRJ 0.4.0
ML-PDR delivery packages
update
ML-PDR + 2
Weeks
20 %
2013/04/13
ML-CDRD
PRJ 0.5.0
WP-04, Design and Implementation
ML-CDR delivery packages for
ML-KO + 18
review
Months
2014/01/16
ML-CDR
Critical Design Review (CDR)
ML-CDRD + 2
Weeks
2014/01/30
ML-CDRU
PRJ 0.6.0
ML-CDR delivery packages
update
ML-CDR + 2
Weeks
30 %
2014/02/13
ML-AR1D
PRJ 1.0.0
WP-05, Provisional Software Acceptance
ML-AR1 delivery packages for
ML-CDRU + 2
review
Weeks
2014/02/27
ML-AR1
Provisional Acceptance Review (AR1)
ML-AR1D + 2
Months
2014/04/27
ML-AR1C
Provisional Acceptance Certificate
ML-AR1 + 1
Week
2014/05/04
ML-AR2D
PRJ 1.1.0
WP-06, Final Software Acceptance
ML-WAS delivery packages for
ML-AR1C + 1
review
Month
2014/06/04
ML-AR2
Final Acceptance Review (AR2)
ML-AR2D + 2
Months
2014/08/04
Page 71/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.
Error! Unknown document property name.
Milestone
ML-AR2C
Description
Final Acceptance Certificate
Timeline
ML-AR2 + 1
Week
Payment
2014/08/11
ML-PRE
Final Study Presentation
ML-AR2 + 2
Weeks
2014/08/18
ML-WAS
Start of warranty
ML-AR2C
2014/08/11
ML-WAE
End of warranty
ML-WAS + 3
months
20 %
2014/11/11
Table 5-4 Schedule and Milestones
Page 72/72
Error! Unknown document property name.
Date Error! Unknown document property name. Issue Error! Unknown document property name. Rev Error!
Unknown document property name.