Introduction - ESAemits.sso.esa.int/emits-doc/ESOC/6994/6994ews.docx · Web viewESA UNCLASSIFIED...

esocEuropean Space Operations Centre

Robert-Bosch-Strasse 5D-64293 Darmstadt

GermanyT +49 (0)6151 900

F +49 (0)6151 90495www.esa.int

File Based Operations Study

Statement of Work

Prepared byReference EGOS-GEN-STU-SOW-1001Issue 0Revision 2Date of Issue 03/04/2012Status IssueDocument Type SOWDistribution

ESA UNCLASSIFIED – Releasable to Public

TABLE OF CONTENTS:

1 INTRODUCTION........................................................................................41.1 Purpose and Scope of the Document................................................................................41.2 Background of the Project................................................................................................51.3 Objectives of the Activity..................................................................................................61.3.1 Space Segment................................................................................................................81.3.2 Ground Segment...........................................................................................................101.3.3 Operations Scenarios to be Considered.........................................................................111.4 References.......................................................................................................................191.4.1 Applicable Documents..................................................................................................191.4.2 Reference Documents...................................................................................................221.4.3 Definition and Terms....................................................................................................231.4.4 Acronyms and Abbreviations........................................................................................242 ASSUMPTIONS, CONSTRAINTS AND CUSTOMER FURNISHED ITEMS. .252.1 Assumptions...................................................................................................................252.2 Constraints......................................................................................................................252.2.1 General Constraints......................................................................................................252.2.2 Intellectual Property Rights Constraints......................................................................252.2.3 SDE Constraints............................................................................................................252.2.4 Baseline Constraints.....................................................................................................262.2.5 Implementation Constraints........................................................................................262.2.6 Other Constraints..........................................................................................................262.2.7 Third Party Products Constraints.................................................................................272.3 Customer Furnished Items.............................................................................................283 STUDY REQUIREMENTS.........................................................................303.1 User Requirements.........................................................................................................313.2 Functional requirements................................................................................................343.2.1 Space Segment..............................................................................................................343.2.2 Ground Segment...........................................................................................................353.3 Development and demonstration requirements............................................................383.4 Interface requirements...................................................................................................413.5 Resources requirements.................................................................................................423.5.1 Space Segment..............................................................................................................423.5.2 Ground Segment...........................................................................................................423.6 Design requirements......................................................................................................433.7 Implementation requirements.......................................................................................443.8 Security and Privacy requirements................................................................................453.9 Quality requirements......................................................................................................463.10HMI requirements..........................................................................................................473.11 Reuse and reusability requirements..............................................................................483.12Verification, Validation and Acceptance Requirements................................................494 WORK TO BE PERFORMED.....................................................................514.1 Project Logic....................................................................................................................514.2 Project Phases.................................................................................................................51

/71

Date 03/04/2012 Issue 0 Rev 2


4.2.1 WP-01, Management....................................................................................................524.2.2 WP-02, Requirements Engineering..............................................................................544.2.3 WP-03, Architecture and Interface Design..................................................................554.2.4 WP-04, Design and Implementation............................................................................564.2.5 WP-05, Provisional Software Acceptance.....................................................................574.2.6 WP-06, Final Software Acceptance...............................................................................574.2.7 WP-07, Warranty..........................................................................................................584.3 Meetings..........................................................................................................................594.4 Work Location and Environment..................................................................................605 DELIVERABLES, SCHEDULE AND MILESTONES....................................615.1 Deliverables.....................................................................................................................615.2 Schedule and Milestones................................................................................................67

/71



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.

/71



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-32). 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.

/71



Future ESA missions will also involve complex topologies which potentially include multi-hop 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.

/71



1.3 Objectives of the ActivityThis activity is intended to demonstrate the feasibility of end-to-end file based operations, based on the concept described in [AD-2], 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-4), 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-2] 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.

/71



Appendix B of [AD-2] 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.

/71



1.3.1 Space SegmentFrom these requirements in Appendix B of [AD-2] 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.NOTE: Encapsulation packets are not shown on the above figure as they are not 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

/71


Physical

Data Link

Network

Transport

Application

Space Packet Protocol

PUS

Radio Frequency and Modulation

Conv. Code RS. Code Turbo Code CLTU & PLOPslTM Frame Sync BCH Code

AOS SpaceData Link

Prox 1. SpaceData Linkl

COP1

TC SpaceData Link

TM SpaceData Link

CFDP SOIS FileUtilisation

PUS Svcs1 - N

File TransferPUS Svcs

File Mngt.PUS Svcs

File Util.PUS Svcs

Figure 1: CCSDS Space/Ground Communications Protocol Stack Showing PUS, SOIS and FUS


the case for example if it is required to 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-31].

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-2]. These form one of the core activities of the study. Access to the FUS is expected to be provided by extensions to the PUS.

/71



User Applications supporting Ground/Space Files Exchange

File Transactions Processor

Ground File Store

File Delivery Protocol

TM Receiver & Distributor TC Handler & Releaser

Network Interface (SLE Service User)

Files

TransactionsHistory Log

File Transactions API

S/C File Store Image

TM packets

FilesUtilisation

Apps

CommandSource

TM Data

Figure : High-level architecture of the Control System components supporting File based Operations

File Transctn. History Log

File Recptn. History Disp.

File Transmn. History Disp.

File Transctn. Manager

On-board File Store

Browsr.

1.3.2 Ground SegmentAs 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-2]) 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.

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-38).

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-31].

/71



1.3.3 Operations Scenarios to be ConsideredThis section defines the various monitoring and control scenarios which are considered as relevant to the study. Section 5.4.2 of [AD-2] 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/downlink2. Spacecraft Control with direct access to uplink/downlink. File Delivery to ground

station3. Spacecraft Asset Control via Relay

The proposed approach for the above scenarios is described in the following sections.

/71



1.3.3.1 Spacecraft Control with direct access to uplink/downlink

This scenario is taken from Section 5.4.2.1 of [AD-2] and is illustrated in the following figure.

SLE

TerrestrialBearer TM/TC

Control Centre

SLE

TerrestrialBearer

PUS CFDP

TM/TC

PUSCFDP

CCSDS Space Link ProtocolsSLE ProtocolsOver TCP/IP

CFDP Class 1 or 2

PUS

Ground Station Spacecraft

Figure 2: Proposed solution for file based Spacecraft Control operations

Figure 2 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 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 cross-support 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

/71



protocols between the service provider and the mission assets (namely, SLE and TM/TC Packets over the Space Link).

/71



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-2] 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.

SLE


Control Centre

SLE

TerrestrialBearer

PUS CFDP

TM/TC

PUSCFDP

CCSDS Space Link Protocols

SLE ProtocolsOver TCP/IP

CFDP Class 1 or 2

PUS

Ground Station Spacecraft

CFDP

CFDP(Downlink only)

CFDP PDUs for Uplink via OCCTBD Protocol

Figure 3: Proposed solution for file based Spacecraft Control operations. File Delivery to ground station

Figure 3 above shows the proposed solution to accommodate file based operations in the scenario of spacecraft monitoring and control

/71



based on a ground station network ensuring 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 cross-support 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. 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.

2. 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.

3. Some groundstation passes may take place with downlink only, i.e. no uplink occurs during the pass.

/71



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 downlink only passes, as the appropriate CFDP PDUs (for retransmission, requesting file downlink etc.) could be uplinked some time previously.

Figure 4: 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.

/71


FileStore

CFDPEntity

MIBCFDPUser

G/S 1

CFPD PDUForwarder

PayloadData System TMTCS

Packetiser

FileStore

CFDPEntity

MIBCFDPUser

G/S 2

CFDP PDUForwarder

PayloadData System TMTCS

Packetiser

TCChain

TM Chain

GS 2 CFDPPDUs

GS 1 CFPDPDUs

CFDP PDUReceiver

FileStore

CFDPEntity

MIBCFDPUser

TC TimeTagger ?

MCS


1.3.3.3 Spacecraft Asset Control via Relay

This scenario is described in Section of 5.4.2.2 of [AD-2] 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-2]. 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.

/71



SLE


RelayControlCentre

SLE

TerrestrialBearer

PUS CFDP

Proximity-1

PUSCFDP

CCSDS Space Link Protocols

SLE ProtocolsOver TCP/IP

CFDP Class 1 or 2

PUS

Ground Station SpaceAsset

TerrestrialBearer

SpaceAsset

ControlCentre

Terrestrial FileTransfer Protocol

TM/TC Proximity-1

CFDP Store & Forward

PUS CFDPCFDP PUS

File Proc.

Proximity-1

Relay

PUS

CFDP Class 1 or 2

Figure 5: Proposed solution for file based Space Asset Control operations via a Relay in space

Figure 5 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

/71



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 transfero 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 scenario.

Figure 6: File based Space Asset Control operations via a Relay in space – interactions.

/71


DirectTM/TC

Lander - OrbiterCCSDS Protocols

CFDP

SPP

File, SPP, Direct TM/TC Proxy

(mission specific application)

Packet SAP

CFDP

SPP

CFDP

SPP

TM, TC, AOS

Cod. RF & Mod

CFDP

SPP

File, SPP, Direct TM/TC proxy

(mission specific app)

TM, TC, AOS

Cod. RF & Mod

CSTSFile

Forward/Return

TerrestrialN

etworks

CSTSFile

Forward/Return

CFDP, Space Packet and TM/TC/AOS Frame services

CSTSGround File

Transfer Services

FilesPUS

Packets

DirectTM/TC

Files Files

PUSPackets

Terrestrial Networks Spacelink

CFDP, Space Packet and Prox-1 Frame

services

Spacelink

Packet SAP

CFDP

SPP

Prox-1

CFDP

SPP

TM/TC,AOS Prox-1 Prox-1

Files

Space - GroundCCSDS Protocols

Relay Space AssetRelay CCSpace AssetCC


1.4 References

1.4.1 Applicable DocumentsThe following documents are to be considered as applicable to the Project:

Id Title Reference Ver. DateAD-1 ECSS-E-ST-40C Space

engineering - Software: Tailoring for Ground Segment Systems

ECSS-Q-ST-80C Space product assurance - Software product assurance: Tailoring for Ground Segment Systems

QMS-EIMO-GUID-CKL-9500-OPS

QMS-EIMO-GUID-CKL-9501-OPS

1.0

1.2

07.2009

09.2011

AD-2 File Based Operations Concept EGOS-GEN-FbO-RP-0001

1.0 07.01.10

AD-3 Operating system Abstraction layer

TEC-EDD-2007.13-AVS-OSAL-ICD

1.15

AD-4 GR-CPCI-AT697 Development Board User Manual

http://www.atmel.com/dyn/products/product_card.asp?part_id=3178

Rev. 1.1

2005-11-16

AD-5 RASTA Interface Board FPGA User’s Manual

1.1.0 May 2010

AD-6 RASTA interface board RTEMS device drivers

1.2.1.0

March 2012

AD-7 RASTA TMTC Board FPGA User’s Manual

1.0.7 Feb. 2009

AD-8 TM/TC Onboard Stack Library Interface Control Document And Design Notes

TEC-EDS-2010.68-AVS-OTMTC-ICD

1.2 2009-12-15

AD-9 File and Packet Store Services - Interface Control Document

TEC-EDD-2010.77-AVS-FPSS-ICD

1.5

AD-10 File and Packet Store Services - Software User Manual

TEC-EDS-2010.85-AVS-FPSS-SUM

1.3 2011-01-30

AD-11 S2K-R5.4.x Document PackAD-12 EUD 2.x Document PackAD-13 CFDP 1.x Document PackAD-14 FARC 2.1.x Document PackAD-15 ESOC Generic Ground Systems:

Development Requirements Specification

EGGS-ESOC-GS-SRS-1001

1.1.1 31.10.2008

/71






Id Title Reference Ver. DateAD-16 ESOC Generic Ground Systems:

System Configuration Baselines: Part 1 - Procedures

ESOC Generic Ground Systems: System Configuration Baselines: Part 2 - Software Package Specification

ESOC Generic Ground Systems: System Configuration Baselines: Part 3 - Baseline Definitions

EGGS-ESOC-GS-SCD-1002



1.0

1.1

1.3

16.09.08

23.07.10

04.08.11

AD-17 License disclaimer Disclaimer 1.5 19.09.08AD-18 EGOS namespace conventions Proposal for EGOS

Namespace Convention1.1 01.02.08

AD-19 Java Coding Standards BSSC 2005(2) 1.0 03.03.05AD-20 Design & Style Guide for XML

Data and SchemaBSSC 2004(3) 1.0 31.03.05

AD-21 Implementation Of The ESA Network Security Policy

EISD-EPNS-00003 2.2.1 28.09.04

AD-22 Software Configuration Management Plan

EGOS-GEN-GEN-CMP-1001

1.2 11.09.09

AD-23 Implementation Of The ESA Network Security Policy for OPS-NET

DOPS-COM-POL-34555-OPS-ECT

2.3 09.11.07

AD-24 Software Quality and Coding Rules

EGOS-QA-XX-TN-9007 1.5 Draft C

09-06-2009

AD-25 SCOS-2000 System regression test automation

egos-mcs-s2k-tn-5003 1.2 2010-03-25

AD-26 EGOS Template Guidelines EGOS-GEN-GEN-TN-0xyz

3.0 2007-11-01

AD-27 Project Tracking BIRFSW ICD EGOS-GEN-BIRFSW-ICD-1001

1.1 18.01.10

AD-28 Project Tracking BIRFSW MPR EGOS-STU-BIRFSW-TN-1002

2.4 16.11.2010

AD-29 Ken Schwaber, Jeff Sutherland: The SCRUM Guide

http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf

2010

AD-30 NIS/NCTRS Volume 2- Detailed interface Definition: MCS

EGOS-NIS-NCTR-ICD-0002

4.0.2 06.11.2009

AD-31 Spacecraft Onboard Interface Services (SOIS) – File and Packet Store Services

CCSDS 873.0-R-2 2 Jan 2011

/71






Id Title Reference Ver. DateAD-32 Ground systems and operations —

Telemetry and telecommand packet utilization (PUS)

ECSS-E-70-41A A Jan. 2003

AD-33 CCSDS File Delivery Protocol, Recommended Standard, Blue Book

CCSDS 727.0-B-4 Jan. 2007

AD-34 ESA Security Directives ESA/ADMIN/IPOL(2008)6, Annex 2

2008-10-20

/71



1.4.2 Reference DocumentsThe following documents are to be considered as reference to the Project:

Id Title Reference Ver. DateRD-1 Spacecraft Onboard Interface

Services (SOIS) – Informational Report

CCSDS 850.0-G-1 1 June 2007

RD-2 CCSDS Space Packet Protocol CCSDS 133.0-B-1 1 Sept. 2003

RD-3 CCSDS Report – Overview of Space Communication Protocols

CCSDS 130.0-G-2 2 Dec. 2007

RD-4 Ground Segment Data System Architecture to Support CFDP, DTN and IP – FINAL REPORT

SSL/CFDPB/RP/001 1.2 Feb. 2011

/71



1.4.3 Definition and TermsTerm 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.

”Reference Architecture”

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.

”Concrete Architecture”

A specific instance of a reference architecture tied to specific standards, technologies, implementations, deployments, or other concrete selection of options and attributes.

”Smoke Test” 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 Predeliveries”

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 Appliance”

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 pre-integrated 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”

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” “Work Results” mean all results of Contractor’s and/or any Sub-Contractor’s work rendered under this Project.

/71



http://www.vmware.com/appliances/learn/overview.html

1.4.4 Acronyms and Abbreviations

Acronym / Abbreviation DescriptionCFI Customer Furnished ItemECC ESTRACK Control CentreEGOS ESA Ground Operation SystemESA European Space AgencyESOC European Space Operations CentreGSS Ground Segment SystemsGSMC Ground Station Monitoring and ControlGSSS Ground Segment Systems StakeholdersHCI Human Computer InteractionHMI Human-Machine InterfaceIPR Intellectual Property RightsITAR International Traffic in Arms RegulationsMCS Mission Control SystemM&C Monitoring and ControlMOI Mission Operations InfrastructureNIS Network Interface SystemOCC Operations Control CentreOPSNET (ESOC) Operations Communications NetworkOS Operating SystemRID Review Item DiscrepancyS/C SpacecraftSDD Software Design DocumentSDE Software Development EnvironmentSOW Statement Of WorkSUM Software User ManualTBC To be confirmed (by the Agency)TBD To be determined (by the Contractor)TBS To be specified (by the Agency)TRP Technology Research ProgrammeTO Technical Officer

/71



2 ASSUMPTIONS, CONSTRAINTS AND CUSTOMER FURNISHED ITEMS

2.1 Assumptions

AR-1 New versions of applicable documents may be provided at KO.

2.2 Constraints

2.2.1 General ConstraintsCR-1 All requirements in the ESOC Generic Ground Systems: Development

Requirements Specification [AD-15] shall be applicable to the work subject of this SoW.

2.2.2 Intellectual Property Rights ConstraintsCO-1 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 ConstraintsCO-2 IBM Rational Change (CFI-SWI-) shall be used, to generate/manage

SPR/SCR related information.

/71



2.2.4 Baseline ConstraintsCO-3 Initial development of the system shall start on SLES 11 using the baseline

from the EGGS System Configuration Document (AD-16) 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-16) will be;

Platform baseline SLES11-064-ESOCL01-I1R0

Application baseline EGOS-X86-064-OPS-I1R0 (for run-time)

Application baseline EGOS-X86-064-OPS-I1R0 (for development)

CO-4 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 ConstraintsCO-5 The User Interface shall be exclusively based on the EGOS User Desktop, see

AD-12.

2.2.6 Other ConstraintsCO-6 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-7 All activities, reports, correspondence, deliverables and tools covered by this SoW shall be in British English.

/71



2.2.7 Third Party Products ConstraintsCO-8 Only 3rd party products according to AD-16 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.

/71



2.3 Customer Furnished Items

CFI-1 ESA is committed to provide only the items listed in Table 2-1 Customer Furnished Items.

CFI-2 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.

CFI-3 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.

CFI-4 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 (CFI-SWI-).

CFI-5 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.

CFI-6 Access to SDE tools/licenses requires the setup of local infrastructure and remote access to license managers.

CFI-7 Access to SDE tools will be provided only after the Contractor has signed the relevant agreement

CFI Identifier Description Delivery Date

DocumentationCFI-DOC- The latest available version for all applicable documents (see

1.4.1)ML-KO

CFI-DOC-7 BIRF Excel Template for monthly reporting ML-KO

Software InfrastructureCFI-SWI- Software to be reused: (SLES 11 baseline)

S2K-R5.4.x EUD 2.x CFDP 1.x FARC 2.1.x

ML-KO (TBC)

CFI-SWI-7 Access to IBM Rational Change server for Change Management

ML-KO

/71



CFI-SWI- For the Linux based RASTA Emulator system:

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- 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

ML-KO

Table 2-1 Customer Furnished Items

/71



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-2] and tailored in Section 1.3 of this Statement of Work. In particular the following scenarios shall be considered.

SR-1 The study shall provide an end-to-end demonstration of file based operations, based on concepts described in [AD-2] 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-2 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-3 The space asset shall be modelled by using the ESTEC Reference Architecture System Test-bed for Avionics (RASTA). [AD-3 - AD-10]

SR-4 All requirements specified in Appendix B of [AD-2] 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.

/71



3.1 User RequirementsThis section outlines high level user requirements extracted from [AD-2].

SR-5 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-6 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-7 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-8 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-9 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-10 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.

/71



SR-11 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-12 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-28

SR-13 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-14 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-15 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-16 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-17 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.

/71



SR-18 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-31].

Note: This is so it is straightforward to model the on board file store on the ground system.

SR-19 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 on-board 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-20 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.

/71



3.2 Functional requirements

3.2.1 Space SegmentSR-21 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-22 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-23 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-2] and the technical note produced as specified in requirements SR-21 and SR-22 above.

SR-24 The Software Requirements Specification shall prioritise the software requirements for the space segment as follows:

Essential Essential for the demonstration of end-to-end file based operations.

Desirable Desirable for the demonstration of end-to-end file based operations.

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

/71



SR-25 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-21)

2. Transfer files (using CFDP functionality as per SR-21)

3. Process the files (using the File Utilisation functionality identified as per SR-21)

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 SegmentSR-26 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-27 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.

/71



SR-28 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-29 It shall be possible to systematically dump all files that have been queued on-board.

SR-30 It shall be possible to uplink and downlink multiple files concurrently.

SR-31 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.

SR-32 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 [AD-2] and the technical notes produced as specified in requirements SR-26, SR-27, SR-28 and SR-31 above.

/71



SR-33 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-34 Once the Software Requirements Specification document has been reviewed and accepted a Software Design Document shall be produced.

SR-35 Once the Software Design Document has been reviewed and accepted the system shall be implemented.

/71



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.

/71



Figure 7: 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-36 The software delivered for final acceptance and demonstration must be able to be run on the RASTA system.

/71



SR-37 The final acceptance and demonstration must be end-to-end, involving both RASTA and the MCS.

/71



3.4 Interface requirementsSR-38 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-30]. 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.

/71



3.5 Resources requirements

3.5.1 Space SegmentSR-39 Software developed for the Linux RASTA Emulator shall use the Ubuntu 10.4

or later operating system

SR-40 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 RequirementsSR-41 The hardware baseline shall be compliant with a hardware baseline specified

in [AD-16], part 3, that is compatible with the version of S2K to be used in the activity.

3.5.2.2 Computer Software RequirementsSR-42 The software baseline shall be compliant with a platform baseline specified in

[AD-16] part 3, that is compatible with the version of S2K to be used in the activity.

SR-43 The software baseline shall be compliant with an application baseline specified in [AD-16] part 3, that is compatible with the version of S2K to be used in the activity.

/71



3.6 Design requirementsSR-44 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-45 All classes shall be stereotyped as Platform Dependent or Platform Independent

/71



3.7 Implementation requirementsSR-46 Namespace conventions shall be compliant with AD-18.

SR-47 Java source code shall be compliant with coding conventions as per AD-19.

SR-48 XML source code shall be compliant with coding conventions as per AD-20.

SR-49 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-50 The new components developed for this study should have no direct dependencies on the underlying protocol implementation (e.g. CFDP, TM/TC, PUS).

/71



3.8 Security and Privacy requirementsSR-51 The system shall be compliant with the ESA Security Policy specified by AD-

21 and AD-23.

/71



3.9 Quality requirementsSR-52 100% Requirements Test Coverage shall be achieved.

Note: i.e. All Software Requirements shall be fully verified/validated.

/71



3.10 HMI requirementsSR-53 Mock-ups of any required HMIs shall be provided and these shall be iterated,

taking into account input from ESA on the proposed layouts.

/71



3.11 Reuse and reusability requirementsSR-54 The Control System shall be based on the latest available version at kick-off of

the SLES 11 based S2KR5 software.

SR-55 The Ground file store shall be based on the existing File ARChive (FARC)

SR-56 The File Transaction History Log shall be based on the existing Packet ARChive (PARC)

SR-57 The user interface shall be built on top of the Egos User Desktop (EUD)

SR-58 The ESOC CFDP implementation shall be used.

SR-59 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.

/71



3.12 Verification, Validation and Acceptance RequirementsSR-60 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-61 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-62 Testing shall include, as a minimum:

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.

SR-63 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-64 System Testing shall reach, at least, 30% of automation.

SR-65 The Contractor shall be responsible for the production of any items required to support testing, including test harnesses, input data samples, command procedures.

/71



SR-66 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-2] 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-2].

These shall be documented as part of the Software Validation Specification [EGOS-GEN-FiBOps-SVS-1001].

/71



4 WORK TO BE PERFORMED

4.1 Project LogicSL-1 The Software Engineering methodology shall be compliant with AD-1 and in

particular Tailoring Type 4 as described in AD-1 shall be applicable to the ground segment software developed for this project.

SL-2 The Software Engineering methodology shall be compliant with AD-1 and in particular Tailoring Type 4 as described in AD-1 shall be applicable to the space segment software developed for this project.

SL-3 The project shall follow the SCRUM [AD-29] 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-4 Each sprint shall not take more than six working weeks.

SL-5 As part of the proposal the bidder should produce a draft product backlog.

4.2 Project Phases SP-1 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

/71



SP-2 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-29]).

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-1, ManagementMGT-1 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-2 Perform general project management ensuring proper control over schedule, cost and quality according to AD-1

MGT-3 Provide complete visibility to the Agency of all aspects of the work.

MGT-4 Implement the appropriate management communication lines and ensure a single management authority for all tasks.

MGT-5 Perform sub-Contractor(s) management

MGT-6 Perform risk management, identifying potential risks propose meaningful ways to mitigate them and review the risk status during the different Project phases.

MGT-7 Produce and maintain the Software Development Plan, EGOS-GEN-FiBOps-SDP-1001

Note: content template defined by AD-1

MGT-8 Produce and maintain the Software Configuration Management, EGOS-GEN-FiBOps-SDP-1001


Note: configuration management requirements specified by AD-22 shall be applied.

/71



MGT-9 Produce and maintain the Software Product Assurance plan, EGOS-GEN-FiBOps-SDP-1001


MGT-10 Monthly production of the Monthly Progress Report, EGOS-GEN-FiBOps-MPR-yymm.

Note: BIRF should be used for progress reporting. The content template defined by AD-28 shall be used. The latest version of the template will be provided at ML-KO.

Note: the Monthly Progress Report shall be delivered not later than five working days after the end of the reporting month.

MGT-11 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-12 Support / attend meetings as per section 4.3MGT-13 Delivery of Documentation Items – Management as per Table 5-3

Documentation Delivery Items – Management (at different milestones)MGT-14 The Project Manager shall ensure information, also within his consortium is

only distributed according to the Agency’s rules and regulations (see AD-34) 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-15 The standard requirements in Appendix 3, Section 1 and 2 of the Contract shall be applicable to this activity

/71



4.2.2 WP-2, Requirements EngineeringRQE-1 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-2 The purpose of this WP is to define the main concepts, requirements, use cases of the system and the software to be reused.

RQE-3 Identify use cases and associated requirements to be supported, by involving a representative group of end users.

RQE-4 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-21 and SR-22.

RQE-5 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-26, SR-27, SR-28 and SR-31.

RQE-6 Analyse and refine the Study Requirements specified in Section 3.RQE-7 Produce the Glossary, EGOS-GEN-FiBOps-GLO-1001

Note: this document shall include: Definition of terms Acronyms

RQE-8 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-9 Produce the Software Requirements Specification, EGOS-GEN-FiBOps-SRS-1001


RQE-10 Produce the Interface Control Document (1/2), EGOS-GEN-FiBOps-ICD-1001


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-11 Deliver the PRJ 0.1.0 delivery package (ML-SWRRD) at least 10 working days before the review meeting.

/71



RQE-12 Perform / support the SW Requirements Review (ML-SWRR)

RQE-13 Deliver PRJ 0.2.0 delivery package (ML-SWRRU) within 10 working days after the review meeting.

4.2.3 WP-3, Architecture and Interface DesignARD-1 The following Input to the phase shall be considered:

Inputs/outputs of previous WP’s.ARD-2 The purpose of this WP is to define the ”Concrete Architecture” and

interfaces of the system supporting the System Concept..

ARD-3 Produce user interface mock-ups (see SR-53) to demonstrate/understand the possibilities offered by the candidate architecture and technology

ARD-4 Produce the Software Design Document (1/2), EGOS-GEN-FiBOps-SDD-1001.

Note: content template defined by AD-1.

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-5 Produce the Interface Control Document (2/2), EGOS-GEN-FiBOps-ICD-1001


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-6 Update and maintain existing deliverable items as per Table 5-4.

ARD-7 Deliver the PRJ 0.3.0 delivery package (ML-PDRD) at least 10 working days before the review meeting.

ARD-8 Perform / support the Preliminary Design Review (ML-PDR)ARD-9 Deliver the PRJ 0.4.0 Delivery package (ML-PDRU) within 10 working days

after the review meeting.

/71



4.2.4 WP-4, Design and ImplementationDSI-1 The following Input to the phase shall be considered:

Inputs/outputs of previous WP’s.DSI-2 The purpose of this WP is to perform:

Software Design Coding and Documentation Unit Testing Integration Testing System Testing

DSI-3 Produce the Software Design Document (2/2),EGOS-GEN-FiBOps-SDD-1001.


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-4 Produce the Software Validation Specification, EGOS-GEN-FiBOps-SVS-1001


Note: this requirement refers only to test cases, test procedures/specification, and expected result.

DSI-5 Produce the User Manual shall be documented in EGOS-GEN-FiBOps-SUM-1001

Note: content template defined by AD-1.DSI-6 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

DSI-7 Produce the Software Release Document, EGOS-GEN-FiBOps-SRelD-1001Note: content template defined by AD-1

DSI-8 Produce the Software Problem Report, EGOS-GEN-FiBOps-SRelD-1001Note: content template defined by AD-1

DSI-9 Update and maintain existing deliverable items as per Table 5-4.

DSI-10 Deliver the PRJ 0.5.0 delivery package (ML-CDRD) ) at least 10 working days before the review meeting.

DSI-11 Perform / support the Critical Design Review (ML-CDR)DSI-12 Deliver the PRJ 0.6.0 delivery package (ML-CDRU)

within 10 working days after the review meeting.

/71



4.2.5 WP-5, Provisional Software AcceptancePA-1 The following Input shall be considered:

Inputs/outputs of previous WP’s.PA-2 The purpose of this WP is for ESA to perform the validation of the system in

the Infrastructure Integration Environment.PA-3 Perform PRJ 1.0.0 Test Readiness Review

Note: ESA may request to attend the TRR.

PA-4 Deliver PRJ 1.0.0 Delivery package (ML-AR1D)PA-5 Install PRJ 1.0.0 Delivery package (ML-AR1D) in ESOC and ESTEC’s

integration environment.PA-6 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-7 Perform / support the Acceptance Review 1 (ML-AR1)

PA-8 Implement requested updates iterating from PA-3 to PA-7 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 PA-3 to PA-7.

4.2.6 WP-6, Final Software AcceptanceFA-1 The following Input shall be considered:

Inputs/outputs of previous WP’s.FA-2 The purpose of this WP is for ESA to perform the validation of the system

(checkout) in the Operational Environment.FA-3 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.

FA-4 Update PRJ 1.0.0 Delivery package according to PA-8

FA-5 Perform PRJ 1.1.0Test Readiness Review.

Note: ESA may request to attend the TRR.FA-6 Deliver PRJ 1.1.0 Delivery package (ML-AR2D)

/71



FA-7 Install PRJ 1.1.0 Delivery package (ML-AR2D) in ESOC’s integration environment.

FA-8 Perform / support the Acceptance Review 2 (ML-WAS).

FA-9 Implement requested updates iterating from FA-4 to FA-8 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 FA-4 to FA-8.

FA-10 The Contractor shall support the Software Presentation at ESOC, including a live presentation of the developed software.

4.2.7 WP-7, WarrantyWA-1 The Contractor shall provide a three-month warranty work package to begin

at the date of successful Final Software Acceptance.

WA-2 The warranty period shall cover the correction of any errors found in the deliverables, including software, configuration or data documentation.

WA-3 Until the end of the warranty period, the Contractor shall be responsible to fix all errors found in the deliverables.

WA-4 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.

4.3 MeetingsME-1 The Kick-off meeting, performed to signal the beginning of the project,

addresses management and technical issues.

ME-2 Monthly Progress Meetings, performed on a monthly basis, address managerial issues.

Note: these Meetings shall be supported by the documentation identified in MGT-10 and MGT-11

ME-3 Sprint Planning Meetings shall be held at the beginning of each sprint.

ME-4 Sprint Review and Sprint Retrospective Meetings shall be held at the end of each sprint.

/71



ME-5 Technical Meetings will be held as required if requested by the Contractor or the Agency.

ME-6 Formal Review Meetings, performed as per AD-1, address the formal review of deliverable items.

Note: Formal review meetings should be combined with Sprint Demonstration Meetings whenever possible.

ME-7 The standard requirements in Appendix 3, Section 3 of the Contract shall be applicable to this activity.

/71



4.4 Work Location and EnvironmentWL-1 Meetings and other activities shall be at the locations defined in Table 4-2

Work Location and Environment.

WL-2 The main part of the work shall be done off-site (i.e. not at ESOC).

Milestone Meeting/Activity Description

Location Comments

ML-KO Kick off ESOCML-SWRR SW requirements review ESOCML-PDR Preliminary design review ESOCML-CDR Critical Design review ESOCML-AR1 Preliminary Acceptance

reviewESOC

ML-AR2 Final Acceptance Review ESOCML-PRE Final Study Presentation ESOC

Regular MeetingsSprint Planning, Sprint Review and Sprint Retrospective Meetings

ESOC Face-to-face meetings are required for the first sprints. After that WebEx or video-conference may be used if meeting at ESOC is not possible.

Technical Meetings ESOC In case a meeting at ESOC is not possible, WebEx or video-conference may be used.

Monthly Progress Meetings ESOC In case a meeting at ESOC is not possible, WebEx or video-conference may be used.

Table 4-2 Work Location and Environment

/71



5 DELIVERABLES, SCHEDULE AND MILESTONES

5.1 Deliverables

5.1.1.1 Delivery Items

5.1.1.1.1 Documentation Delivery ItemsDD-1 In accordance with the requirements specified in Section 4, the Contractor

shall create/update/review all documentation items listed in Table 5-3 and Table 5-4

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-2 All produced documents shall use the standard EGOS document template (see [AD-26]) or those specified in [AD-1] as appropriate and follow the documentation guidelines specified in [AD-26] providing all mandatory Microsoft Word property fields.

DD-3 All produced documents shall bear an ESA Security Marking according to AD-34. 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-4 For new documents created under the present activity the document reference, issue and revision numbers shall comply with the numbering scheme defined in AD-22.The Contractor shall request to ESA Technical Officer the document references required.

DD-5 Documents produced by the Contractor shall have a change log that allows tracing the implemented changes within the document.

DD-6 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.

/71



DD-7 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-8 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-9 The Contractor shall deliver the documentation in electronic format with an electronic signature.

DD-10 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-11 The Contractor shall ensure that electronic documents do not contain any harmful code (e.g. virus).

DD-12 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-13 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-14 The Contractor shall insert the following copyright statement in all software files as a comment in the header:



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).

/71



DD-15 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.:



DD-16 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.

Documentation Item

Description

Eve

nt

dri

ven

ML-

KO

ML-

SWR

R

ML-

PDR

ML-

CD

R

ML-

AR

1

ML-

WA

S

EGOS-GEN-FiBOps-SDP-1001

Software Development Plan

C/R/U U/R/U U/R/U U/R/U U/R/U U/R/U

Software Configuration Management PlanSoftware Product Assurance Plan

EGOS-GEN-FiBOps-MPR-yymm

Monthly Progress Report

C/R/U

EGOS-GEN-FiBOps-MIN-tnnn

Meeting Minutes

C/R/U C/R/U C/R/U C/R/U C/R/U C/R/U

Table 5-3 Documentation Delivery Items – Management

/71



Documentation Item

Description

ML-

SWRR

ML-

PDR

ML-

CDR

ML-

AR1

ML-

WAS

EGOS-GEN-FiBOps-GLO-1001

Glossary C/R/U U/R/U U/R/U U/R/U U/R/U

EGOS-GEN-FiBOps-DCL-1001

Document Control List

C/R/U U/R/U U/R/U U/R/U U/R/U

EGOS-GEN-FiBOps-TN-1001

Space Segment Trade-off Analysis.


EGOS-GEN-FiBOps-TN-1002

Ground Segment Trade-off Analysis.


EGOS-GEN-FiBOps-SRS-1001

Software Requirements Specification


EGOS-GEN-FiBOps-ICD-1001

Interface Control Document


EGOS-GEN-FiBOps-SDD-1001

Software Design Document

C/R/U U/R/U U/R/U U/R/U

EGOS-GEN-FiBOps-SVS-1001

Software Validation Specification

C/R/U U/R/U U/R/U

EGOS-GEN-FiBOps-SUM-1001

Software User Manual

C/R/U U/R/U U/R/U

EGOS-GEN-FiBOps-SRelD-1001

Software Release Document

C/R/U U/R/U U/R/U

Configuration and Installation GuideSoftware Problem Report

EGOS-GEN-FiBOps-PRE-1001

Final Study Presentation

C/R/U U/R/U U/R/U

Table 5-4 Documentation Delivery Items - Technical

/71



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-5 Software Deliverables shows the software deliverables together with the release numbers to be used.

Delivery Set (see AD-15)

Sprint Deliveries M-DEM M-AR

Documentation 1.0.0 issue-x

1.1.0 issue-x

Source 0.<x>.0 1.0.0 issue-x

1.1.0 issue-x

Table 5-5 Software Deliverables

Note: The Documentation Delivery Set should be included on the Source Delivery Media as well.

DS-1 The deliverable software shall be managed as specified in the Software Configuration Management Plan [AD-22].

DS-2 The Contractor shall deliver all Software Delivery Items according to Table 5-5 Software Deliverables.

DS-3 Any copyright statements rules defined in Section 5.1.1.1.1 shall be fully applicable here.

DS-4 The Contractor shall submit the software to ESA on delivery media like CD-ROM(s) or DVD(s) to be agreed with the ESA TO.

/71



DS-5 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:

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.

DS-6 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-7 For further details on the Agency’s requirements for Operational Software reference is made to Part II of the GCC.

/71



5.2 Schedule and Milestones

SM-1 The Contractor shall establish a schedule that is consistent with the planned start of work and milestones identified in Table 5-6.

Any deviation shall be identified and duly justified.SM-2 The Contractor shall monitor the major milestone schedule indicated in Table

5-6. Any deviations shall be duly justified.

SM-3 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 Description Timeline PaymentML-KO Kick-Off Meeting 2012/07/16

WP-2, Requirements EngineeringML-TND Initial delivery of TNs specified in SR-26, SR-

27 and SR-28ML-KO + 2 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

ML-SWRRD

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

ML-SWRRU

PRJ 0.2.0 ML-SWRR delivery packages update

ML-SWRR+2 Weeks

2012/12/14

30 %

WP-3, Architecture and Interface DesignML-PDRD PRJ 0.3.0 ML-PDR delivery packages for

reviewML-KO + 8 Months

2013/03/16

/71



Milestone Description Timeline PaymentML-PDR Preliminary Design Review (PDR) ML-PDRD + 2

Weeks

2013/03/30

ML-PDRU PRJ 0.4.0 ML-PDR delivery packages update

ML-PDR + 2 Weeks

2013/04/13

20 %

WP-4, Design and ImplementationML-CDRD PRJ 0.5.0 ML-CDR delivery packages for

reviewML-KO + 18 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

2014/02/13

30 %

WP-5, Provisional Software AcceptanceML-AR1D PRJ 1.0.0 ML-AR1 delivery packages for

reviewML-CDRU + 2 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

WP-6, Final Software AcceptanceML-AR2D PRJ 1.1.0 ML-WAS delivery packages for

reviewML-AR1C + 1 Month

2014/06/04

ML-AR2 Final Acceptance Review (AR2) ML-AR2D + 2 Months

2014/08/04

/71



Milestone Description Timeline PaymentML-AR2C Final Acceptance Certificate ML-AR2 + 1

Week

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

2014/11/11

20 %

Table 5-6 Schedule and Milestones

/71



Introduction - ESAemits.sso.esa.int/emits-doc/ESOC/6994/6994ews.docx · Web viewESA UNCLASSIFIED...

Documents

Transcript of Introduction - ESAemits.sso.esa.int/emits-doc/ESOC/6994/6994ews.docx · Web viewESA UNCLASSIFIED...