News | 14.11.2019

Q&A for H2020 SPACE-27-TEC-2020


General notice for UK applicants: In conformity with the EU-UK Withdrawal Agreement*, the UK and persons or entities established in the UK continue to be eligible to receive Union funds under actions carried out in direct, indirect or shared management, which implement Union programmes and activities committed under the MFF 2014-2020 until the closure of those Union programmes and activities. When restrictions apply, these will be clearly specified in the call for proposals.

*Agreement on the withdrawal of the United Kingdom of Great Britain and Northern Ireland from the European Union and the European Atomic Energy Community

  • How could Brexit affect the 2020 call if the UK leaves the EU on January 31st? What do the consortiums need to take into account? And can UK companies participate?

UK researchers and innovators will be eligible to collaborate with European partners after Brexit given the majority of H2020 projects are open to third country participation. A “no deal” exit means the government guarantee and extension will ensure the UK’s transition from full to third country membership is handled with as little disruption as possible. The Space Call falls under this bracket. If the UK leaves the EU without a deal the UK Government will support continued UK participation in H2020 when the UK would become a third country. UK participants should be eligible to bid for, participate and lead on H2020 projects open to third country participation with UK participation in H2020 projects to be funded by the UK government via the guarantee and guarantee extension, distributed by UK Research and Innovation (UKRI). The summary of the H2020 guarantee is as follows:

  • Guaranteefunding goes to projects submitted to the Commission whilst the UK was a MS.
  • Extensionfunding goes to projects submitted to the Commission after exit when the UK is a Third Country.”


OG12 & OG13

  • In the Guidance Document for SPACE-27-TEC-2020, what exactly is meant by the text “All deliverables as requested by [AD15-20], with dissemination level CO-1” which appears in the deliverables section on pages 14, 15 &16?

There is an error in the Guidance Document. The correct sentence should read “All deliverables as requested by [AD25-30]”, which means that the deliverables need to be coherent with the applicable documents AD25-30 listed in the Guidance Document in conformity with the European Cooperation for Space Standardization (ECSS).

  • What exactly is meant by showing the transition from short-term to mid/long-term approach in the demonstrator? What percentage of effort ought to be focused on each area?

The purpose of the demonstrator is to provide a baseline for next-generation missions that will feature in the new space eco-system, which will feature open architectures, greater modularity and standardization of technologies. By formulating a demonstrator that combines solutions for short-term market needs (ie servicing of platforms in orbit) that can be extrapolated into solutions for foreseen long-term needs (ie reconfigurable satellites, on-orbit assembly of platforms) we will maximise the output and impact of the project and prepare European competitiveness and advantage for this anticipated eco-system. They should consider adding functional building blocks to their system to increase the aforementioned modularity and flexibility.
As for the percentages required, it’s down to the effort of the consortium to design a mission that will effectively deliver all of the above. There is no prescription on this. What is required is that Europe delivers an IOD in 2025 (tbc) that not only demonstrates effective state-of-the-art capability but significantly explores the potential for application in new markets. The full answer is in the Call Text.

  • In the requirement 4 (R4) it is indicated that the critical technologies shall achieve a TRL of 9, while in the technology maturation section is indicated as TRL 6? What is the TRL needed?

It is not required that the selected technologies be matured to TRL 9 in OG12 and 13. The mission definition to be written by this consortium must define how the subsequent mission itself will develop and mature the technology to TRL 8 (pre-launch) and 9 (post-test). OG12/13 will be required to mature their selected technologies up to TRL 5-6 only.

  • In R10 it is said that the proposed demonstrator shall be completed in 2025. This mean that the launch year is already selected? Could the teams propose more simple demonstrators that could be ready before or more complex ones that will take more time to develop?

The requirement is simply to be used as a scope for designing the mission. The actual mission is still subject to ongoing negotiations The year 2025 is indicative, if the proposals go for a demonstrator that could be ready before or later, need to be properly justified in the proposal, taking into account the expected state of the art for the selected year.

  • In the technology maturation section is said that the technologies selected and TRL level will be fine-tuned during the GAP phase, what this exactly means?

We want to ensure that there is no duplication of effort across the two successful proposals (for example, where similar/identical technologies are selected for maturation), so the distribution of tasks and responsibilities will be allocated across the two projects to ensure complementarity.

  • Is active-debris removal something that could be covered by the demonstrator or is it out of scope?

Active debris removal is certainly not out of scope as it represents an emerging market. However, it is clear that other operators and agencies already have developed effective capabilities in this arena, and that it does not represent an effective springboard for more long-term aspirations, which is the purpose of this demonstrator.

  • Is the budget of M€50-100 already decided? Could the proposal move from this range?

The final budget will be confirmed in the Horizon Europe work programme. M€50-100 is the indicative budget, and the final budget selected need to be perfectly analysed in the proposal and any deviation shall be justified.

  • The system breakdown for OG12 & OG13 proposed in the call (section 3.4) foresees two spacecraft. How mandatory and restrictive is this definition? Would, for instance, an approach with only one spacecraft be sufficient if it would allow the demonstration of all so far untested robotic capabilities and technologies relevant to the intended commercial applications? What would be the criteria for an acceptable reduction of the mission elements without negative impact (or even with positive influence) on the evaluation of the proposal?

Other solutions that fully achieve the objective of the call and the demonstrator specifically can be considered. The proposal would need to justify convincingly why such an approach has been selected and demonstrate that the approach achieves the requested objective.

The ultimate objective of the demonstrator is to provide confidence about the business case approach by the proposer. If the business case implies the existence of two spacecraft configuration then the proposer will have to demonstrate how a single spacecraft configuration in the demonstration mission can provide confidence.

  • How is the access to the SRC building blocks via procurement to be realized in order to guarantee fair competition, as independent as possible from the partners involved in the previous PERASPERA activities? Which channels should be used for enquiries for offers and how is it ensured that pricing is identical for all in order to avoid distortion of competition?

There is no a priori competitive advantage for proposals with partners that have already participated to prior SRC activities (OGs); however proposals will need to demonstrate how the consortium will bring together the necessary expertise and how access to and work with the building blocks products is planned.

Applicants that so wish should contact SRC partners directly, there will be no arbitration of any kind during proposal preparation phase.

During the Grant Agreement Preparation phase after the selection of OG12 and 13, however, the REA with the support of the PSA will look into such aspects to ensure that the Collaboration Agreement conditions are respected and that same conditions apply to all grants.

  • How relevant are the use cases examined in OG7-OG9 if, from a company’s business perspective, others (or slightly different) are more relevant for future commercial applications? What is the basis of evaluation in this respect?

It is important that the applicants submit proposals that are in-line with their long term strategy, as also stated in the Guidance Document and the Work Programme. However, as also mentioned in the Guidance Document “The activity in subject shall consider a range of future mission scenarios, including those addressed by existing OGs, but not to the exclusivity of others.

So, the proposal must contain some of the use cases investigated in OG7-OG9 and can also introduce additional ones.

  • Requirement R17 describes the use of standard interfaces in the Demonstrator. Could the HOTDOCK interface, which is already in use in OG8, 9 and 11, be used as the standard interface in the proposals?

As of now HOTDOCK is not been considered to be a Common Building Block of the SRC despite being used in OG8, 9 &11. The requirements for being a CCB need to fulfil the same conditions for IPR, Open documentation & TRL. Consortia are free to plan and design their proposals incorporating the HOTDOCK interface, but until the above conditions are met the technology cannot be considered to be a CBB.

UPDATE(23/12/2019): HOTDOCK is now considered a Common Building Block of the SRC and can be used in proposals submitted to the 27-TEC call. The relevant documents will be made available on the PERASPERA website together with the applicable documents from the Operational Grants (OGs).


  • What type of robotic collaboration shall be implemented in OG14? Similar to OG11 or a different set of techniques are expected?
    Taking into account the fact these robotic collaborations performances are finalized to implement the ground exploration skills of the robotic system to overcame challenges goals, in the Guidelines are not fixed initial types for the robotic collaboration to make free to develop new and disruptive ideas in this area. To be inspired by the biological systems can be a good and relevant opportunity. The reuse of a significant part of the results and the technologies developed in the previous OGs (specifically OG11) is mandated by the Call, but not exclusively. To increase the value of the successful proposal for OG14, the project could incorporate not only existing SRC technologies (such as those exhibited in OG11) but also other useful technologies required to develop a robotic system that will perform challenging planetological investigations.
  • What is the added value of OG14 over OG10 & OG11, and what additional developments are expected?

The added value of OG14 is the development of the advanced cooperative mobility capability for exploration of hard-to-reach/previously inaccessible areas, such as craters, caves, gullies, lava tubes etc, which has not been investigated thus far in the SRC. The other differentiator is the inclusion of a detailed case study for the terrestrial/commercial application of the technologies being developed in this OG.

  • How will the scientific return and the spin in-out possibilities be evaluated?

The proposals will be evaluated on the strength of their individual justifications for their selections. For example, a proposal that decides to focus on the exploration of caves shall reference existing scientific publications on Martian caves and why they are of scientific interest. Another aspect in their justification has to be the relevance to specific terrestrial applications and the exploitation of the same technology in those applications.

  • The following is stated in pp. 24 and 25 of the Guidance document for SRC-Space robotic technologies: R21-The demonstration scenario must include a minimum of two (preferably three) cooperative Robotic Explorer Units (REUs) and a Remote Monitoring Station.” It is not specified whether the ADRES alone must include the two (or three)  REUs. In other words, can multiple ADRES bring one REU each? Or shall a single ADRES bring the three of them.

As clearly stated at page 24 of the Guidelines:  “ In detail, the demonstrator shall put together:  1. An ADvanced Robotic Explorer System (ADRES) involving multiple Robotic Explorer Units (REU), …”. It means that a REU is a Robotic Explorer Unit and an ADRES System is a system consisting of two or more REUs.

  • Can UAVs be considered as REUs as well  ? (They can operate in Mars, but not in the Moon).

If for UAV you mean an Unmanned Aerial Vehicle, then these can be considered REU also if they can be equipped as autonomous explorer robots, then with the necessary subsystems that make them able to perform autonomously:

  • collection of data,
  • elaboration of data to obtain useful information,
  • make decisions,
  • autonomous movements
  • telecommunication with the ADRES and the other REUs

These are all of the required performances for which they can be defined REU, as indicated in the Guidelines.For a basic and more simple performance, a UAV could be implemented as a REU subsystem.

  • In page 25, it is stated: R8. the demonstration shall allow for a minimum of 3 repetitions of the critical operation (ascending/descending in different relevant environments) “. From the starting points of the document it is understood an ADRES must be able to sort steep slopes and reach a point to release the REUs. One of the REU must have the ability for ascending/descending. The ascending/descending procedure of this REU must be followed by some sort of other actions like coupling among both units (e.g. ADRES release REUs, REUs extract samples, which in turn return to ADRES for analysis)?   

The ADRES has to be able, as system, to perform ascending/descending procedures. It means that a strong slope can’t stop its exploration work but the difficulties of moving on a strong slope can be overcame from opportune actions of the robotic system. It could be realized through coupling among its REUs or through collaborative actions among its REUs, or combinations among coupling and collaborative actions, also in function of the specific terrain difficulties.

  • In page 24, it is stated: 3. A Remote Monitoring Station (RMS) responsible for monitoring the tests, acquiring RWAs’ state telemetry and interfacing with the EST (Environment Simulation Tool) from OG11 heritage.” The previous paragraph suggests OG11 must be included in the implementation constraints. However, in (pp26) at “Implementation Constraints”, only OG1, OG2, OG3 and OG4 are mentioned. Shall we expect it is mandatory to re-use building blocks of OG11 in this call? 

It is strongly suggested to re-use the OG11 heritage for the acquiring RWAs’ state telemetry and interfacing with the EST. It is not mandatory and then not in the Implementation Constraints.