ARTES Competitiveness & Growth Full Proposal. Requirements for the Content of the Technical Proposal

Similar documents
ARTES Competitiveness & Growth Full Proposal. Requirements for the Content of the Technical Proposal. Part 3B Product Development Plan

General Support Technology Programme (GSTP) Period 6 Element 3: Technology Flight Opportunities (TFO)

GALILEO JOINT UNDERTAKING

Satellite Technology for Future Applications

TECHNOLOGY QUALIFICATION MANAGEMENT

Benefits of Standardization in National Space Activities: ASI and the European Cooperation for Space Standardization (ECSS)

Technology qualification management and verification

Typical Project Life Cycle

The Preliminary Risk Analysis Approach: Merging Space and Aeronautics Methods

PLATO Preliminary Requirements Review Technical Report

GENERAL SUPPORT TECHNOLOGY PROGRAMME. ESA Thematic Information Day Belspo, June 2012

DFMC SBAS Receiver Development. Please note that this presentation is also published on the GSA website

SATELLITE NETWORK NOTIFICATION AND COORDINATION REGULATIONS 2007 BR 94/2007

EGS-CC. System Engineering Team. Commonality of Ground Systems. Executive Summary

SPECIAL CONDITIONS OF TENDER

Model Based AOCS Design and Automatic Flight Code Generation: Experience and Future Development

ARTES 33 ESA Telecommunication Public Private Partnership

estec REQUEST FOR INFORMATION Technologies, science payloads, and commercial services for lunar missions ESA UNCLASSIFIED - For Official Use

GUIDELINES FOR STRATEGIC RESEARCH CLUSTER ON IN-SPACE

NEW TECHNOLOGIES. Philippe Francken. WSRF 2012, Dubai 1

BROAD AGENCY ANNOUNCEMENT FY12 TECHNOLOGY DEMONSTRATION MISSIONS PROGRAM OFFICE OF THE CHIEF TECHNOLOGIST PROPOSALS DUE.

Italian Space Agency perspective on Small Satellites

GeneSat-1 Quick Look Mission Report

The ESA SME Initiative

SPACE. DG GROW Internal Market, Industry Entrepreneurship and SMEs GROW/I1 - Space Policy and Research Unit

GALILEO Research and Development Activities. Second Call. Area 3. Statement of Work

Electronic Communications Committee (ECC) within the European Conference of Postal and Telecommunications Administrations (CEPT)

REQUEST FOR PROPOSAL For Color Orthogonal & Color Oblique Imagery

TECHNOLOGY WITH A HUMAN TOUCH

The ARTES Technologies and Products programme and the Megaconstellations opportunity

ASSEMBLY 37TH SESSION

Review of Technology Level 3 achievement and Level 3 and 4 unit standards. Graphics Design Graphic Communication

SCOE SIMULATION. Pascal CONRATH (1), Christian ABEL (1)

(Non-legislative acts) DECISIONS

Incentive Guidelines. Aid for Research and Development Projects (Tax Credit)

Guidance on design of work programmes for minerals prospecting, exploration and mining permits

learning progression diagrams

Aerospace Software* Cost and Timescale Reduction *and complex electronic hardware

Technology Transfer: An Integrated Culture-Friendly Approach

Understand that technology has different levels of maturity and that lower maturity levels come with higher risks.

1. Introduction. defining and producing new materials with advanced properties, or optimizing industrial processes.

National Grid s commitments when undertaking works in the UK. Our stakeholder, community and amenity policy

ESPA Satellite Dispenser

Method for CubeSat Thermal-Vacuum testing specification

GALILEO Research and Development Activities. Second Call. Area 1A. Statement of Work

Robotics in Horizon 2020 IMPACT and Technology Readiness Levels

Model Based Systems Engineering (MBSE) Business Case Considerations An Enabler of Risk Reduction

EU Support for SME Innovation: The SME Instrument

NASA Cost Symposium Multivariable Instrument Cost Model-TRL (MICM-TRL)

High Performance Engineering

Space Debris Mitigation Status of China s Launch Vehicle

(R) Aerospace First Article Inspection Requirement FOREWORD

GAMMa - A modular ascender concept for sample return missions

Using COTs components to Reduce Space Mission Costs: Facts, Myths, Advantages & Pitfalls

Human Spaceflight Programmes and Possible Greek Participation

Technology and Manufacturing Readiness Levels [Draft]

Strategic Research Cluster on Electric Propulsion H2020 Space call text 2016 & related Guidelines document

EUROPEAN GNSS APPLICATIONS IN H2020

Announcement of Opportunity for the JUICE Payload

Fault Management Architectures and the Challenges of Providing Software Assurance

GUIDELINE DOCUMENT FOR FUNDING APPLICATION

High Voltage Instrumentation Cables for the ITER Superconducting Magnet Systems

ESA Technology Programmes: Spanish Participation in TRP and GSTP

ASSESSMENT OF THE USE OF C-BAND FOR GNSS AO 5410, closing 30/05/2007

EXPERIENCE OF PARTICIPATION IN INTERNATIONAL SCIENTIFIC AND EDUCATIONAL SPACE PROJECTS BY THE EXAMPLE OF QB50 PROJECT

Annex B: HEO Satellite Mission

TECHNICAL AND OPERATIONAL NOTE ON CHANGE MANAGEMENT OF GAMBLING TECHNICAL SYSTEMS AND APPROVAL OF THE SUBSTANTIAL CHANGES TO CRITICAL COMPONENTS.

SMR Conference Manchester 2014 Regulator s view UK and International. Bob Jennings Systems Lead for ONR s Generic Design Assessment (GDA)

LOGICAL FRAMEWORK MATRIX LFM

System Architecture Module Exploration Systems Engineering, version 1.0

A Methodology for Effective Reuse of Design Simulators in Operational Contexts: Lessons Learned in European Space Programmes

EUROPEAN SPACE AGENCY INDUSTRIAL POLICY COMMITTEE GENERAL SUPPORT TECHNOLOGY PROGRAMME GSTP-5 ELEMENT-2 INITIAL WORK PLAN

7 Briefing. Responsible investor

Attitude Determination and Control Specifications

Floating Power Plant A/S POSEIDON project

D/SCI/DJS/SV/val/21851 Paris, 5 March 2007 CALL FOR PROPOSALS FOR THE FIRST PLANNING CYCLE OF COSMIC VISION

SURREY GSA CATALOG. Surrey Satellite Technology US LLC 8310 South Valley Highway, 3rd Floor, Englewood, CO

GANOMIC. Disruptive technologies for PPU cost & volume efficiency

Cover. DLR-ESA Workshop on ARTES-11. SGEO: Implementation of of Artes-11. Dr. Andreas Winkler

Mid Term Exam SES 405 Exploration Systems Engineering 3 March Your Name

Office of Technology Development (OTD) Gap Fund

CONCURRENT EVALUATION - AN APPLICATION FOR DLR S CONCURRENT ENGINEERING FACILITY SECESA OCTOBER 2010

Manufacturing Readiness Level Deskbook

GUIDELINES FOR THE APPLICATION FOR A SPACE STATION CARRIER LICENCE. Section 1 - Introduction

Independent Communications Authority of South Africa Pinmill Farm, 164 Katherine Street, Sandton Private Bag X10002, Sandton, 2146

NZQA registered unit standard version 4 Page 1 of 5. Plan, construct, modify, and report on an electronic prototype

Estates Development & Projects

From concept to launch of remote sensing satellites

TYPE APPROVAL PROCEDURE

GALILEO Research and Development Activities. Second Call. Area 1B. Interference Detection Mitigation and Isolation.

Navigating the Healthcare Innovation Cycle

Jerome Tzau TARDEC System Engineering Group. UNCLASSIFIED: Distribution Statement A. Approved for public release. 14 th Annual NDIA SE Conf Oct 2011

GENERAL DESCRIPTION OF THE CMC SERVICES

Report ITU-R SM.2181 (09/2010)

Aboriginal Consultation and Environmental Assessment Handout CEAA November 2014

Electronic Communications Committee (ECC) within the European Conference of Postal and Telecommunications Administrations (CEPT)

Software-Intensive Systems Producibility

NATIONAL GEOSPATIAL-INTELLIGENCE AGENCY 11.2 Small Business Innovation Research (SBIR) Proposal Submission Instructions

SWOT PROJECT STATUS T. LAFON. SDT Toulouse 7 JULY SWOT Status

FAA Research and Development Efforts in SHM

Transcription:

ARTES Competitiveness & Growth Full Proposal Requirements for the Content of the Technical Proposal Part 3C (DDVP) Statement of Applicability and Proposal Submission Requirements Applicable Domain(s) Space Ground System Application Yes 1 Yes 1 Yes 1 Yes 1 Applicable Development Phase(s) Definition Technology Product Demonstration Yes 1 Yes 1 Yes 1 Yes 1 1 The table of contents identifies additional requirements specific to Domains and Development Phases. Proposal Submission Requirements A separate and self-contained Part 3C of the Technical Proposal shall be included for each Development Phase for which support is being requested under the ARTES C&G Call for Proposals. Notes on the Content of this Document This style is used for explanatory notes and guidance to help you to develop the Full Proposal content. 1 This numbered style in bold font identifies the main sections to be completed in this Part of the Proposal. 1.2 This numbered style identifies requirements for the Full Proposal content for each of the main sections of this Part of the Proposal. Page 1 of 12

Contents 1 General Requirements... 3 2 Objective of the Proposed Development Phase... 3 3 Models/Prototypes to be Developed within the Proposed Development Phase... 4 4 Risk Mitigation Activities within the Proposed Development Phase... 4 5 Qualification, Certification and Type Approval Activities within the Proposed Development Phase... 4 6 Verification Activities within the Proposed Development Phase... 4 7 Work to be Performed in the Proposed Development Phase... 5 8 Specific Requirements for the Definition Phase (All Domains)... 5 9 Specific Requirements for the Technology Phase (All Domains)... 6 10 Specific Requirements for the Space Segment Product Phase... 7 11 Specific Requirements for the Ground Segment and System Product Phases... 8 12 Specific Requirements for the Application Product Phase... 8 13 Specific Requirements for the Space Segment Demonstration Phase... 9 14 Specific Requirements for the Ground Segment and System Demonstration Phases... 11 15 Specific Requirements for the Application Demonstration Phase... 12 Page 2 of 12

1 General Requirements The DDVP defines the plan to develop the product from its current state of development (Readiness Level) to the end of the planned Development Phase and shall result in achieving the required outputs of the 1.1 The Tenderer shall provide an independent detailed (DDVP) for each of the proposed Development Phases. This Part of the Proposal zooms in from the high or top level presented in Product Development Plan presented in response to Part 3B for a specific Developments Phase included in the Tenderer s Proposal. The ECSS DRDs may be used as a reference for the content and layout of the elements of the DDV Plan (e.g. ECSS-E-ST-10-02C Annex A). The phase DDVP shall only answer the applicable set of requirements corresponding to the proposed Development Phase it describes (excluding requirements from other Development Phases). 1.2 The Tenderer shall identify the specific Development Phase to which the detailed development logic applies. 1.3 Stand-alone documents referenced as supporting information in the DDVP element of the Proposal shall be delivered to the Agency as part of the Proposal documentation package. The use of stand-alone documents is encouraged. These documents should be referenced in the Development Plan and attached (not copied) to the Proposal. 2 Objective of the Proposed Development Phase This section of the Proposal establishes the top-level objectives of the work to be performed. The details of how these objectives shall be achieved are then detailed in the section responding to the requirements relating to the work to be performed in the proposed 2.1 The Tenderer shall establish the objectives of the proposed Development Phase, including the key outputs and achievements. 2.2 The Tenderer shall indicate the target (ending) readiness level (RL) of the product, and of its major subsystems and key enabling technologies, to be achieved at the end of the proposed Development Phase. Readiness Levels for Space Segment, Ground Segment, System and Application Domains are defined in Appendix 1, Part 3B of the Technical Proposal. 2.3 The Tenderer shall confirm that the outputs of the planned Development Phase shall include an updated Business Plan reflecting the maturity of the development. For example, at the end of the Definition Phase the Business Plan should be sufficiently mature to initiate the next proposed development phase (e.g. Technology Phase). Details of the Business Plan content requirements are provided in Part 2 of this call for proposals. 2.4 The Tenderer shall confirm that the outputs of the planned Development Phase shall include updated plans to organise, direct and conduct the remaining development work in the following Development Phase, defining: i) schedule, ii) cost, iii) reviews, iv) deliverables. Page 3 of 12

3 Models/Prototypes to be Developed within the Proposed Development Phase 3.1 The Tenderer shall identify the Model(s) to be developed in the proposed The models to be developed should include any iterations of a given model that the Tenderer proposes to undertake within the 3.2 The Tenderer shall identify the characteristics/functionality of product to be verified by the each of the models in the proposed 4 Risk Mitigation Activities within the Proposed Development Phase 4.1 The Tenderer shall identify any risk mitigation activities to be undertaken within the proposed 5 Qualification, Certification and Type Approval Activities within the Proposed Development Phase Qualification refers to demonstrating that the product is capable of operating in the specified environment. For the Ground Segment, the term validation is often used in place of qualification. Certification refers to meeting the safety or regulatory requirements (e.g. CE marking). Type approval refers to a demonstration, by test to the extent practicable, that a product meets the technical requirements for its use within a given satellite system, with a certification that all units of the same product type will meet the requirements in a similar manner. 5.1 The Tenderer shall define the qualification, certification or type approval activities that shall be carried out within the proposed Development Phase (as applicable). 5.2 The Tenderer shall identify the model(s) to be used to achieve qualification/certification/type approval within the proposed 5.3 The Tenderer shall identify the standard(s)/procedure(s) that shall be used to achieve qualification, certification or type approval during the proposed Development Phase, for each of the models to be used for this purpose. 6 Verification Activities within the Proposed Development Phase Reference may be made to a separate test plan document (or set of documents), a copy of which should be attached to the Proposal. 6.1 The Tenderer shall identify and describe the verification activities to be performed in the proposed 6.2 The Tenderer shall give an overview of: i) The tests to be performed; ii) The model on which the tests will be performed; iii) The test environment. This information may be presented in the form of a test matrix. 6.3 The Tenderer shall identify and define the various analyses and simulations foreseen within the proposed Development Phase (if relevant). 6.4 The Tenderer shall identify the simulation tools to be utilised (if relevant). Page 4 of 12

7 Work to be Performed in the Proposed Development Phase This section provides a narrative description of the work to be performed in the activity. A detailed breakdown should be provided in the work package descriptions. 7.1 The Tenderer shall define the development approach to be undertaken within the proposed This section zooms in from the high or top level presented in the previous section. The development approach defines the plan to develop the product from its current state of development (Readiness Level) to the end of the planned Development Phase and shall result in achieving the required outputs of the 7.2 The development logic for the proposed Development Phase shall achieve the specific objectives of that Phase. 7.3 The Tenderer shall identify the key enabling technologies that will be developed during the proposed 7.4 The Work Description shall identify the item(s) (e.g. technology, technique, system, performance, environment etc.) to be assessed or developed within the proposed 7.5 The Tenderer shall identify the adopted manufacturing approach and associated resources required (if relevant). 8 Specific Requirements for the Definition Phase (All Domains) The requirements stated in this section only apply for a Definition Phase. Requirements Related to the Objective of the Definition Phase 8.1 The Tenderer shall confirm that the objectives of the Definition Phase include: i) Generation of a complete set of Product Requirements. ii) Completion of an initial design concept that will allow development work to continue. iii) Generation of supporting analyses that are sufficient to demonstrate the technical and economic feasibility of the product. Requirements Related to the Work to be Performed in the Definition Phase 8.2 For Application activities, the Tenderer shall include in the Proposal an initial version of the System and Service Architecture Document. The content of the document is set out in the document content definition section in Part 5C of the Management Proposal. Page 5 of 12

9 Specific Requirements for the Technology Phase (All Domains) The requirements stated in this section only apply for a Technology Phase. Requirements Related to the Objectives of the Technology Phase 9.1 The Tenderer shall confirm that the work to be undertaken in the Technology Phase does not include any of the following: - Materials qualification activities; - Component qualification activities; - Process qualification activities; - Qualification activities on the equipment; - Industrialisation of the product. All qualification or industrialisation activities should be carried out as part of a Product Phase. 9.2 The Tenderer shall confirm that the output of the Technology Phase shall include Breadboard(s), Prototype(s) or EM(s) of the product. The Hardware/Software developed under the Technology Phase shall be identified in the definition of the Model to be developed within the current Development Phase (see requirement 3.1). 9.3 The Tenderer shall confirm that, upon completion of the Technology Phase, all the hardware (Breadboard(s), Prototype(s) or EM(s)) and software developed during the Technology Phase shall have been subjected to an appropriate test campaign to demonstrate the functionality and/or performance of the product. Requirements Related to the Work to be Performed in the Technology Phase 9.4 For Application Segment activities, the Tenderer shall include in the Proposal an initial version of the System and Service Architecture Document. The content of the document is set out in the document content definition section in Part 5C of the Management Proposal. Requirements Related to Risk Mitigation Activities within the Technology Phase 9.5 The Tenderer shall identify the specific technology risks to be retired during the Technology Phase. Requirements Related to Verification Activities within the Technology Phase 9.6 The Tenderer shall define, for each of the items to be developed in the Technology Phase, the criteria that provide the necessary confidence to proceed with the development (e.g. success criteria). 9.7 The Tenderer shall identify the test/verification method(s) to be used during the Technology Phase to demonstrate that each technology risk has been retired. Page 6 of 12

10 Specific Requirements for the Space Segment Product Phase The requirements stated in this section only apply for a Space Segment Product Phase. The objective of the Product Phase is to have completed the development of the product such that the product is ready for commercial exploitation. The Product Phase activities shall conform to the following principles: a. For the development of a product to be used on a spacecraft, the Product Phase shall be related to the qualification and to non-recurring development activities preparing for its commercial production. b. Product Phase shall include a test program suitable for validating the final product. c. The result of the Product Phase shall be a product ready for commercial exploitation. Requirements Related to Objective of the Space Segment Product Phase 10.1 The Tenderer shall confirm that at the end of the Product Phase, the Tenderer shall have completed (as applicable and/or included in the activity): i) All qualification testing of the product for flight on the specified spacecraft and launch vehicles, i.e. TRL 7 shall have been reached. ii) All non-recurring development activities to prepare for the commercial production of the product. iii) All materials qualifications required for the product. iv) All parts qualifications required for the product. v) All process qualifications required for the product. vi) The industrialisation of the product. vii) The development of the product test system. 10.2 The Tenderer shall indicate in its Proposal which of these objectives are applicable. Requirements Related to Qualification Activities Qualification is the demonstration that an item is capable of operating in its specified operational environment with adequate margins. The decision to use a developed product for an operational mission or flight demonstration rests with its customer and is dependent upon the outcome of a separate qualification and suitability review. Thus, completion of any qualification activity in the contract does not ensure that the item will be accepted for use in a specific operational programme. Specific requirements for reviews to be held for each Development Phase are given in Part 5C of the Requirements for the Content of the Management Proposal. 10.3 The Tenderer shall define any component qualifications that will be performed in the proposed 10.4 The Tenderer shall define any material qualifications that will be performed in the proposed 10.5 The Tenderer shall define any process qualifications that will be performed in the proposed Requirements for the Work to be Performed in the Product Phase 10.6 The Tenderer shall detail any development activities required to prepare the product for commercial production (if applicable). For example, development of automated test software. Page 7 of 12

10.7 The Tenderer shall detail any product industrialisation activities to be undertaken in the Product Phase (if applicable). 11 Specific Requirements for the Ground Segment and System Product Phases The requirements stated in this section only apply for a Ground Segment and/or a System Product Phase. The objective of the Product Phase is to have completed the development of the product to the extent that it is ready for commercial exploitation. The Product Phase activities shall conform to the following principles: a. For the development of a product to be used in the Ground Segment or a System, the Product Phase shall be related to verification and industrialisation of the product (i.e. readiness for commercial production). b. The Product Phase shall include a test program suitable for verifying the final product. c. The result of the Product Phase shall be a product ready for commercial exploitation. Requirements Related to the Objective of the Product Phase 11.1 For Ground Segment and System activities the objectives of the Product Phase shall include: i) Verification of the product in a representative, non-operational environment. ii) Completion of the product design and industrialisation, ready for commercial exploitation. iii) Completion of the verification of the product performance, via a suitable test program. This verification shall confirm that the performance of the product is adequate for the target market. iv) Industrialisation of the product, or product test system (if applicable). 11.2 The Tenderer shall indicate whether or not requirement 12.1 iv) is applicable. Requirements for the Work to be Performed in the Product Phase 11.3 The Tenderer shall detail any development activities required to prepare the product for commercial production (if applicable). For example, development of automated test software. 11.4 The Tenderer shall detail any product industrialisation activities to be undertaken in the Product Phase (if applicable). 12 Specific Requirements for the Application Product Phase The requirements stated in this section only apply for an Application Product Phase. Requirements Related to the Objective of the Product Phase 12.1 The objective of the Product Phase shall be to complete the verification of the product performance via a suitable test program. This verification shall confirm that the application/service is ready for entering into a validation stage with operational users. Requirements for the Work to be Performed in the Product Phase 12.2 If the Proposal includes software, the Tenderer shall detail any development activities required to prepare the product for commercialisation. E.g.: preparation of user manuals, getting started materials, and the transformation of the software into a self-installing package. For example, preparation of installation files. Page 8 of 12

12.3 The Tenderer shall include an initial version of the System and Service Architecture Document. The content of the document is set out in the document content definition section in Part 5C of the Requirement for the Content of the Management Proposal. 13 Specific Requirements for the Space Segment Demonstration Phase The requirements stated in this section only apply for a Space Segment Demonstration Phase (Atlas). Requirements Related to the Objective of the Demonstration Phase 13.1 The objective of the Demonstration Phase within the Space Segment shall be to: - Demonstrate the product in its operational environment i.e. TRL 9 shall have been reached, or - Support the launch of in-orbit flight hardware to be used in a system, service or application product, or - Support the launch of in-orbit flight hardware to be used in demonstrators to verify the functioning of the technology in a system context. 13.2 The outputs of the Demonstration Phase shall include: i) Measurement of the on-ground performance of the product. This shall include: - Unit Acceptance Testing; - Performance of the unit during Spacecraft Acceptance Testing. ii) Measurement of the in-orbit performance of the product. This data shall be compared to the data collected during ground testing. iii) Measurement of the in-orbit performance during the first year after the completion of in-orbit testing. This data shall be compared to the data collected during ground testing and that collected during In-Orbit-Testing. Flight Configuration Information The Flight Configuration information defines the specific information required for a Space Segment Demonstration Phase ( Atlas ) activity. 13.3 The Tenderer shall identify by name all products to be developed and flown as part of the Demonstration Phase. 13.4 The Tenderer shall explicitly state whether its request for support is an embedded case or a passenger case. The difference between an embedded and a passenger case are detailed in the cover letter of this Call for Proposals. 13.5 For each of the identified products, the Tenderer shall state whether or not the first flight unit is fully representative of the recurrent flight product. 13.6 For each of the identified products, if the first flight unit is not fully representative of the recurrent flight product, the Tenderer shall: - describe the differences with respect to the recurrent product; - justify why a fully representative example of the recurrent product is not proposed to be flown. Page 9 of 12

13.7 For each of the identified products, the Tenderer shall provide a description of the flight configuration, including: - the total number of units of the product to be flown, including additional units of the same type for which the Agency is not providing support; - The number of units that are proposed to be developed and flown with Atlas support; - how these units are embedded into the main mission; - How the unit(s) will be used in the context of the payload/platform architecture (e.g. redundant unit within a redundancy ring, with the rest of the hardware being standard hardware). 13.8 The Tenderer shall describe the intended operational use of the product, in the proposed flight opportunity, i.e. whether these products will be part of the nominal operation or used in a redundant mode only, and whether there is an equivalent conventional item(s) installed as a redundant unit. Examples of operational use are: - the primary functional element with no other backup; - a redundant element to a primary functional element; - the primary functional element, backed up by a redundant element. 13.9 For each of the identified products, the Tenderer shall include information on the nature of the innovation that justifies the need for Atlas support for this particular product (first flight heritage of a new product or product variant). For example, the Tenderer has never manufactured this type of equipment before and hence has no heritage for the product. 13.10 The Tenderer shall, for all cases where more than one unit of the same product is proposed to be flown and supported under Atlas, explain why it is necessary to fly more than one unit: - what function(s) would not be adequately demonstrated by flying only one unit, and - how would these function(s) be adequately demonstrated by flying the proposed number of units. Atlas support is provided for the minimum number of flight units of the same product that is necessary to obtain first flight heritage for that product. 13.11 The development plan shall specifically identify any accommodation studies to be performed (if applicable). 13.12 The development plan shall specifically identify any activities associated with the accommodation of the flight item, including assembly, integration and test at spacecraft level (if applicable). 13.13 The nature of any work to be carried out by the spacecraft manufacturer shall be identified by the Tenderer. For example, accommodation studies, design modifications performed to accommodate the innovative item, hardware specifically required for accommodation purposes and satellite-level assembly, integration and test (AIT), specific activities related to the innovative product during the AIT and launch campaigns. Flight Configuration Passenger Case The requirements stated in this subsection shall only apply if the Proposal is for a Passenger case within the Space Segment Demonstration Phase (Atlas). 13.14 For passenger cases, the Tenderer shall state the operator of the main Mission. Page 10 of 12

13.15 For Passenger cases, the Tenderer shall identify the name of and objective of the main mission of the spacecraft. Please note that the main mission does not have to be a telecommunications mission. 13.16 For Passenger cases, the Tenderer shall identify the launch vehicle (if it is known). 13.17 For Passenger cases, the development plan shall specifically identify activities associated with the launch campaign (testing and early operation phase activities specific to the item, for verification of function and performance, or monitoring). Note: these activities can only be supported for the Passenger case. 13.18 For Passenger cases, the development plan shall specifically identify activities associated with the IOT and verification of the performance and function of the product. Note: these activities can only be supported for the Passenger case. 14 Specific Requirements for the Ground Segment and System Demonstration Phases The requirements stated in this section only apply for a Ground Segment and/or System Demonstration Phase. Requirements Related to the Objective of the Demonstration Development Phase 14.1 The objective of the Demonstration Phase shall be a product validated in its operational environment. 14.2 The output of the Demonstration Phase for the Ground Segment or System Domain shall be the performance of the product as measured in an operational environment. This data shall demonstrate that the product is fully validated in all its technical and operational elements, and is ready to be offered to a well-identified customer(s). Pilot Configuration Information The Pilot Configuration information defines the specific information required for a Ground Segment and/or System Demonstration Phase activity. 14.3 For each of the identified products, the Tenderer shall confirm that the product under validation is fully representative of the recurrent product. 14.4 The Tenderer shall confirm that the pilot configuration is of a scale sufficient to demonstrate the commercial attractiveness of the product. 14.5 For each of the identified products, the Tenderer shall provide a description of the operational configuration, including: - the total number of units of the product to be validated, including additional units of the same type for which the Agency is not providing support; - how these units are embedded into the Ground Segment architecture; - how the unit(s) will be used in the context of the end-to-end system. 14.6 The Tenderer shall describe the intended operational use of the product in the proposed pilot phase. 14.7 The Tenderer shall include in the Proposal an initial version of the Pilot Utilisation Plan (PilUP). The content of the document is set out in the document content definition section in Part 5C of the Requirement for the Content of the Management Proposal. Page 11 of 12

15 Specific Requirements for the Application Demonstration Phase The requirements stated in this section only apply for an Application Demonstration Phase. Requirements Related to the Objective of the Demonstration Development Phase 15.1 The Objective of the Demonstration Phase shall be an application/service validated with relevant users and customers and ready for a commercial rollout. 15.2 The output of the Demonstration Phase for the Application shall be a service fully defined and validated in all its technical and operational elements, and ready to be offered by a well-identified service provider, under clear contractual and commercial conditions. Requirements Related to the Work to be Performed in the Demonstration Phase. 15.3 The Tenderer shall include in the Proposal an initial version of the System and Service Architecture Document. The content of the document is set out in the document content definition section in Part 5C of the Management Proposal. Pilot Configuration Information 15.4 The Tenderer shall include in the Proposal an initial version of the Pilot Utilisation Plan (PilUP). The content of the document is set out in the document content definition section in Part 5C of the Management Proposal. Page 12 of 12