→ SPACE SITUATIONAL AWARENESS PRECURSOR PROGRAMME CO-VIII & DC-II Industry Day.

→SPACE SITUATIONAL AWARENESS

PRECURSOR PROGRAMME

CO-VIII & DC-II Industry Day

Emmet Fletcher | SSA Precursor Programme | SSA Industry Day | CO-VIII & DC-IIPage: 2

European Space Agency

- The SSA Precursor Programme

- Precursor Services Objectives

- Past and Present Activities

- Link between CO-VIII and DC-II

- CO-VIII ITT

- Objectives

- Content

- Key issues

- Questions and Answers

OUTLINE



BACKGROUND

Image: Dan Durda – FIAAA



2009 – 2012

• Preparatory Programme

– Governance Definition

– Data Policy

– Architecture

– Federation

– Precursor Services

– Radar Breadboard

– Pilot Data Centres

2013 – 2020

• Development/

Operational Phase

– Development of essential components

– SSA Exploitation

INTRODUCTIONCurrent Objectives



1. Core Element

SSA Architecture

Governance

Data Policy

Security

Space Surveillance and Tracking Segment

2. Space Weather Element

(including NEO activities)

3. Radar Element

Prototype Development

4. Pilot Data Element

Transversal support for all segments

INTRODUCTIONSSA Programme Structure



• Austria

• Belgium

• Finland

• France

• Germany

• Greece

• Italy

• Luxembourg

• Norway

• Portugal

• Spain

• Switzerland

• United Kingdom

Canada (in discussion)

INTRODUCTIONSSA Participating States



INTRODUCTIONSSA Programme Structure

Tasking Centre

SWESpace Weather

Centre

NEONear Earth

Objects Centre

SSTSpace

Surveillance & Tracking Centre



DC-II ITT



SST PRECURSOR SERVICE OBJECTIVES



OVERALL SYSTEM



SSA Preparatory Programme parallel stream

goal is to be able to perform representative

testing of proposed solutions through

precursor services:

– Scaleable solutions

– Representative of full systems

– Provide measurable results with

reduced data set

– Characterise current European

resources

– Enable evaluation of performance

using of available European assets

– Provide test-bed for innovative

solutions

SST PRECURSOR SERVICES GOAL



PRECURSOR SERVICES

1. Catalogue of man-made objects

2. Collision Avoidance

3. Fragmen-tations

4. Re-entry predictions

5. Mission characterisation

6. Mission Support

7. Small objects

OperatorsOperatorsGeneral

publicGeneral

publicScience

specialistsScience

specialistsState

authoritiesState

authorities

Search and initialisation

Warning bulletins

Attitude motion

Warning bulletins

Orbits and covariances

TIP messages

Debris detections

Internat. ID, classification

Mass, area



Man-euvers

Segment Cervices

Data policy control filters

Expected User Community

Maneuvers

Products



SST PRECURSOR SERVICES SELECTION

• Catalogue of Man-Made Objects

• Core of the SST service

• Provides one additional service directly through the correlation process

• Collision Avoidance

• Drives the precision requirements for the catalogue

• Drives the coverage requirements for the sensor network

• Drives both surveillance and tracking systems

• Re-entry Prediction

• Requires active filtering of the catalogue to produce sub-set of target objects

• Will drive some limiting needs of a tracking system

• Introduces new disciplines into the SST segment

• Fragmentation Detection

• Initiated by correlation process in catalogue maintenance

• Requires rapid tasking, recalculation and prediction to support other services



PAST AND PRESENT ACTIVITIES

Image: Dan Durda – FIAAA



PAST ACTIVITIES

CO-I part I Optical System to complement traditional radar sensors

Catalogue/Collision avoidance requirement driven

NEO component



CURRENT ACTIVITIES

CO-I part II Overall requirements and architecture

Provides definition to the service requirements

CO-V Telescope analysis and design

CO-VI SST Precursor Services Deployment

Install current ESA conjunction prediction tool (CRASS)

Create web-based front-end to CRASS

Develop data model for SST

Characterise current European SST assets



CO-VIII and DC-II LINKAGE



LINK BETWEEN CO-VIII and DC-II



CO-VIII OBJECTIVES



CO-VIII OBJECTIVES

– Create future collision avoidance framework

– Provide re-entry service baseline

– Generate representative data for test and validation

exercises



• Provide core conjunction prediction

• Develop future baseline code for development

• Expand upon earlier capabilities

– Interface with an SQL database (input and output)

– Perform all-on-all conjunction analysis

• Retain single-object/catalogue capability

– Allow parallel processing on large datasets

– Automated input/output

– Interface with current web-based front-end

CONJUNCTION PREDICTION



• New precursor service

• Predict uncontrolled re-entries

• Use SQL database for data source

• Provide multiple outputs:

– Number of candidate objects

– Impact ellipsoid plot

• Automatic input/output

• Interface with web-based front-end

RE-ENTRY PREDICTION



• Real data required to:

– DC-II [test SST process pipeline]

• Track management

• Orbit determination

• Correlation

– CO-VIII [conjunction prediction & re-entry prediction]

• Conjunction algorithms

• Possible filtering techniques

• Re-entry coordination

• Two classes

– Surveillance data

– Tracking data

• Two tasks

– Data planning

– Data execution

TEST AND VALIDATION DATA GENERATION



•WP-1 Conjunction Prediction System

– WP-1.1 Conjunction Prediction System Design

– WP-1.2 Conjunction Prediction System Implementation

– WP-1.3 Conjunction Prediction System Deployment

– WP-1.4 Conjunction Prediction System Maintenance

•WP-2 Re-entry Prediction System

– WP-2.1 Re-entry Prediction System Design

– WP-2.2 Re-entry Prediction System Implementation

– WP-2.3 Re-entry Prediction System Deployment

– WP-2.4 Re-entry Prediction System Maintenance

•WP-3 Test and Validation Data Generation

– WP-3.1 Test and Validation Data Requirements Planning

– WP-3.2 Test and Validation Data Acquisition Management

WORK PACKAGE ORGANISATION



WORK PACKAGES

Function

Work Package

ConjunctionPrediction

Re-entryPrediction

Test and Validation Data Generation

Design 1.1 2.1 3.1Requirements

Planning

Implementation 1.2 2.2 3.2Data Acquisition

Management

Deployment 1.3 2.3

Maintenance 1.4 2.4



WORK PACKAGES

FATIRE

Planning Design 3.1

Re-entry PredictionDesign 2.1

Operational EoC

Planning Implementation 3.2

Re-entry PredictionImplementation 2.2

RePDeployment 2.3

ReP Maintenance 2.4

Conjunction PredictionDesign 1.1

Conjunction PredictionImplementation 1.2

CPDeployment 1.3

CP Maintenance 1.4

Planning Design 3.1

Planning Implementation 3.2Planning

Design 3.1Planning Implementation 3.2Planning

Design 3.1Planning Implementation 3.2



CO-VIII: OPTIONS

• As with DC-II, bidders are asked to provide an offer for the annual

maintenance of the systems for at least three years after the end of

the contract

• The option will not be valid until the end of the contract; ESA unlikely

to take this option until FAT completion (at earliest).



CO-VIII KEY ISSUES: IPR AND SW REUSE

• As with DC-II:

• “SSA needs to own the IPR of all non-COTS software that it will eventually operate. This is needed to allow SSA to license the SW in future contracts (development, maintenance, and operations) and eventually transfer the SSA system to a third party for operations.”

• As a result:

– All software developed will be considered as “operational software” in the contract

– “When offers are based on re-using software where ESA does not already own the IPR, the bidders are expected to transfer to ESA the IPR in the form of a written agreement at no cost or provide - as an option - the cost of transferring the IPR for these systems to ESA for use in SSA.”



CO-VIII KEY ISSUES: IPR AND SW REUSE

• The right to exercise the transfer of IPR options need to be valid for at least 3 years from KO.

• These IPR transfer option costs (if any) will not be considered within the ITT envelope but must be quoted.

• ESA is unlikely to take the IPR options at KO; instead this will be a decision taken later based on the success of the development and the likelihood to use it a basis for the full programme implementation.

• Any IPR offered to ESA shall be subject to “due diligence” procedures from ESA before the transfer can be completed.

• Any IPR transfer to ESA does not exclude the bidder from continuing to use the offered software. ESA will normally grant the bidder a licence.

• In all cases (with or without IPR transfer) the bidder needs to provide a license to ESA for the indefinite continued use of the software. The ESA draft contract attached to the ITT will specify the complete terms and conditions with regard to Operational Software and re-use of existing/third party products.



CO-VIII KEY ISSUES: ESA CFI

• SST Pilot Data Centre site infrastructure (ESAC)

• SST Test and Validation Centre site infrastructure (ESAC)

• SST Pilot Data Centre ICT infrastructure (ESAC)

• SST Test and Validation Centre (ESAC) ICT infrastructure

• Outputs from on-going precursor implementation activities (e.g. CO-

VI) when relevant



CO-VIII KEY ISSUES: NON CFI

• development infrastructure;

• Contractor needs to provide a “representative” environment

• COTS linked to bidders software re-use

• algorithm specifications

• test data

• initial object catalogue



QUESTIONS?

Ariane 5 V198 Launch (Hylas-1 & Intelsat-17) 16th November 2010

→ SPACE SITUATIONAL AWARENESS PRECURSOR PROGRAMME CO-VIII & DC-II Industry Day.

Documents

Transcript of → SPACE SITUATIONAL AWARENESS PRECURSOR PROGRAMME CO-VIII & DC-II Industry Day.