HERCULES: High-Performance Real-time …hercules2020.eu/wp-content/uploads/2016/04/D6.2_Final...HERCULES final exploitation strategy is based on two main pillars: • Exploitation

HERCULES: High-Performance Real-time Architectures for Low-Power Embedded Systems

Project title: High-Performance Real-time Architectures for Low-Power Embedded Systems

Acronym: HERCULES

Project ID: 688860

Call identifier: H2020 - ICT 04-2015 - Customised and low power computing

Project Coordinator: Prof. Marko Bertogna, University of Modena and Reggio Emilia

D6.2: Final Exploitation Plan

Document title: Final Exploitation Plan

Version: 1.2

Deliverable No.: 6.2

Lead task benefi-ciary

PIT

Partners Involved: All

Author: Roberto Mati, all partners

Status: DRAFT

Date: 30/12/2018

Nature1: R – Report

Dissemination level

PU Public X

PP Restricted to other programme participants (including the Commission Services – CS & IAB)

RE Restricted to a group specified by the consortium (including the IAB)

CO Confidential to consortium (including CS & IAB)

1 For deliverables: R = Report; P = Prototype; D = Demonstrator; S = Software/Simulator; O = Other For milestones: O = Operational; D = Demonstrator; S = Software/Simulator; ES = Executive Summary; P = Prototype

Page 2

This Project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement: 688860

Document history:

Version Date Author Comments

0.1 2018-11-22 PIT Initial version

0.2 2018-12-10 PIT Initial contributions from partners

1.0 2018-12-17 PIT Integrated contributions from all partners

1.1 2018-12-25 PIT Integrated review comments

1.2 2018-12-30 UNIMORE Final revision

This document reflects only the author's view and the EU Commission is not responsible for any use that may be made of the information it contains.

Page 3


Table of contents

Document history:............................................................................................................................................. 2

Table of contents .............................................................................................................................................. 3

GLOSSARY ........................................................................................................................................................ 5

1. Executive summary ................................................................................................................................ 6

2. Purpose ................................................................................................................................................... 8

3. Exploitation definition methodology ..................................................................................................... 9

4. Variation during the project ................................................................................................................. 10

5. Overview of the partners and their involvement in HERCULES ....................................................... 11

6. HERCULES Exploitable results ........................................................................................................... 14

6.1. HERCULES Integrated Framework ......................................................................................16

6.2. Automotive Use Case ............................................................................................................19

6.3. Avionic Use Case ..................................................................................................................21

6.4. Individual Exploitation ..........................................................................................................23

6.4.1 Exploitation results: Co-scheduling algorithms, Jailhouse colouring, Jailhouse

Memguarding. ..............................................................................................................................23

6.4.2 Exploitation result: KCF Open source Tracker ..............................................................26

6.4.3 Exploitation result: Compiler modules, Runtime library, FPGA IP for low-cost remapping of virtual addresses ................................................................................................................................28

6.4.4 Exploitation result: Hypervisor, Erika Enterprise, RTE, Power management for SCHED_DEADLINE ..........................................................................................................................30

6.4.5 Exploitation result: Aerial Drone applications .....................................................................32

6.4.6 Exploitation result: Electronics module for central ADAS/AD domain controller .................34

6.5. Summary ................................................................................................................................35

6.6. TRL and HERCULES exploitable results .............................................................................37

6.6.1 TRL for exploitation results .................................................................................................37

7. Management of IPR ............................................................................................................................... 38

7.1. Definitions ..............................................................................................................................38

7.2. Background............................................................................................................................38

7.3. Results ...................................................................................................................................39

8. Interaction with the IAB ........................................................................................................................ 42

8.1. Collaboration with IAB members .........................................................................................43

9. Exploitation with other stakeholders .................................................................................................. 45

Page 4


9.1. Bylogix and Autonomous Driving ........................................................................................45

9.1.1 Company introduction ........................................................................................................45

9.1.2 Domain of interest ..............................................................................................................45

9.1.3 Why HERCULES is an added value for you and your customers.......................................45

9.1.4 Results ...............................................................................................................................46

9.1.5 Which are HERCULES exploitation results more interesting for you? ................................48

9.2. Lifetouch and Last Mile Delivery ..........................................................................................48

9.2.1 Company introduction ........................................................................................................48

9.2.2 Domain of interest ..............................................................................................................48

9.2.3 Why HERCULES is an added value for you and your customers.......................................49

9.2.4 Results ...............................................................................................................................49

9.2.5 Which are HERCULES exploitation results more interesting for you? ................................49

10. Conclusion ............................................................................................................................................ 50

Annex 1: TRL methodology ............................................................................................................................ 51

Executive summary ..............................................................................................................................51

Purpose 51

Overview methodology.........................................................................................................................52

Introduction ........................................................................................................................................52

The TRL scale in Horizon2020 ..........................................................................................................54

TRL adaptations to other organisations .............................................................................................57

TRA for software activities .................................................................................................................59

TRL questionnaire ................................................................................................................................64

TRL Conclusion ....................................................................................................................................66

Page 5


GLOSSARY

Item Description

ADAS Advanced Driver Assistance System

AI Artificial Intelligence

CPS Cyber Physical System

COTS Commercial Off-The-Shelf

DP Deep Learning

ECU Electronic Control Unit

EU European Union

GNC Guidance, Navigation, and Control

HIL Hardware In the Loop

IAB Industrial Advisory Board

IPR Intellectual Property Rights

ISF Integrated Software Framework

M12 Month 12 of the project

M36 Month 36 of the project

ML Machine Learning

OS Operating System

PREM PRedictable Execution Model

RTE Run-Time Environment

RTOS Real Time Operating System

SoC System on Chip

TRA Technology Readiness Assessment

TRL Technology Readiness Level

UX User Experience

Page 6


1. Executive summary

Deliverable D6.2 contains the final plan for the exploitation results of the HERCULES project. It collects and describes the exploitable outcomes that have been identified during the whole duration of the project, includ-ing:

• List of identified results;

• Leading partner for each result;

• Background and Foreground IP of each Partner applied to each one of the results;

• Protection form for each result. The market analysis and exploitation plans for the Integrated Framework, the two Use Cases of the project, and the specific exploitation plans by all partners are presented separately. A preliminary exploitation plan was provided at Month12 and described in deliverable D6.1 Preliminary exploi-tation plan. D6.1 was restricted to the Consortium and IAB members. Deliverable D6.2 is and updated version of outcomes and plans identified during the project and it is released for public access. The marketable results of HERCULES project described in D6.2 address the main expected impacts described in the proposal. 1. Reinforce and broaden Europe's strong position in low-power computing in traditional and new market segments by strengthening the technology competences of European suppliers and the academic community. The technology developed within HERCULES has never been previously adopted by any company in its in-dustrial settings. As an addition, by setting up the first complete framework for automotive, avionics and indus-trial automation system based on heterogeneous embedded many-core platforms, HERCULES represents the first full-fledged baseline platform to exercise state-of-the-art academic findings in these domains. Moreover, the industrial partners (MM and AGI) participating to the consortium are among the main world players in their specific domains, and they are further strengthening their position thanks to this strategic cooperation.

2. Reduction of energy consumption of servers by 2 orders of magnitude as compared to state of the art in 2013. Results showed that the impact of memory contention to energy consumption may be significant (see deliver-able D2.2). Also, porting the industrial use case applications to the target embedded platforms allows a tre-mendous improvement in the power consumption, provided the predictability problems of these intertwined architectures are solved thanks to the HERCULES framework. Despite HERCULES technological baseline doesn't target server-based systems, the methodologies, tools and technology developed within the project may be potentially adopted also in that specific domain.

3. Double the productivity in efficiently programming and maintaining advanced computing systems

The adoption of OpenMP as a programming interface enables quick code refactoring and porting on power-efficient many-cores. This has a tremendous impact on programmers' productivity. Also, the consortium has worked to hide all the complex scheduling mechanisms behind this simple programming level, providing com-piler support, execution models, co-scheduler, and related schedulability analysis tools that are transparent to the programmer, provided the code complies with some requirements that are typical for real-time applica-tions.

4. Powering cyber-physical systems as compared to state of the art in programming embedded systems in 2013. The next-generation of cyber-physical (CPS) systems is increasingly adopting power-efficient, high-performance platforms such as the ones targeted in HERCULES. Being the approach of the project purely at

Page 7


the software level, it can be easily integrated in a CPS platform, provided some key building blocks be properly ported. 5. Increase the adoption of form-factor data-centres and heterogeneous highly parallel computing systems. HERCULES framework may be potentially adopted within data centre settings.

6. Higher involvement of SMEs, both on the supply and the demand-side. Both SMEs involved in the consortium will achieve tremendous benefits by the project. EVI is strengthening its position as one of the main providers of RTOS for embedded and multi-core systems; PIT is enriching its port-folio of advanced autopilots for robots. As an addition, EVI has developed an AUTOSAR Run-Time Environ-ment (RTE) generator for ERIKA Enterprise, that was not originally planned, to properly support MM’s automo-tive use case, further strengthening the cooperation between consortium partners. Moreover, two more SMEs have been included in the project, namely Bylogix and Lifetouch, that proved to gain potential advantage by deploying the HERCULES framework within their respective scenarios. Bylogix is an engineering company that customizes intelligent vehicles, whereas Lifetouch is designing a novel robot for last mile logistics.

7. Increased adoption of concurrency in applications across all sectors; higher degree of parallelism in appli-cations; increased public trust in embedded applications due to secure and reliable architectures. The HERCULES project assesses the applicability of multi- and many-core embedded accelerators in safety-critical settings, i.e., certified ISO26262 for automotive, DO-178C for avionics, IEC61508 for industrial sys-tems. By doing so, HERCULES improves the trust that industry has in such platforms as applicable to systems with high predictability and reliability requirements. HERCULES also promotes the adoption of parallel archi-tectures and parallel programming models in the next generation of industrial embedded systems. The final plan, with the overall decisions taken, are described within this document.

Page 8


2. Purpose

The Final Exploitation Plan described in this document provides the details and a clear overview of which re-sults HERCULES provides to the academic and industrial domains, and to promote and foster strategic and sustainable innovation throughout EU countries. The exploitation plan has been modified from the preliminary version described in Deliverable D6.1, and the full plan is be presented in the following chapters. HERCULES project has introduced predictability into embedded high-performance computing, where previous-ly only average performance was important. The predictability level HERCULES has delivered has paved the road for novel safety-critical applications, with reduced power budget and cost, without sacrificing performanc-es. The specific objectives of the Final Exploitation Plan are:

• To assess current exploitation activities, both at joint and individual level, trying to forecast future mar-kets and technological achievements

• To pave the way to market penetration of the HERCULES exploitable results

• To stimulate the Consortium to focus on market opportunities beyond pure research activities.

• To identify, track and solve potential issues in Intellectual Property Rights (IPR) among the partners

• To provide a market-oriented point-of-view to all partners and foster the creation of start-ups, spin-offs and joint partnerships to maximize the impact of the project, with particular relation to the EU market.

Page 9


3. Exploitation definition methodology

HERCULES final exploitation strategy is based on two main pillars:

• Exploitation Activities, to define how each partner has planned to generate benefits by the project results, both for the Integrated Framework, Use Cases, and individual exploitation activities;

• IPR Management, to address the ownership of the IPR, and the management of the access rights to such IPR by the project partners.

Specific commercial and process benefits achievable by the HERCULES project results at the level of the Final Exploitation Plan are regulated by:

• The definition of the marketable results and of the individual exploitation strategy;

• The definition of the access rights of the partners to the project background and foreground for the internal usage

• The management of IPR generated in the project; this is mainly the definition on how to treat the fore-ground generated in the project.

Deliverable D6.2 does contain such information about exploitable results and protection strategies.

Page 10


4. Variation during the project

During the project development some variations in the exploitable results have been applied. The Avionic Use Case was considered strong enough to get access to EU funding but lacking in the integra-tion of HERCULES core technologies from an operational point-of-view. As a consequence, the Consortium asked the partner PIT to switch its activities from Automotive to Avionic use case, and to augment the Avionic use case with an aerial drone system, complementing the activities in place in the Avionic Use Case to show the performance of the HERCULES framework, similar to what was already defined for the Automotive use case. The Avionic use case was then subdivided into two branches, one focusing on computer vision for visual object tracking, and one focusing on computer vision for Guidance, Navigation and Control (GNC). The relations between both branches is that branch2 complements branch1 with corresponding open source components, i.e. the open source Tracker customized by partner CTU, and the potential to demonstrate the application with a drone demonstrator. The first branch (of a pure machine-learning based visual object tracker) places high SIMD-based computa-tional requirements on the embedded hardware platform to achieve high tracking performance (in terms of tracking robustness), while the second branch places higher focus on the integration of various system as-pects necessary to realize the coupled functions of vision based GNC. More information about the Avionic Use Case application can be founded in deliverable D1.3 Integrated appli-cations.

Page 11


5. Overview of the partners and their involvement in HERCULES

All the partners involved in the HERCULES project have specific interests in exploiting the project results. In the following table an overview of respective interests is provided. Data are extracted from an exploitation questionnaire that was designed and sent to the Consortium preliminarily in October 2016, and finally updated and confirmed in December 2018. The answers are related to two questions that were posed to understand partners’ interests in HERCULES:

1. What is the main reason why your organization is in the HERCULES project; 2. Summarize the strategy of your organization in the field of Real-Time, Multicore Heterogeneous plat-

forms.

Partner Reason & Strategy

UNIMORE 1. The High-Performance Real-Time Lab (HiPeRT Lab) of the University of Modena aimed at creating a reference point in the research on real-time multi- and many-core systems, providing scheduling algorithms and schedulability tests for next-generation hardware architectures. With the HERCULES project, it aimed at bridging the gap be-tween performance and predictability using next-generation embedded platforms based on heterogeneous multi-core systems

2. The group intends to strengthen the collaborations with leading industrial excellences in the Emilia-Romagna area, promoting the framework as a solution to cope with the complexity of heterogeneous hardware platforms, providing a simple and integrated method to achieve higher performances in a predictable way. To this end, the group has exploited the many existing connections and collaborations with middle-to-big-size companies based in Italy, mainly from the automotive, avionics and industrial au-tomation domain. Some of these companies have been involved in the IAB of the pro-ject to allow an easy dissemination of the technological solutions developed, provid-ing a chance to get companies involved in the project since its early stages.

CTU 1. Our group has a long tradition in working in the area of real-time and embedded sys-tems, and it is known for that by our industrial partners. These partners are interested in learning our know-how, which we typically generate by working on research pro-jects.

2. It is clear that the topic of the HERCULES project is of interest by our industrial part-ners and our participation in HERCULES led to more collaboration with industry, such as Skoda Auto, Porsche and Honeywell. In addition to that, the topics of the HERCU-LES project are also hot research topics, which have allowed us to publish more sci-entific journal and conference papers: Parallel Computing (Elsevier), IEEE Transac-tions on Vehicular Technology, Programming Models and Applications for multi-core and many-core workshop.

ETHZ 1. The group has a strong background in heterogeneous many-core systems architec-ture and programming. The HERCULES project has allowed us to strengthen our ex-pertise in the field of real-time computing, to complement our main background, to match the challenging requirements of current industrial settings (automotive, avion-ics).

2. As an academic institution, one of the main goals of our group is that of acquiring the described skills within industrial settings with real-life use cases, for their exploitation in higher education and in the production of scientific publications. The group also

Page 12


has a relevant record of activities in technology transfer, where we have been able to exploit the outcomes of the HERCULES project. This encompasses the possible di-rect reuse of IPs developed for the project as well as consulting activities.

EVI 1. We see a strategic need about how to take advantage of future multi-core architec-tures, coming from current Evidence’s customers in both the automotive and the in-dustrial domains. The HERCULES project has provided Evidence technical skills as well as the opportunity to build a software eco-system (composed of ERIKA Enter-prise v3, Linux, and Jailhouse hypervisor) for deploying multi-core solutions for next generation automotive customers, as well as to strengthen the collaborations with companies and research centers across Europe.

2. Evidence needed to create a set of standard products for the automotive and indus-trial markets that will make efficient usage of current and future multi-/many-core ar-chitectures. As part of this strategy, we saw and implemented the following two points: a. Create an AUTOSAR-compliant RTOS for the automotive market (in this case

ERIKA v3, plus a Run Time Environment middleware) b. Create innovative solutions for running multiple operating systems on the same

chip (“Multi-OS”), composed of Linux, an open-source hypervisor like Jail-house, and ERIKA Enterprise.

PIT 1. The HERCULES project allowed us to investigate the potential of novel technologies for real-time multi core embedded systems, specifically for real-time safety-critical systems.

2. The core business of Pitom is the development of Autopilots and Perception systems for aerial, ground and marine unmanned vehicles. As no pilot is usually in control of the unmanned vehicle, autopilot and perception systems constitute a safety-critical system, that must respond in real-time to external inputs. For perception systems to be hosted by small vehicles, energy-efficient yet computationally powerful boards are required. The augmentation of Avionic use case, and the support provided to the Consortium in testing single components and the overall HERCULES Framework, has brought into our team a strategic know-how and experience on programming real time critical systems.

AGI 1. Investigation of the HERCULES platform as a potential COTS-based real-time archi-tecture for applicable avionic use-cases and demonstrators.

2. The fast progress in the algorithmic fields of artificial intelligence makes it necessary

to rethink existing development processes for future services and products that might be impacted by this progress. New strategies are required to speed up evaluation and development processes that incorporate computational demanding concepts from ar-tificial intelligence and machine learning. Especially in earlier development phases (up to demonstrator levels), the utilization of COTS-based real-time architectures for evaluation and demonstration of new concepts and capabilities are preferable w.r.t computational power, development time and architecture costs. While demonstrators generally place lower certification requirements on real-time architectures, the predict-ability w.r.t real-time requirements - as targeted by HERCULES - must not be com-promised for many relevant avionic use-cases.

MM 1. Technical opportunity to collaborate with skilled specialized partners on innovative HW-SW real time innovative embedded platforms for next 2020 automotive data fu-sion ECU generation.

Page 13


2. Starting from European projects like HERCULES, our target has been to prepare a

roadmap of library products for electronics block components and SW modules that will allow designing new evolution applications for the automotive market (ADAS, Au-tonomous driving, Automotive Hybrid/BEV Domain architecture, etc.) in the time-frame 2020-2025.

Page 14


6. HERCULES Exploitable results

This chapter collects and describes the exploitable results identified in the project. Specifically, the final exploitation outcomes are subdivided into three main categories:

1. The Integrated Framework, that is exploited in the industrial domain; 2. The two Use Cases, namely the Automotive Use Case and Avionic Use Case; 3. The Individual Exploitation Activities.

The following figure shows the overall exploitation outcomes of HERCULES, both at industrial and open-source level.

Figure 1. Industrial and open-source outcomes of HERCULES

Hardware

ERIKA RTOS

Linux kernel

Automotive app

PR

EM C

om

pile

r

RTE

Jailhouse Hypervisor

Middleware (libpremnotify, GPUGuard)

CPU GPU

Co-scheduling Memguard Coloring Nvidia TX2

SCHED_DEADLINE

Avionic app

Tracker

Released as open-source by HERCULES.

Page 15


The final list of exploitable results is presented in the following table.

Exploitable results Leading partner

HERCULES Integrated Framework UNIMORE

Automotive Use Case: Valet Parking MM

Avionic Use Case: Real-Time Tracking AGI

Avionic Uses Case: Aerial Drone applications PIT

PREM compiler ETHZ

KCF Tracker CTU

Runtime library (libpremnotify,GPUGuard) ETHZ

Run-Time Environment (RTE) EVI

Jailhouse co-scheduling algorithms UNIMORE, CTU

Jailhouse colouring UNIMORE

Jailhouse Memguarding CTU , UNIMORE

Jailhouse for NVIDIA TX1/TX2 EVI

ERIKA RTOS for ARM Cortex-A on Jailhouse EVI

FPGA IP for low-cost remapping of virtual ad-

dresses ETHZ

Power management for SCHED_DEADLINE EVI

HW electronics module for central ADAS/AD domain controller

MM

Page 16


6.1. HERCULES Integrated Framework

Figure 2. HERCULES ISF holistic view

Exploitation Leader: University of Modena and Reggio Emilia (UNIMORE)

What is the product/service/result to be exploited for the Integrated Framework? For industrial applications, like those where computers replace human activities, real-time and multicore plat-forms are necessary to guarantee a prompt elaboration of a wide number of data coming from multiple sen-sors. Even with a limited number of cores, predictability has been a difficult requirement to guarantee in the Real-Time community, due to the conflicting accesses to shared hardware and software resources by multiple concurrent tasks. The main target of HERCULES project has been to build an Integrated Software Framework (also called in the following HERCULES ISF) for ensuring predictability at minimal performance loss on top of COTS heteroge-neous platforms. It consists of an integrated toolchain composed of multiple modules, including: compiler-level extensions to produce predictable (PREM-ized) code; enhanced RTOS/OS support for multi-core SoCs; hy-pervisor layer to enable timing and spatial separation among different OS components; a set of co-scheduling routines implemented at RTOS/HV level to predictably arbitrate the access to shared computing and memory resources; efficient and predictable host-to-device communication support and runtime. All modules have been seamlessly integrated into a homogeneous framework and demonstrated on top of the hardware platform Nvidia Tegra Parker. The HERCULES ISF is released as a software framework with TRL5. We have planned not to sell HERCULES ISF as a standalone product, anyway each module is mature enough to lend itself for a further commercializa-tion phase, if additional work and resources are made available. Industrial activities, also carried out by the SME partners as well as by spin-off companies that are being created by a subset of HERCULES partners, are foreseen to push the TRL to higher values.

What kind of exploitation form does your organization intend for?

Page 17


☒ Direct industrial use ☒ Technology transfer ☒ License agreement ☒ Publications ☐ Standards ☐ Other

What kind of domain market is your result addressing?

☒ Avionics ☒ Automotive ☒ ICT-Energy Efficiency ☒ New Parallel Programming Libraries ☒ Other

In case of ‘Other’, please describe it: Industrial automation

What are you achieving in HERCULES with respect to current similar products, with reference to your result? The added values of HERCULES ISF architecture with respect the state of the art mainly are: 1. Integrate in a common platform AUTOSAR, Linux/POSIX and GPU API and programming platforms; 2. Increase predictability while maintaining the performance on heterogeneous multi-core SoCs; 3. Provide a multi-OS framework that aims for the ISO 26262 qualification.

Who are the target customers and end-users of your result? The main target customers of the whole HERCULES ISF are silicon provider producing multicore platforms (e.g. Nvidia, Xilinx) who need to integrate predictability within their own products, and industrial companies that need to produce next-generation products with tight requirements in predictability and energy consumption. Even before the end of the project, partner UNIMORE was able to establish multiple contracts with leading platform providers exposing some of the HERCULES components (namely, predictability assessment, memory interference characterization, cache colouring, GPU scheduling). There is indeed a strong interest by these companies on the overall integrated framework. The companies particularly appreciated the modularity of the approach, which also allows selectively using some of the components (e.g., compiler, memguard, colouring, etc.) according to the related applications of interest. Now that the overall HERCULES framework is ready, UNIMORE and the other partners will be consolidating it and present it to the above-mentioned platform pro-viders, as well as to important Tier-1’s in the automotive and avionic domain. See the Individual Exploitation section to identify a list of potential companies that the consortium already targeted. Specific exploitation activities to deliver consultancy on HERCULES ISF (custom development, integration, remote support, training etc.) will be settled in the future by the main OS contributors, i.e. UNIMORE, EVI, ETHZ, and CTU. Each partner will have the right of selling services/products based on the HERCULES ISF, sharing revenues in case of not open-source software developed by other partners (specific agreements based on what described for Joint Foreground IPR will be eventually prepared). Another specific exploitation activity that was investigated during the project and exploiting the HERCULES ISF was started by UNIMORE and PIT, and called Drivebox. DriveBox is meant to be an aftermarket kit to enhance a car with self-driving capabilities, increasing driving safety and comfort. Unfortunately, the Consorti-um encountered some issues to make the overall HERCULES ISF work properly before starting up the new company, and the potential creation of a Drivebox product has been shifted after the end of the project. In order to test the viability of the HERCULES ISF during its development, UNIMORE decided to co-organize the F1/10 competition2, an international event where teams coming from many countries challenge themselves to win an autonomous race with 1/10 scaled cars. After the first event, UNIMORE has taken the lead of the European part of the Race, with the University of Pennsylvania (USA).

2 F1/10 Autonomous Racing Competition official website: http://f1tenth.org/

Page 18


Two competitions have been organized in Europe: 1. During the Cyber-Physical Systems Week conference3, in Porto, Portugal, April 2018 2. During the Embedded Systems Week conference4, in Turin, Italy, October 2018 The F1/10 Race has been further introduced to the Maker Faire of Rome, Italy, in October 2018

What is the benefit that your result will provide to customers/end users? With the release of HERCULES ISF, we provide a multicore heterogeneous architecture that will make pro-grammers capable of writing complex tasks in a simple way. A combined solution composed by hardware and OS that allows a programmer to conveniently design safety-critical applications characterized by a huge com-putational demand, concurrent behaviour, limited energy budget and strict real-time requirements.

3 https://cister.isep.ipp.pt/cpsweek2018/p1/?F110 4 https://esweek.org/event-details?id=262--107-

Page 19


6.2. Automotive Use Case

Figure 3: Automotive Use Case Scenario Example

Exploitation Leader: Magneti Marelli (MM)

What is the product/service/result to be exploited for the Use Case? Automatic Valet Parking is one of the most interesting use cases in the automotive autonomous driving do-main, and it is likely to be one of the first to be really implemented in production. The drivers usually perceive parking manoeuvres involved as boring, so that they are more willing to accept an automation of this task. Valet Parking has been chosen for testing HERCULES platform for three main reasons: 1. Automated Valet Parking has a subset of functionalities required to a self-driving vehicle, and testing all of

them is affordable in a controlled scenario within the timeframe of HERCULES project; 2. MM has simulators and testing environments in Turin to create the scenario; 3. All the agents are driving at a low speed, with clear safety advantages. The application is sufficiently robust to consider not-completely-structured settings, moving beyond conserva-tive scenarios where Valet Parking is solely managed by the infrastructure and other agents (vehicles, people, etc.) are prevented to enter the area. While these additional functionalities increase the computational burden to be processed by the embedded platform, they allow the application to be more robust to unforeseen agents entering the parking area, increasing the safety integrity level of the application. Valet Parking (i.e. the Automotive Use Case) will likely be an application directly managed by the OEMs, and not fully exploited by MM. By the way, MM is exploiting some specific software enabling technology. It is possible to consider four main algorithms areas that will run on the HERCULES platform: the perception area (sensor data processing), the data fusion area (perceived object fused with a-priori information to create an environment model), the decision area (decision, action planning, path planning, vehicle control) and the localization area (GPS, INS and MAP data management).

Page 20


Based on such a division, MM would like to try to exploit mainly the data fusion and the decision area by ena-bling OEMs to create applications using the following SW enablers (algorithms): 1. Probabilistic Data Fusion Framework; 2. Path Planner.


☒ Direct industrial use ☒ Technology transfer ☐ License agreement ☐ Publications ☐ Standards ☐ Other


☐ Avionics ☒ Automotive ☐ ICT-Energy Efficiency ☐ New Parallel Programming Libraries ☐ Other

What are you achieving in HERCULES with respect to current similar products, with reference to your result? Increase performance and reliability vs. power consumption vs. cost, keeping flexibility for software modules integration aligned to state-of-the-art in 2020.

Who are the target customers and end-users of your result? Some of the most important OEMs in European and American markets.

What is the benefit that your result will provide to customers/end users? Ready-to-use algorithms for valet parking and self-driving navigation.

Who are your competitors and how is your product different from theirs? Main European Tier1 and smart sensors developer

Page 21


6.3. Avionic Use Case

Figure 4: Avionic on-board camera systems to provide situation- and context-awareness

Exploitation Leader: Airbus Group Innovations (AGI)

What is the product/service/result to be exploited for the Use Case? Future airplanes will be required to better understand their environment. Image processing and computer vi-sion, for instance, will be largely used during landing, in surveillance activities, or for navigation purposes. Many airplanes already contain a significant number of cameras to provide situation- and context-awareness on the ground or in the air, and the number of cameras is expected to significantly increase over the next years. Besides the possibility to directly make the video streams of these cameras available to pilots or the crew during airplane operations, higher levels of automation can be achieved by making use of computer vi-sion technologies that automatically extract meaningful information from these video streams. Within the field of image processing and computer vision, there is a huge industrial interest in machine learn-ing technologies. Machine learning technologies have proven to significantly advance the capabilities of many computer vision tasks – but come at the price of higher algorithmic complexity and computational require-ments. A visual object tacking application was selected by AGI to test and stress the promises of the HERCULES platform, especially with respect to programming models and predictability on GPU-based hardware platforms. The visual object tracking application is based on an Airbus proprietary high-speed machine learning technol-ogy called FD-SVM that enables online-learning during the tracking process. This application represents a typical machine learning application from the field of computer vision that is well suited for evaluation of the HERCULES platform. Within the Avionic Use Case, exploitation is foreseen for high performance computer vision and machine learning capabilities onboard of commercial (civil) drones based on COTS real-time architectures. Since the purpose of AGI was to stress the GPU and to evaluate the HERCULES platform, AGI cannot promise that the application will directly become a product in the future – but the general demand in robust visual tracking, or similar technologies, has opened up many opportunities, especially in the field of commercial civil drones. As a first technology transfer, a first software version of the visual object tracking application using the HERCULES programming model has already been transferred from AGI to an Airbus business division for further explora-tion.

Page 22



☐ Direct industrial use ☒ Technology transfer ☐ License agreement ☐ Publications ☐ Standards ☐ Other

Transfer of HERCULES technology from Airbus Group Innovations (cooperate research) into Airbus Group divisions to develop products/services.


☒ Avionics ☐ Automotive ☐ ICT-Energy Efficiency ☐ New Parallel Programming Libraries ☐ Other

What are you achieving in HERCULES with respect to current similar products, with reference to your result? The increase of accessible on-board computing performance for next-generation demonstrators with real-time guaranties and simplified programming models to speed up the time from code to hardware.

Who are the target customers and end-users of your result? Airbus business divisions

What is the benefit that your result will provide to customers/end users? Reduction of development costs and time related to transferring new algorithmic technologies (e.g. machine learning, artificial intelligence) to on-board real-time architectures. Increase the applicability of such algorithmic technologies to on-board scenarios by providing higher compute performance and predictability.

Page 23


6.4. Individual Exploitation

6.4.1 Exploitation results: Co-scheduling algorithms, Jailhouse colouring, Jailhouse Memguarding.

Exploitation Leader: UNIMORE

What is the product/service/result to be exploited for your organization? 1. A set of co-scheduling algorithms that enables a more efficient and predictable use of computing and com-munication/memory resources on heterogeneous multi-core platforms. Two branches of algorithms/techniques have been introduced depending on the addressed application: one for PREM-izable code that can be com-piled into separate memory and computation regions; one for legacy applications whose memory access pat-terns cannot be rearranged. 2. Cache coloring extension to the Jailhouse hypervisor. Cache colouring is a technique for avoiding data evic-tion on the cache. It works by handling virtual memory virtual memory so that pages with different "colors" have different positions in cache. 3. Predictable memory hierarchy extension to the Jailhouse hypervisor. It consists of the PREM co-scheduling algorithm plus the MemGuard mechanism, both implemented in the Jailhouse hypervisor. Co-scheduling algorithms and Jailhouse Memguarding have been jointly developed with CTU, while the cache coloring has been developed by UNIMORE only.


☐ Direct industrial use ☒ Technology transfer ☒ License agreement ☒ Publications ☐ Standards ☐ Other


☒ Avionics ☒ Automotive ☒ ICT-Energy Efficiency ☐ New Parallel Programming Libraries ☐ Other

What are you achieving in HERCULES with respect to current similar products, with reference to your result? Most of the existing results are either limited to a theoretical level, ignoring many of the practical difficulties stemming from implementation and runtime overhead experienced in real settings, or they are not tailored for real-time applications. Pre-fetching execution models have been brought forward in the High-Performance Computing domain to speed up performances, but their adaptation to concurrent and periodic real-time set-tings is not directly applicable. We will instead propose a set of algorithms that are designed taking into ac-count the real-time requirements and the memory/computation footprint of each concurrent task, optimizing the usage of shared resources available in the considered platform. To our knowledge, only a few works have been proposed in the literature by two academic groups (University of Waterloo, Canada and UIUC, Illinois) that are in close contact with UNIMORE. Most of the related products are still at a very early prototyping/study phase.

Who are the target customers and end-users of your result?

Page 24


OS/RTOS providers; SoCs provider (e.g., Nvidia, Xilinx), as well as OEM and Tier 1 interested in optimizing their application on a targeted multi-core system. Specifically, UNIMORE has started a collaboration with NVIDIA and Xilinx to provide consultancy activities in the HERCULES domain. The list of individual industrial exploitation activities already in place is as follows. Egicon srl Profiling of Real-Time Systems Executing upon an Embedded Multi-core Platform. Overall budget: 36.600€ (entirely funded by the company). 2/08/2016 – 31/08/2017 Nvidia Corporation 1. GPU Real-Time Computing and Scheduling. Overall budget: 114.198$ (entirely funded by the company). 20/03/2017 – 19/09/2017 2. Real-time scheduling of GPU resources and recommendations for architectural enhancements. Overall budget: 128.290$ (entirely funded by the company). 05/02/2018 – 04/08/2018 SACMI Imola S.C. Heterogeneous Multi-core Platforms for Real-Time Applications. Overall budget: 48.800€ (entirely funded by the company). 01/02/2017 – 31/01/2018 Borsch Gmbh 1. funding of a 3-years PhD scholarship on Real-Time Multi-core Systems for Automotive Applications. 1/10/2017 – 30/09/2020 2. Code Generation Tool for Heterogeneous Hardware Platforms based on Amalthea. Overall budget: 40.000€ + VAT (entirely funded by the company). 1/7/2018 – 31/12/2018 TetraPak Packaging Solutions S.pA. 1. Real-time analysis and assessment of multi-core platforms for industrial motion and control. Overall budget: 25.000€ + VAT (entirely funded by the company). 17/10/2017 – 16/04/2018 2. Real-time analysis and assessment of multi-core platforms for industrial motion and control (extension). Overall budget: 30.000€ + VAT (entirely funded by the company). 16/04/2018 – 31/3/2019 Xilinx Inc. Implementation of a hypervisor-based cache coloring mechanism for industrial real-time applications. Overall budget: 25.292€ + VAT (entirely funded by the company). 08/01/2018 – 30/06/2018 Generali S.p.A. study of insurance policies for autonomous driving. 1/2/2018 – 31/1/2019 United Technologies Research Center (UTRC) Predictable hypervisor and multi-OS support for heterogeneous hardware platforms. Overall budget: 12.500$ + VAT (entirely funded by the company). 11/9/2018 – 31/12/2018 Ferrari S.p.A. co-funding of a research fellowship on next-generation ADAS applications. Overall budget: 28.000€ (9.000 funded by Ferrari, 19.000€ by the Emilia Romagna region through POR-FSE 2014-2020 project Automotive Academy. 1/2/2019 – 31/1/2020

Page 25


What is the benefit that your result will provide to customers/end users? The main benefit will be a more predictable and efficient utilization of hardware resources in a multi-core sys-tem. The obtained improvement significantly depends on the specific application domain and the constraints imposed by the legacy system.

Page 26


6.4.2 Exploitation result: KCF Open source Tracker

Exploitation Leader: Czech Technical University in Prague (CTU)

What is the product/service/result to be exploited for your organization? Knowledge of technical details of selected platforms and hands-on experience. Knowledge about certain algo-rithms used for autonomous driving and how to make execution of these algorithms more predictable on the selected or similar platforms. An open source tracker has been optimized for the target host NVIDIA TX2, in order to be integrated on the Avionic Use Case. Specifically, co-scheduling algorithms and Jailhouse Memguarding have been developed through close col-laboration with UNIMORE.


☐ Direct industrial use ☒ Technology transfer ☒ License agreement ☒ Publications ☐ Standards ☐ Other


☒ Avionics ☒ Automotive ☐ ICT-Energy Efficiency ☐ New Parallel Programming Libraries ☒ Other

In case of ‘Other’, please describe it: Military, Industrial automation

Who are the target customers and end-users of your result? Mostly companies, that we are already in contact with. In the automotive area, these are mainly: Skoda Auto, Porsche Engineering, Valeo. In the other areas they are, for example, Honeywell, ERA and Eaton. Skoda Auto, a.s. 1. Technologies and infrastructure for autonomous driving. Overall budget: 19.200 EUR, 2017. 2. Training and development for future ADAS-ready multi-core ICAS ECUs and related software layers. Overall budget 20.000 EUR, 2018. Porsche Engineering 1. Cone slalom with Porsche Panamera. Overall budget: 44.000 EUR, 2018. Honeywell: 1. H2020/CleanSky project THERMAC was accepted. The project will continue with development of some parts of the HERCULES stack (hypervisor, time-triggered scheduling).

What is the benefit that your result will provide to customers/end users? Predictable execution of algorithms on high-performance COTS hardware will make it easier to certify final products for safety-critical applications. This will lead to huge cost savings.

Who are your competitors and how is your product different from theirs?

Page 27


Other universities and research institutions. Our “product” differs from most of the competitors that we are able to provide holistic understanding of computing platforms, which includes detailed knowledge of underlying hardware, operating systems/hypervisors as well as user space libraries and applications.

Page 28


6.4.3 Exploitation result: Compiler modules, Runtime library, FPGA IP for low-cost remapping of virtual addresses

Exploitation Leader: Swiss Federal Institute of Technology in Zurich (ETHZ)

What is the product/service/result to be exploited for your organization? The planned technical work in the HERCULES project led to the development of three main IPs: 1. Compiler modules (based on the LLVM/Clang infrastructure) for the refactoring of heterogeneous applica-

tions (written in C/C++ with OpenMP annotations for GPU offloading) into PREM-compliant code, where PREM stands for the PRedictable Execution Model;

2. Runtime library that supports the dynamic execution of PREM-compliant codes, comprising the PREM library libpremnotify (Portable library for memory scheduling for the compiler, versions for Jailhouse (CPU) and GPUguard (GPU), and the GPUguard kernel module (the GPU support for the compiler);

3. an FPGA IP for low-cost remapping of virtual addresses in a heterogeneous system. Besides the IPs themselves, we see great value in the expertise to be acquired from the project’s activities and from the collaboration with leading automotive/avionics industries and to be reinvested in consulting activities.


☐ Direct industrial use ☒ Technology transfer ☐ License agreement ☒ Publications ☐ Standards ☐ Other


☐ Avionics ☐ Automotive ☒ ICT-Energy Efficiency ☒ New Parallel Programming Libraries ☐ Other

What are you achieving in HERCULES with respect to current similar products, with reference to your result? From a research perspective, the developed methodologies, techniques and tools, coupled to the possibility of validating them on realistic industrial settings, will allow us to improve significantly the state-of-the-art solutions and results. The same holds for the acquired knowledge and expertise, considering the opportunities for consulting activi-ties. This will allow us to broaden our services to also target automotive companies (or in general those with a focus on real-time computing), which we previously did not. Furthermore, discussions on the reuse of ETHZ HERCULES technologies have been discussed with Siemens.

Who are the target customers and end-users of your result? National/International companies with a demand for computing solutions capable of delivering high-performance, energy-efficiency and real-time requirements.

What is the benefit that your result will provide to customers/end users? Please provide some numerical data

Page 29


Real-time requirements are traditionally dealt with by relying on computing solutions that simplify the hardware design in favor of an increased timing predictability. The best example of such a restriction is probably the adoption of single-core architectures with simplified memory hierarchies. The price to be paid for increased predictability is thus to sacrifice performance/energy efficiency, as the cur-rent solutions adopted in the general-purpose computing domain to achieve the latter are all relying on mas-sively parallel accelerator architectures. The key benefit of our results consists of techniques to provide timing guarantees on top of commercial off-the shelf (COTS) heterogeneous architectures based on many-core accelerators. In our experiments we show that we can achieve a reduction in sensitivity to interference of 10x for GPU programs, and 2.6x for CPU programs. For details, please see Deliverable 3.3.

Who are your competitors and how is your product different from theirs? Currently there is no PREM compiler available on the market.

List the main strengths of HERCULES specifically referred to your organization core business 1. It provides relevant use cases, with real-life industrial settings. 2. It enables frequent and timely interactions with top industries owning the use cases. 3. The technical partners in the consortium have complementary expertise that addresses all the layers of

the complex HW/SW infrastructure on top of which the proposed solution is to be developed.

Page 30


6.4.4 Exploitation result: Hypervisor, Erika Enterprise, RTE, Power management for SCHED_DEADLINE

Exploitation Leader: Evidence Srl (EVI)

What is the product/service/result to be exploited for your organization? 1. The Multi-OS stack (i.e. hypervisor for concurrent execution of Linux and ERIKA Enterprise), to be directly exploited in the automotive market and potentially on other markets such as industrial automation. 2. The new version of the ERIKA Enterprise RTOS (“ERIKA v3”) for selected MCUs (including ARM Cortex-R5 and Cortex-A5x). 3. The AUTOSAR stack (consisting of ERIKA Enterprise and the RTE) for direct exploitation in the automotive market.


☒ Direct industrial use ☐ Technology transfer ☐ License agreement ☐ Publications ☐ Standards ☐ Other


☐ Avionics ☒ Automotive ☐ ICT-Energy Efficiency ☐ New Parallel Programming Libraries ☒ Other

In case of ‘Other’, please describe it: Industrial automation

What are you achieving in HERCULES with respect to current similar products, with reference to your result? Other companies in the market sell similar products under expensive royalty-based licenses. HERCULES will allow EVI to create a competitive product, potentially with a higher number of features, which will be desirable for the embedded market due to a commercial license not based on royalties. Moreover, the proposed solution will incorporate top state of the art solution for efficiently managing multi-cores.

Who are the target customers and end-users of your result? Manufacturers operating in the automotive (e.g. Magneti Marelli), telecom (e.g. Huawei) and industrial automa-tion (e.g. IMA) markets. Chip manufacturers looking for innovative solutions for their own customers (e.g., NVIDIA, Xilinx, Infineon, NXP).

What is the benefit that your result will provide to customers/end users? Cost reduction due to the possibility of running automotive-certified software and general-purpose software on the same chip under controlled mechanisms.

Page 31


In the industrial domain, the possibility to efficiently use multi-cores (currently companies often use only single core for predictability reasons). The cost savings of such a solution depends on the customer and on the num-ber of items produced. On the automotive market, the cost savings can be measured in terms of limited need to use proprietary solu-tions from other reference vendors. In the industrial market, it is mainly due to the integration of different em-bedded PCs in the same machine, which means reduced amount of software licenses and hardware.

Who are your competitors and how is your product different from theirs? Vector sells products (i.e. RTOS, tools) based on the AUTOSAR standard. However, its solution does not cur-rently support Multi-OS configurations. Windriver sells products based on the VxWorks RTOS. However, its solution lacks flexibility.

List the main strengths of HERCULES specifically referred to your organization core business 1. Collaboration with important actors like Magneti Marelli (partner in HERCULES and Evidence’s customer),

NVIDIA and Xilinx. 2. Possibility to create a reference platform for multicores including ERIKA v3 and hypervisors. 3. Possibility to create a first version of an ERIKA v3 RTE for the automotive market. 4. Possibility to analyze and strengthen the knowledge on most innovative multi-core heterogeneous hard-

ware platforms.

Page 32


6.4.5 Exploitation result: Aerial Drone applications

Exploitation Leader: PITOM (PIT)

What is the product/service/result to be exploited for your organization? The technological effort on the HERCULES project led to the development of an Autonomous Aerial Drone System, with vision-based object tracking. The Aerial Drone System is composed of the drone itself, and more strategically the complete Autopilot solution running on a Jetson NVIDIA TX2 platform, along with the vision-based system. The suite is completed by a Graphic User Interface to easily monitor and control the overall aerial mission. The attractivity of the novel application is that, for the first time, the vision-based tracker acts on the GPU in a predictable way, with the potential to lead (even if it is not directly dealt by HERCULES) to future certification activities, whereas the Autopilot runs upon a RTOS. More generally, we will try to bring the exper-tise collected during HERCULES on real-time embedded heterogeneous systems into other fields of autono-mous robots. Besides the technical activities, we see great value in the expertise that will be acquired by leading the Exploi-tation activities and the interaction with the Industrial Advisory Board members.


☒ Direct industrial use ☐ Technology transfer ☐ License agreement ☐ Publications ☐ Standards ☐ Other


☒ Avionics ☒ Automotive ☐ ICT-Energy Efficiency ☐ New Parallel Programming Libraries ☒ Other

In case of ‘Other’, please describe it: Industrial automation, Precision Agriculture

What are you achieving in HERCULES with respect to current similar products, with reference to your result? With the HERCULES results and the acquired expertise PIT will start the design of more safety-critical vision-based perception systems and autopilots for robotic applications. Mobile robots are expected to have better safety-critical guarantees and need for lower energy budgets when compared to similar products on the mar-ket.

Who are the target customers and end-users of your result? Potential customers are national and international companies (e.g. Yanmar, CS Group, Stiga, Virtualabs) deal-ing with autopilots and perception systems for robotic applications. Energy-efficient real-time Autopilot systems can be used in markets like Automotive, Precision Agriculture, Aerial Drones.

What is the benefit that your result will provide to customers/end users? Many tracking systems heavily rely today on vision-based algorithms. Those algorithms are very data-crunching and need a huge computational power to be processed. Moreover, autopilots need to sense the

Page 33


environment in order for a drone to move safely in the environment. In these scenarios, real-time safety critical systems are needed to guarantee the overall safety.

List the main strengths of HERCULES specifically referred to your organization core business 1. Great combination of research centers, SME and Big Companies. 2. IAB presence, to understand real needs and try exploitation with them. 3. Experts in real-time multicore systems, possibility to augment our know how.

Page 34


6.4.6 Exploitation result: Electronics module for central ADAS/AD domain controller

Exploitation Leader: Magneti Marelli (MM)

What is the product/service/result to be exploited for your organization? Electronic Control Unit (ECU), aligned to ISO26262 and AUTOSAR 4.x architecture, with innovative algorithms for autonomous car applications up to level 4 (OICA reference).


☒ Direct industrial use ☒ Technology transfer ☐ License agreement ☐ Publications ☐ Standards ☐ Other


☐ Avionics ☒ Automotive ☐ ICT-Energy Efficiency ☐ New Parallel Programming Libraries ☐ Other

What will you achieve in HERCULES with respect to current similar products, with reference to your result? Increase performance and reliability vs. power consumption vs. cost, keeping flexibility for SW modules inte-gration aligned to state of art in 2020.

Who are the target customers and end-users of your result? Fiat Chrysler Automobiles Group, IVECO

What is the benefit that your result will provide to customers/end users? Car system integration and Reduction of System ECU numbers, cost and complexity. (ADAS domain targets reduction : > -50% ECU numbers; > -50% system cost)

Who are your competitors and how is your product different from theirs? Main European Tier1 and smart sensors developer

List the main strengths of HERCULES specifically referred to your organization core business Experienced partners on multicore heterogeneous platforms for architecture, operating systems, and hypervi-sors.

Page 35


6.5. Summary

In order to summarize and combine the results from exploitation activities, exploitation form and market do-main are reported in the table below.


Exploitation form Market domain

HERCULES Integrated

Framework

UNI-

MORE

Direct industrial use

Technology transfer

License agreement

Publications

Avionics

Automotive

ICT-Energy Efficiency

New Parallel Program-

ming Libraries

Industrial automation

Automotive Use Case MM Technology transfer Automotive

Avionics Use Case AB Technology transfer Aerial

Avionic Uses Case: Aerial

Drone applications PIT Direct industrial Use

Automotive

Avionics


Precision Agriculture

PREM compiler ETHZ Technology transfer

Publications


ming

KCF Tracker CTU Technology transfer

Publications Automotive

Runtime library ETHZ Technology transfer

Publications New Parallel Program-

ming

Run-Time Environment

(RTE) EVI Direct industrial Use

Automotive Industrial automation

Jailhouse co-scheduling

algorithms

UNI-

MORE

Technology transfer

License agreement

Publications

Avionics

Automotive



CTU Technology transfer

Publications

Automotive

Avionics


Jailhouse colouring UNI-

MORE

Technology transfer

Publications

Avionics

Automotive



Jailhouse Memguarding

UNI-

MORE

Technology transfer

Publications

Avionics

Automotive



CTU Technology transfer

Publications

Automotive

Avionics

Page 36


Jailhouse for NVIDIA

TX1/TX2 EVI

Direct industrial Use

Technology transfer

Indirect visibility

Automotive


ERIKA RTOS for ARM Cor-

tex-A on Jailhouse EVI Direct industrial Use

Automotive


FPGA ETHZ Technology transfer

Publications


ming

Energy efficiency

Power management for

SCHED_DEADLINE EVI Indirect visibility

Automotive


HW central electronics

module MM

Direct industrial use

Technology transfer Automotive

Combined feedbacks relative to Strong and Weak points of HERCULES project, with respect to each partner’s core business, are reported in the following table.

Partner Strong Points Weak Points

UNI-

MORE

Partnership with NVIDIA Rich network of contacts with industrial partners in Emilia Romagna Very strong IAB addressing the project to the markets needs

Partnership with NVIDIA could increase the degree of confidentiality of the out-comes of HERCULES

CTU Partnership with Nvidia. Limited access to Computer Vision ex-perts

ETHZ

Use cases and interaction with their owners, complementary expertise of partners.

None

EVI

Collaboration with important actors (MM,NVIDIA, Xilinx). Reference platform for multicores includ-ing ERIKA v3, hypervisors and RTE for the automotive market. Expertise on most innovative multi-core heterogeneous hardware platforms.

Partnership with NVIDIA may steer the focus to a custom architecture. Changes done to open-source software (e.g. Linux, Jailhouse) must remain open-source and thus may not allow direct rev-enue.

PIT

Great combination of research centers, SME and Big Companies IAB presence, to understand real needs and try exploitation with them. Experts in real-time multicore systems, possibility to augment our know how.

The development of such a challenging architecture is subject to potential delays, and lacks of time in integration phase may arise

AB

Reduction of costs and time to get from algorithmic concepts (esp. in the fields of artificial intelligence and machine learn-ing) to proof of concepts and demonstra-tors.

No commercial availability, maturation and maintenance of the HERCULES platform and compilers after the project. No availa-ble generalization of concepts to other high level programming models, besides OpenMP.

MM Experienced partners on multicore heter-ogeneous platform.

Missing a hardware semiconductor main blocks developer.

Page 37


6.6. TRL and HERCULES exploitable results

This chapter defines the TRL number associated to each exploitation result so far. It takes into account the preliminary exploitation results for:

1. The Integrated Framework, that will be exploited in the industrial domain; 2. The two Use Cases, namely the Automotive Use Case and Avionic Use Case; 3. The Individual Exploitation Activities.

The TRL scale defined and adopted by ESA is adopted in HERCULES as the reference to define TRL numbers for software exploitation results. TRL description from 7 to 9 should be slightly modified to eliminate the terms “spacecraft”, “space mission”, “in-orbit”, and substituted with relevant terms addressed by HERCULES results. Anyway, no exploitation result is defined above 6 (see next paragraph), and the ESA table is not double-written here.

6.6.1 TRL for exploitation results

Exploitable results Leading partner Initial TRL Final TRL

HERCULES Integrated Framework UNIMORE 1 5

Automotive Use Case: Valet Parking MM 3 4-5

Avionic Use Case: Real-Time Tracking AGI 4 4

Avionic Uses Case: Aerial Drone applications PIT 3 4

PREM compiler ETHZ 1-2 4-5

KCF Tracker CTU 5

Runtime library (libpremnotify,GPUGuard) ETHZ 1-2 4-5

Run-Time Environment (RTE) EVI 3 5

Jailhouse co-scheduling algorithms UNIMORE, CTU 2 4

Jailhouse colouring UNIMORE 2 6

Jailhouse Memguarding CTU, UNIMORE 2 4

Jailhouse for NVIDIA TX1/TX2 EVI 1 5

ERIKA RTOS for ARM Cortex-A on Jailhouse EVI 2 6

FPGA IP for low-cost remapping of virtual

addresses ETHZ 4

Power management for SCHED_DEADLINE EVI 2 4


MM 2 4

With the basic definition of TRL provided by Horizon2020, the TRLs before and at the end of the HERCULES project for exploitation results are as follows. It must be noticed that all the exploitable results except for the HW central electronics module are software components integrated with electronics/mechanics components. For them the ESA table applies. Relating to MM’s HW central electronics module, it is mainly an hardware component, and the TRL definition is the one commonly adopted within MM. The complete description of TRL definition is reported in Annex2.

Page 38


7. Management of IPR

IPR on Background and Foreground information, as well as exploitation claims and exploitation rights are re-ported in this chapter.

7.1. Definitions

Results: means any (tangible or intangible) output of the action such as data, knowledge or information –whatever its form or nature, whether it can be protected or not– that is generated in the project, as well as any rights attached to it, included intellectual property rights.

Exploitable results: results which can be used for:

1. Using them in further research activities 2. Developing, creating or marketing a product or process 3. Creating and providing a service, or 4. Using them in standardisation activities

Background: means data, knowledge or information – whatever its form or nature any (tangible or intangible) included intellectual property rights – that:

1. is held by the partners before the acceded to the Agreement, and 2. is needed to implement the project or exploit the results.

Foreground: Result

7.2. Background

To enable a trustful and reliable cooperation (i.e. avoid disputes on the property of a specific information) the partners of HERCULES defined their background at the beginning of the project. Pre-existing know-how re-mains of property to the partner that brings it into the project. Details about background owned by individual partners and included in HERCULES are reported in the table below.

Partner Background Information

UNIMORE None

CTU

Scientific publications and open-source software generated by the CTU research team directly involved in the HERCULES Project to the extent that such Background is needed for implementation of the Pro-ject. Excluded is: • all Background generated by the CTU other than by those employees di-rectly involved in the project; • all Background that the CTU is unable to grant access rights to due to existing or pending third party rights; • all Background generated by the CTU which is outside the scope of or not directly related to the Project.

ETHZ None

Page 39


EVI

1. Existing ERIKA Enterprise source codebase. 2. Developed RT-Druid codebase. 3. EForms Eclipse plugin generator codebase and code generation

tool. 4. E4Coder toolset source code.

PIT

Documented scientific work of the perception systems that might be eventually needed to implement the project and to obtain the agreed results. The source code software developed by the research group of PITOM relating perception systems is excluded from the background.

AB Patents DE102011113154, EP000002756458, US020140328537

MM

• Published scientific work required to implement the project and to obtain the agreed results. • Use Cases involved in the activity of Tasks T1.1 and T1.2 in form of binary Algorithms only. The following parts are explicitly excluded from the background: • MM source code.

Partners EVI, PIT, AGI and MM ensured (Specific limitations and/or conditions for exploitation -Article 25.3 Grant Agreement) that all their respective partners do have access — under fair and reasonable conditions — to the background owned by the research group of each of them and needed for exploiting their own results.

7.3. Results

Ownership and access rights to results are defined in the Consortium Agreement. Ownership summary data are stated as follows: Results are owned by the Party that generates them and: Unless otherwise agreed: - each of the joint owners shall be entitled to use their jointly owned Results for non-commercial research ac-tivities on a royalty-free basis, and without requiring the prior consent of the other joint owner(s), and - each of the joint owners shall be entitled to otherwise exploit the jointly owned Results and to grant non-exclusive licenses to third parties (without any right to sub-license), if the other joint owners are given: (a) at least 45 calendar days advance notice; and (b) Fair and Reasonable compensation. Access rights are described as follows: Access rights to results if needed for exploitation of a party's own results shall be granted on fair and reasona-ble conditions. Access rights to Results for internal non-commercial research activities shall be granted on a royalty-free ba-sis. Access Rights to Background if Needed for Exploitation of a Party's own Results, including for research on behalf of a third party, shall be granted on Fair and Reasonable conditions.

Page 40



Foreground ownership

UNIMORE

CTU ETH

Z EVI PIT AGI MM

HERCULES Integrated Framework UNIMORE X X X X

Automotive Use Case: Valet Parking MM X

Avionic Use Case: Real-Time Tracking AGI X

Avionic Uses Case: Aerial Drone appli-

cations PIT X

PREM compiler ETHZ X

KCF Tracker CTU X

Runtime library (libpremnoti-fy,GPUGuard)

ETHZ X

Run-Time Environment (RTE) EVI X

Jailhouse co-scheduling algorithms UNIMORE,

CTU X X X

Jailhouse colouring UNIMORE X

Jailhouse Memguarding CTU, UNI-

MORE X X

Jailhouse for NVIDIA TX1/TX2 EVI X

ERIKA RTOS for Jailhouse EVI X

FPGA IP for low-cost remapping of vir-

tual addresses ETHZ X


SCHED_DEADLINE EVI X


MM X

In the above table:

Leading partner: is the partner in charge of result exploitation. Usually this is the partner which has developed most of the result or it has the facilities to produce it.

Foreground: each partner has a column about the Foreground IP. Where a cell contains an X, the respective partner owns the whole or part of the respective exploitable result.

Information concerning exploitable results, IP protection strategies and patents, licences etc. is reported be-low.

Page 41



IP Protection Notes

HERCULES Integrated Framework UNIMORE

Automotive Use Case: Valet Park-

ing MM Industrial design

Avionic Use Case: Real-Time

Tracking AGI Patent

Avionic Use Case makes use of

patents DE102011113154B4,

US000009361543B2

Avionic Uses Case: Aerial Drone

applications PIT Industrial design

PREM compiler ETHZ

KCF Tracker CTU Copyright

Runtime library (libpremnoti-

fy,GPUGuard) ETHZ

Run-Time Environment (RTE) EVI Copyright

The RTE is released by EVI un-

der a fee. Source code is not

disclosed.

Jailhouse co-scheduling algorithms UNIMORE,

CTU Patent

Jailhouse colouring UNIMORE

Jailhouse Memguarding CTU , UNI-

MORE

Copyright (GPL

license)

Jailhouse for NVIDIA TX1/TX2 EVI None (released

as open-source)

ERIKA RTOS for ARM Cortex-A

on Jailhouse EVI Copyright

EVI releases the ERIKA RTOS

under a dual-license scheme: the

RTOS is released under the free

GPLv2 license; the linking excep-

tion (or a commercial version) is

available through a fee.

FPGA IP for low-cost remapping of

virtual addresses ETHZ


SCHED_DEADLINE EVI

None (released

as open-source)

HW electronics module for central

ADAS/AD domain controller MM Industrial design

Page 42


8. Interaction with the IAB

As part of the exploitation strategy, an initial list of members of the Industrial Advisory Board (IAB) was already setup and described in the Description of Work. The HERCULES IAB is a team of industrial experts who pro-motes the dissemination and exploitation of the project within their companies. The IAB consists of important industrial organizations, external to the project consortium, with significant activities and needs in the key are-as addressed by HERCULES. IAB members also helps disseminate the project outcomes to other customers and companies in their supply chain, potentially leading to additional industrial contacts that can be exploited by the project partners for joint activities. IAB has grown during the project, and contains ARM, Autoliv, BMW Car IT, Calzoni, CodePlay, Continental, Daimler, Honeywell, IMA, Kalray, Leonardo, MBDA, Nvidia, Porsche Engineering Service, SACMI, Tom’s hardware, TopCon Positioning Systems, Vodafone Automotive, and Yanmar. Two meetings with the IAB members have been organized during the project. In May 10th 2016, the first work-shop was held in Venaria Reale (TO), Italy, at MM’s official location. The second meeting was in Prague, at the official location of CTU, in June 13th 2017. In the first workshop, IAB members participated to a full-day meeting where the consortium presented the HERCULES vision and intermediate results. IAB members were asked to evaluate the ongoing work on HER-CULES against their companies’ requirements, to ensure that the project results could be tuned along the upcoming industrial needs. Before the IAB meeting, the Consortium prepared a Post-IT session, where IAB members were asked to an-swer to the following questions: 1. What are the weak points of the project? 2. What are the strong points of the project? 3. Which products could be improved using HERCULES technology? 4. What kind of services would you expect from HERCULES startup? In the second meeting, the Consortium gave the IAB the updates of HERCULES results. A specific session was held to let IAB members pose their questions, and answer to them. All questions/answers were registered in the minutes of the meeting, and demonstrated the high level of technical preparation and interest of IAB member representatives. All questions/answers were taken into strong consideration by the Consortium as precious insights for tech-nical developments and future exploitation activities.

Page 43


Figure 5. Leonardo member participates to the Marketplace discussion in the 1st workshop

8.1. Collaboration with IAB members

The following table reports the individual collaboration activities that partners of the Consortium have estab-lished with IAB members. Inside columns, the following details are provided. Collaboration with IAB members: the name of IAB members with whom the partner has established a collabo-ration activity Collaboration started during HERCULES: The IAB members the partner started to work with during the project Specific activity and foreseen result: the activity the partner is carrying on with each IAB member and the re-sults expected from the collaboration

Partner Collaboration with IAB

members Specific activity and foreseen result

UNIMORE Nvidia, SACMI, Bosch,

UTRC Predictable software stack for reference

heterogeneous platforms

MM - -

AGI - -

CTU Porsche Engineering,

Honeywell Autonomous driving experiments, applied re-

search

ETH - -

Page 44


EVI

ARM IMA

Kalray Vodafone Automotive

The SCHED_DEADLINE Power Management has been done jointly with ARM.

SCHED_DEADLINE was shown by EVI at ARM booth during the Embedded Linux Conference

Europe (ELCE), October 2017

Partners with IMA and UNIMORE on the ECSEL project I-MECH

Partners with Kalray in the P-SOCRATES pro-

ject

Vodafone Automotive is currently a customer-

PIT Yanmar -

Page 45


9. Exploitation with other stakeholders

HERCULES partners dedicated a lot of effort in presenting the HERCULES framework to main industrial play-ers in different domains: platform providers (Nvidia, Xilinx, Samsung, ARM, Kalray, Huawei), automotive (OEMs such as Maserati, Porsche, BMW, Ferrari, Daimler, Energica, etc.; TIER 1 such as Veoneer, Bosch, Continental, Autoliv, Egicon, etc.), avionic (Finmeccanica/Leonardo, Honeywell, Archon, etc.), industrial auto-mation (Tetra Pak, SACMI, IMA, GD, Comau, etc.), and others (Doxee, Bylogix, Pluservice, Lifetouch, etc.). In order to spread the adoption of technologies developed within HERCULES, UNIMORE provided financial support to two Italian SMEs, namely Bylogix and Lifetouch, whose details are reported in the following para-graphs. We posed five questions to the SMEs, to understand why they are interested in the HERCULES out-comes and how they plan to exploit some of them. Questions are in the titles of the paragraphs, and a direct answer is provided.

9.1. Bylogix and Autonomous Driving

9.1.1 Company introduction

Bylogix s.r.l. is an Italian SME established in 2007, specialised in embedded applications for the automotive, railway, naval, industrial and automation sectors, working in Italy and abroad. With a strong focus on research and development, Bylogix designs, develops and implement SW and HW for embedded electronic devices (actuation, control, supervision, data acquisition systems…), as well as valida-tion, integration and testing systems. Bylogix performs the verification and validation of functional require-ments, as well as safety analysis activities in compliance with current international standards (ISO26262). For all these activities, Bylogix is an ISO 9001:2008 certified company and regularly performs them for its Cus-tomers. Its skills and expertise can be apply to all sectors, from the automotive to the medical one. The Com-pany has indeed a multifaceted expertise in electronics, electric engineering, mechanics, mechatronics, and informatics, applicable to several domains and is able to work both on single components and on the complex systems where those components are integrated, proposing innovative customized and turnkey solutions.

9.1.2 Domain of interest

Bylogix is fully involved in the Autonomous Driving trend since 2015 with several internal projects that focus on developing a system architecture in order to integrate autonomous driving functionalities and additional fea-tures. With the ORT (Object Recognition Technology) the car, thanks to sensors and high-speed cameras distributed all around the vehicle, can recognize approaching objects (such as vehicles, bicycles, pedestrians or animals), identify them and send actuation signals for vehicle management. All those functionalities are possible thanks to AI (Artificial Intelligence) software implemented on Nvidia Platform combine neural networks technologies solution and real time drive capabilities. The aim of the project is to implement, as a proof of concept, a fully autonomous vehicle using computer-vision based sensors only.

9.1.3 Why HERCULES is an added value for you and your customers

HERCULES platform sets a standard as a comprehensive automotive and industrial, state of the art, resource-aware system for enterprise-class software needs. It features a reliable hypervisor system together with a fully reliable Operative System capable of supporting real-time as well as multitasking user space applications. Those features enable us to deliver our software solutions following the NVIDIA vision of a supercomputer for the entire software stack of automotive and industrial applications, that is the most promising architecture now available. We foresee this paradigm will be the most widely adopted in the engineering field in the near future.

Page 46


Unifying the hardware and the software stack for applications usually run on several custom hard-ware/software packages ensures better performance and a more reliable data exchange in the first place. Moreover, this enables us to focus our resources on software architectures more than hardware customiza-tions. A streamlined software design and development, relying on globally available knowledge and an open stack (mostly GPL’d), ensures us to be more reactive and effective upon responding to our customer’s needs.

9.1.4 Results

The vehicle, actually a car, will follow a predefined path running through the available free space ahead, decid-ing the best speed to have, whether to break and avoiding obstacles trying to find the best way into the middle of the perceived free space. The architecture will consist of several layers accomplishing several tasks in loop: sensing the state of the car, identifying the position and the free space ahead, fusing the sensor information, computing a suitable path, communicating with the car body, and sending the actuation commands. Most of the software will run on a specific hardware platform provided by NVIDIA functioning as a main controller. A fully electric vehicle is adopted that has been equipped either with an NVIDIA DRIVE PX2 or a NVIDIA Jet-son TX2 as the main controller.

Figure 6. The e-Mehari car integrating the HERCULES framework on board

The overall hardware setup is composed like follows:

• 4 x 120° Sekonix Cameras for front and surround view

• 2 x 60° Sekonix Cameras for stereo vision

• NVIDIA® DRIVE PX-2 Platform (or Nvidia Jetson TX2) as the main controller

• EMLID RCH101 RTK GNSS receiver to handle global positioning

• Raspberry Pi 3 as GPS asynchronous processing

Page 47


Figure 7. View of the electronic platform

The car state is acquired via direct access to the CANBUS networks of the car. We sniff the bus for the mes-sages from the SAS and the powertrain to get the actual steering angle and the current speed. The integration with these networks is obtained by directly wiring the preexisting networks to two of the CAN ports we have on the main controller. A Raspberry Pi 3, connecting an EMLID RCH101 receiver, collects GPS data and shares it implementing a TCP network server open to the main controller to query the actual position of the car. An extremely accurate positioning prediction is enabled by natively using the RTK GNSS service. This system is used to track and log the desired path to follow and provided to the piloting algorithm with minimum preprocessing.

Figure 8. Visual representation of the path to follow

VeGA is equipped with several cameras, proximity sensors and a GPS subsystem covering different aspects of its sensing capabilities. We have a system of three cameras in the front aimed to detect the shape of free space in the distance. One 120° camera accomplishes to horizontal and vertical spatial vision, together with an approximate idea of the depth. A pair of 60° cameras provides stereo vision capabilities aimed to detect a more precise idea of the distances ahead.

Page 48


Figure 9. Another visual representation of the path to follow

9.1.5 Which are HERCULES exploitation results more interesting for you?

Features we most appreciate of the HERCULES project are:

• Mostly Open Source software stack (mostly GPL’d);

• Predictable real-time Hypervisor system;

• High performance real time Operative System support (both GNU/Linux and ERIKA);

• Pervasive use of predictable execution model.

Above the others, we consider the PREM approach very promising to develop truly reliable software products. It is exceptionally useful when it comes to safety, and to qualify tasks for functional safety, guaranteeing dura-ble and predictable performances.

9.2. Lifetouch and Last Mile Delivery

9.2.1 Company introduction

Lifetouch was founded in 2015 and it is an Engineering and UX design studio. It has more than 15 years of experience in interface design, ergonomics, project development, engineering, and testing, with a full under-standing of the whole HMI process, AI DL/ML, E-Mobility, Autonomous Driving, ranging from strategic consult-ing to technical implementation. The team is composed of Engineers, Designers and Computer scientists. Some of them are engineers coming from the automotive field, and others are engineers and Computer scientists with Phd and Master degree in AI. Lifetouch is also introducing AI features in the interfaces, to make them contextual and predictive. These Human Machine Interface’s projects are expression of the most advanced solutions both in terms of graphic design and interaction. A novel strategic project for Lifetouch is a “Last Mile Delivery Robot”. This robot can delivery packages point to point autonomously, detect its position and move itself avoiding the obstacles.

9.2.2 Domain of interest

Lifetouch is interested in the domain of Mobile Robotics and Last Mile Logistics. In particular, we are interested in the self-driving robotics applied to Last Mile delivery.

Page 49


This knowledge can be applied in the Last Mile Delivery Robot in development, to make it safer, faster and robust. Every year in EU+USA >25bilions of packages and >3bilions of takeaway food are delivered. Last mile delivery is the most expensive share in the logistic domain (around the 50% of the total cost). Considering the takeaway food deliveries, the average cost is around 3-4€ per delivery. The cost of the same delivery made by our autonomous robot could decrease to 1,5€. Considering a market share of the food deliveries of just the 3%, the estimation of the turnover in five year is 150M€/y.

9.2.3 Why HERCULES is an added value for you and your customers

HERCULES is an added value for Lifetouch to predictably improve the performances of its own applications, offering a combined eco-system that allows the safe co-existence of a general-purpose OS (i.e., Linux) where we could run ROS-based navigation libraries, along with a hard real-time OS (i.e., ERIKA Enterprise) that can support latency-sensitive actuation and control tasks. The selection of the embedded platform is particularly suitable for the mobile robots adopted for the last mile delivery, providing sufficient computing performance within a reasonable size and power consumption.

9.2.4 Results

In Lifetouch, we applied the HERCULES framework on top of an NVIDIA Jetson TX2 platform mounted on board of the autonomous Rover. Specifically, we performed:

• The integration of cameras and Lidar

• The integration of serial communication

• The Integration on the rover of the Nvidia platform used in the HERCULES framework

Figure 10. The Lifetouch autonomous robot MOVE

9.2.5 Which are HERCULES exploitation results more interesting for you?

Beside the mentioned ERIKA+Linux predictable support, we are interested in the Jailhouse Hypervisor and specifically in the porting to NVIDIA TX1/TX2.

Page 50


10. Conclusion

This document detailed the Final Exploitation Plan of the HERCULES project, as well as exploitation activities performed so far. Exploitation results have been separately discussed for the Integrated Software Framework, the Automotive and Avionic Use Cases, and the Individual Activities. The HERCULES project had the opportunity to share vision, ideas and technology improvements to members of the Industrial Advisory Board, composed of Industrial groups with a great relevance in their respective mar-kets. The interaction with the IAB provided important feedbacks to guide the technology development towards real industrial needs, fostering in some cases immediate industrial exploitation. Even before the HERCULES framework was ready, a long list of exploitation activities directly attributable to HERCULES have been put into action and reported in this document.

Page 51


Annex 1: TRL methodology

Executive summary

This report addresses the degree of maturity expected for the exploitation results of the HERCULES project. Though Technology Readiness Levels are already defined in Horizon2020, they are general purpose and not strictly related to a specific area. This document focuses on establishing a more specific detail of TRLs to bet-ter address the HERCULES exploitation results, and to serve as guidelines for the overall maturity improve-ment of results throughout the project. The guidelines proposed in this report are derived from multiple sources, and specifically integrated to adhere with the project specific activities.

Purpose

The purpose of this Annex is to provide a guideline for the Technology Readiness Assessment (TRA) of the exploitable results obtained by the HERCULES consortium. This is in response to the recommendation of the Project Officer concerning future work to be done after the review meeting held in Brussels in October 2016. The TRA is here provided to define a way to set the TRL for the results, in a unique, concise and clear man-ner. That is useful to state which level of maturity the result will get at the end of the project. Moreover, TRA is a good way to evaluate progress activities, and finally verify the results obtained. As no common rule is adopted neither world-wide nor at European level, a preliminary study of current meth-odologies has been performed. Though different organization accept the TRL subdivision into 9 different ma-turity levels, they adapt the general-purpose scale to their specific area.

Page 52


Overview methodology

Introduction

According to the US Department of Energy (DoE), a Technology Readiness Assessment (TRA) is a systemat-ic, metric-based assessment of how far technology development has progressed5. It is not a pass/fail exercise, and is not intended to provide a value judgment of the technology developers or the technology development program. A TRA evaluates technology maturity using the Technology Readiness Level (TRL) scale that was pioneered by the National Aeronautics and Space Administration (NASA) in the 1980s. Some widely known papers de-scribing TRLs used in NASA were written by Mankins67. A TRA can:

• Identify the gaps in testing, demonstration and knowledge of a current TRL and the information and steps needed to reach the TRL required for successful inclusion in the project;

• Identify at-risk technologies that need increased management attention or additional resources for technology development;

• Increase the transparency of management decisions by identifying key technologies that have been demonstrated at certain levels of maturity or by highlighting immature or unproven technologies that might result in increased project risk.

In 2011, an early study on Key Enabling technologies (KET)8 performed by the High Level Expert Group on Key Enabling Technologies (HLG-KET), recommended that the TRL scale be used as tool for assessing the results and expectation of the projects. This was further adopted by the European Commission and included in their 2012 Communication on KETs9. Although TRL scale is now widely adopted in organizations working on innovation activities, some major limita-tions must be highlighted. That makes necessary to adapt the TRL scale to a specific scenario. Main limita-tions in use are reported as follows:

• Lack of attention to feedbacks in technology maturity. TRL scale does not into account that high TRL often require a great amount of research.

• Single technology maturity approach. As the TRL scale focuses on a single technology component, limitations arise when the project moves from low TRL (a single component is addressed) to high TRL, where integration of different technologies may be required.

• Focus on product development, rather than manufacturability, commercialization and organizational changes. TRL scale was first proposed and deployed for product design. Today, TRL adaptations are needed to use the scale for planning and communication activities. For instance, the H2020 SME In-strument program is now requiring a high TRL for accessing funding and providing a business plan for future development.

• Context specificity of TRL scales. Different purposes lead to different operational needs. Usually the adaptation is done by adjusting the definitions of the levels, i.e. the scale needs to be adapted to the specific purpose of the organization.

5 U.S. Department of Energy, Office of Environmental Management. Technology Readiness Assessment (TRA) / Technology Matu-ration Plan (TMP) Process Implementation Guide, Revision 1, August 2013 6 John Mankins, Technology Readiness Levels. A white paper. April 6, 1995, Advanced Concepts Office, Office of Space Access and Technology, NASA 7 Mankins JC. Technology Readiness Assessments: A Retrospective. Acta Astronautica. 2009;65:1216-23. 8 PB Larsen, E Van de Velde; E Durinck, HN Piester, L Jakobsen & H Shapiro (2011), Cross-sectoral Analysis of the Impact of International Industrial Policy on Key Enabling Technologies, DTI & Idea Consult, Copenhagen 9 European Commission (2012), A European strategy for Key Enabling Technologies. A bridge to growth and jobs, Brussels.

Page 53


The figure below10 shows how the usefulness of a particular technology evolves in time, and how the technol-ogy development phases relate to the TRLs. It is clear that most of the TRLs occur early in the technology life cycle, where:

• TRL1 to TRL3 address general conceptual science matters. A step up from TRL1 to TRL2 shifts ideas from pure to applied research;

• TRL4 to TRL5 cover the transition from scientific research to engineering and system development. TRL4 is the first step in determining whether the individual components will work together as a system

• TRL6 to TRL9 focus on engineering matters. TRL6 begins true engineering development of the tech-nology as an operational system, and TRL9 represents the final stage of the technology, when the technology is fully operational and its maturity is reached.

Figure 11. Technology Life Cycle and Technology Readiness Levels

The table below represents the operational scale to progress from TRL1 to TRL9, and the associated fidelity associated to the final TRL9 product.

TRL Scale of testing System fidelity Environment 1 Paper

2 Paper

3 Laboratory Pieces Simulated

4 Laboratory Pieces Simulated

5 Laboratory Similar Simulated

6 Laboratory/Benchmark Similar Relevant

7 Full Similar Operational (limited range)

8 Full Identical Operational (full range)

9 Full Identical Operational (full range)

Table 1. Relationship of Testing Recommendations to the TRLs

In the table above, the following definition apply.

1. Scale of testing: a. Full scale matches final application. b. 1/10 full scale < engineering/pilot scale < full scale (typical)

10 Nolte, William L. 2008. Did I Ever Tell You about the Whale? or Measuring Technology Maturity. Information Age Publishing,

Page 54


c. Lab scale < 1/10 full scale (typical) 2. System fidelity:

a. Identical matches final application in all aspects b. Similar matches final application in almost all aspects c. Pieces matches a piece or pieces of the final application d. Paper exists on paper

3. Environment: a. Operational (full range) full range operational capacity b. Operational (limited range) limited range operational capacity c. Relevant simulated environments plus a limited range of external features d. Simulated restrictive range of simulation

The TRL scale in Horizon2020

In Horizon2020, where a topic description refers to a TRL, the following definitions apply, unless otherwise specified11:

TRL Definition TRL1 Basic principles observed

TRL2 Technology concept formulated

TRL3 Experimental proof of concept

TRL4 Technology validated in lab

TRL5 Technology validated in relevant environment (industrially relevant environment in the case of key enabling technologies)

TRL6 Technology demonstrated in relevant environment (industrially relevant environment in the case of key enabling technologies)

TRL7 System prototype demonstration in operational environment

TRL8 System complete and qualified

TRL9 Actual system proven in operational environment (competitive manufacturing in the case of key enabling technologies; or in space)

Table 2. Definition of TRL scale in Horizon2020

Horizon2020 makes use of the TRL scale to decide which type of projects can be funded with the proposed TRL level given in call descriptions, and for use in evaluation. The scale needs to be adapted to the specific purpose of EU funding for RDI programmes as it does not ad-dress the well-known feedback mechanisms intrinsic to innovation processes. The description of the TRL scale is briefly reported in the following figure.

Figure 12. The TRL scale adapted to the KETs HLG three pillar-bridge model

Another reading is done to the 9 TRL levels12, and formatted according to innovation actions like Horizon2020 projects. An integrative approach (combining different technologies and addressing market and organizational

11Horizon 2020, Work Programme 2017-2017, General Annexes. (see http://ec.europa.eu/research/participants/data/ref/h2020/other/wp/2016_2017/annexes/h2020-wp1617-annex-g-trl_en.pdf)

Page 55


issues) is adopted and the different stages in maturity are aligned to the various ways governments can sup-port RDI activities. In the scenario, manufacturability is also incorporated.

Figure 13. EARTO reading on the TRL scales, incorporating manufacturability and including

A full description of the TRL levels proposed by EARTO for European funded projects is shown in the following table.

12See http://www.earto.eu/fileadmin/content/03_Publications/The_TRL_Scale_as_a_R_I_Policy_Tool_-_EARTO_Recommendations_-_Final.pdf

Page 56


Cluster TRL H2020 terminology EARTO reading EARTO definition and description

Invention

TRL1 Basic principles observed Basic principles observed Basic scientific research is translated into potential new basic principles that can be used in new tech-

nologies

TRL2 Technology concept formulated Technology concept

formulated Potential application of the basic (technological) principles are identified, including their technological concept. Also the first manufacturing principles are explored, as well as possible markets identified. A small research team is established to facilitate assessment of technological feasibility.

Concept validation

TRL3 Experimental proof of concept First assessment of feasi-

bility of the concept and technologies

Based on preliminary study, now actual research is conducted to assess technical and market feasibil-ity of the concept. This includes active R&D on a laboratory scale and first discussions with potential clients. The research team is further expanded and early market feasibility assessed.

TRL4

Technology validated in lab Validation of integrated prototype in a laboratory

Basic technological components are integrated to assess early feasibility by testing in a laboratory environment. Manufacturing is actively researched, identifying the main production principles. Lead markets are engaged to ensure connection with demand. Organisation is prepared to enter into scale up, possible services prepared and a full market analysis conducted.

Prototyping and incuba-

tion TRL5

Technology validated in rele-vant environment (industrially relevant environment in the case of KETs)

Testing of the prototype in a user environment

The system is tested in a user environment, connected to the broader technological infrastructure. Actual use is tested and validated. Manufacturing is prepared and tested in a laboratory environment and lead markets can test pre-production products. Fist activities within the organisation are estab-lished to further scale up to pilot production and marketing

Pilot produc-tion and

demonstration

TRL6

Technology demonstrated in relevant environment (industri-ally relevant environment in the case of KETs)

Pre-production of the product, including testing in a user environment

Product and manufacturing technologies are now fully integrated in a pilot line or pilot plant (low rate manufacturing). The interaction between the product and manufacturing technologies are assessed and fine-tuned, including additional R&D. Lead markets test the early products and manufacturing pro-cess and the organisation of production is made operational (including marketing, logistics, production and others).

TRL7

System prototype demonstra-tion in operational environment

Low scale pilot production demonstrated

Manufacturing of the product is now fully operational at low rate, producing actual commercial prod-ucts. Lead markets test these final products and organisational implementation is finalized (full market-ing established, as well as all other production activities fully organized). The product is formally launched into first early adopter markets.

Initial market introduction

TRL8 System complete and qualified Manufacturing fully test-

ed, validated and qualified Manufacturing of the product, as well as the product final version is now fully established, as well as the organisation of production and marketing. Full launch of the product is now established in national and general early majority markets.

Market ex-pansion

TRL9

Actual system proven in opera-tional environment (competitive manufacturing in the case of KETs)

Production and product fully operational and competitive

Full production is sustained, product expanded to larger markets and incremental changes in the product create new versions. Manufacturing and overall production is optimized by continuous incre-mental innovations to the process. Early majority markets are fully addressed.

Table 3. The TRL scale proposed by EARTO

Page 57


TRL adaptations to other organisations

Many adaptations of the general purpose TRL scale have been adopted for specific areas and organizations. In the following, some of them are extracted and reported here as a reference13. An example of this adaption of the TRL approach to the specific needs of the organization can be found in the Guide to TRA published by the US Department of Energy14. In this guide, energy based aspects are incorpo-rated while maintaining the 9 levels. The description for each level is shown in the figure below.

Figure 14. TRL scale for the US Department of Energy

Specific works have been published to define the TRL scale for software applications. One of them15 proposed a customization of the TRL scale to develop the overall software for a smart grid. Within this document a review of different TRLs coming from different organizations is described. The following table below highlights the meaning of the TRL scale among some major organizations. In the table, USA DoE data are related to nuclear fuel only.

13http://www.earto.eu/fileadmin/content/03_Publications/The_TRL_Scale_as_a_R_I_Policy_Tool_-_EARTO_Recommendations_-_Final.pdf 14 United States Department of Energy (2011), Technology Readiness Assessment Guide, Washington. 15 C. Tugurlan, H. Kirkham, D. Chassin. Software Technology Readiness for the Smart Grid. Pacific Northwest National Laboratory, Advanced Power and Energy Systems, Richland, WA

Page 58


TRL National Aeronautics and Space (NASA)

Department of Defense (DOD)

Department of Energy (DoE)

North Atlantic Treaty Organization (NATO)

0

N/A N/A N/A Basic research with fu-

ture military capability in

mind

1

Basic principles observed

and reported


and reported

Initial concept verified

against first principles

and evaluation criteria

defined


and reported in context of

a military capability

shortfall

2

Technology concept

and/or application formu-

lated

Technology concept


lated

Technical options evalu-

ated and parametric rang-

es are defined for design

Technology concept


lated

3

Analytical and experi-

mental critical function

and/or characteristic

proof-of-concept




proof of concept

Success criteria and

technical

specifications are

defined as a range




proof of concept

4

Component and/or

breadboard validation in

laboratory environment

Component and/or


laboratory environment

Fuel design parameters

and features defined

Component and/or


laboratory/field (eg

ocean) environment

5

Component and/or


relevant environment

Component and/or


relevant environment

Process parameters de-

fined

Component and/or


relevant (operating) envi-

ronment

6

System/subsystem model

or prototype demon-

strateon in a relevant

environment (ground or

space)


or prototype demonstra-

tion in a relevant envi-

ronment

Fuel safety basis estab-

lished


or prototype demonstra-

tion in a realistic (operat-

ing) environment or con-

text

7

System prototype demon-

stration in a space envi-

ronment


stration in an operational

environment

All quantification steps

completed and fuel is

licensed


stration in an operational

environment or context

(eg exercise)

8

Actual system completed

and “flight qualified”

through test and demon-

stration (ground or space)


and “flight qualified”

through test and demon-

stration

Reactor full-core conver-

sion to new licensed fuel

completed


and qualified through test

and demonstration

9

Actual system “flight

proven” through success-

ful mission operations

Actual system “flight

proven” through success-

ful mission operations

Routine operations with

licensed fuel established

Actual system operation-

ally proven through suc-

cessful mission opera-

tions

Table 4. TRL definitions used by the leading government agencies

Page 59


TRA for software activities

ISO 16290:201316 defines the TRL scale primarily for space system hardware, although the definitions could be used in a wider domain in many cases. The definition of the TRLs provides the conditions to be met at each level, enabling accurate TRL assessment. ISO 16290:2013 TRL definition does not address the use of TRLs for software and there is no international or even European uniform approach for using TRLs for software developments17. European Space Agency (ESA) has adopted for its convenience the 16290:2013 TRL scale for software developments by providing a clear definition of the expected development state at each TRL. Moreover, due to their very different development and application characteristics, ESA has identified three types of software for the purpose of TRL definition18:

1. Software tool. Software that runs in a stand-alone mode, i.e. without requiring a specific in-put/output simulator

2. Embedded Software. Software that necessarily interacts with other software and possibly also with HW. Two categories exist as follows:

a. Building block: embedded software conceived to be reused in a range of missions, either flight or ground software. This software is executed as part of a larger software application (this category includes IP cores for micro-electronics, e.g. FPGA, ASICs).

b. Specific embedded software: software that is targeting a specific application and that is not conceived to be reused in another domain of application (e.g. equipment embedded software).

3. Software that cannot be considered separated from the hardware which it runs on, e.g. equipment embedded software. For this type of software component ESA proposes to use the TRL classifica-tion of the system of which the specific software is part of.

Some examples that can be found in ESA documents and that address the main results of HERCULES are reported below in the next paragraphs.

16 ISO 16290:2013 Space systems, Definition of the Technology Readiness Levels (TRLs) and their criteria of assessment (see http://www.iso.org/iso/catalogue_detail.htm?csnumber=56064) 17 Guidelines for the use of TRLs in ESA programmes (see https://artes.esa.int/sites/default/files/ESSB-HB-E-002-Issue1(21August2013).pdf) 18 TEC-SHS/5551/MG/ap. Technology Readiness Level Handbook for Space Applications, September 2008 (see https://artes.esa.int/sites/default/files/TRL_Handbook.pdf)

Page 60


Example for software building block

A typical software building block is an on-board operating system. This example is particularly meaningful as it addresses the most important exploitation result of HERCULES, that is the HERCULES Integrated Frame-work. The description of TRL for an operating systems is here slightly changed with respect to the ESA docu-ment to better accomplish the HERCULES framework.

TRL Description 1 the mathematical formulation of the scheduling theory is done

2 there is a prototype of the scheduling algorithm itself, without any hardware or application context, but

scheduling with this particular algorithm is feasible

3

there is an architecture that shows not only the scheduling algorithm, but also the interrupt management, the

semaphores, the relation to hardware timers, etc. Integrating the algorithm into an operating system is feasi-

ble

4

the operating system has a specified interface for application software users, all expected functions of an

operating system are implemented, but not all are tested (e.g. the priority inversion protection). The operat-

ing system has been validated by running in a simulator of the target processor, itself being a software run-

ning on a standard PC

5

the domain of use of the operating system is defined, in terms of target processors (e.g. NVIDIA Tegra),

communication capabilities (e.g. drivers) or operational capability (e.g. maximum number of priority, tasks,

semaphores). The operating system is validated for all the parameters values and hardware environment that

are foreseen in the domain of reuse. The validation environment is a hardware board with a representative

target processor and hardware communication drivers

6

a formal qualification data package (in the meaning of the software standards applied in the foreseen criti-

cality level) is available and approved by software product assurance. It constitutes a qualification credit that

can be invoked in a project. The process to be used in order to delta-qualify the operating system in the user

project is defined. Support to users is organized (helpdesk). The operating system can be called a “product”

and can be proposed to users

7

A specific target application has selected the operating system for its multi-core, heterogeneous, low power

computing platform. At this point, target processor, communication drivers and maximum sizes and ranges

are set. There is a successful qualification of the operating system with these values, in the intended envi-

ronment. The validation environment includes the actual hardware of the project, i.e. at least the two plat-

forms selected for the project

8 the software is integrated in the final embedded system that has been accepted and is ready for operations

9 the embedded system is fully working in its real environment and the operating system is nominally func-

tioning

Table 5. TRL description for an operating system

Page 61


Example for software tool

Another meaningful example is for software tools. A typical software tool is a compiler, and TRLs for this case are reported below as described by ESA.

TRL Description

1 the algorithm related to parsing source code to generate machine code or gates, in one or several passes,

exists

2 there is a set of prototypes that reads a selection of the source code syntax and generates machine code using

part of the instruction set

3 the architecture of the compiler is defined, and the complete source code syntax and semantics is covered

4 the Alpha version of the compiler has a primitive man machine interface, generates non optimized machine

code, and the execution time is slow. It is validated using typical examples of source code

5

the Beta version of the compilers has optimized the machine code generation, the performance and the er-

gonomy of the man machine interface. A reference test suite of source code has been established to validate

the compiler, and the generated object code runs on the hardware processor

6

the compiler is a Product with a good documentation and acceptable performances. It produce error messag-

es which are complete and user friendly. The support is organized, as well as the product packaging and

delivery

7 the compiler is delivered to early adopters for extensive testing. Then, the compiler robustness is improved

following user feedbacks

8 the compiler is deployed to the complete user community

9 the compiler is deployed to the complete user community

Table 6. TRL description for a compiler

Detailed definitions of TRL by ESA

The following table reports the TRL detailed definition for software developments at ESA.

Page 62


TRL SW terms Explanation Description Requirements

Verification

Viability

1 Mathematical

Formulation Scientific knowledge

Detailed mathematical for-

mulation description. Publi-

cation of research

results.

Expression of a problem

and of a concept of solution. Proven mathematical

formulation.

Feasibility to be im-

plemented in software

with available compu-

ting facilities demon-

strated.

2 Algorithm

Individual algorithms

or functions are pro-

totyped

Algorithm Algorithm Individual algorithms or func-

tions are prototyped Algorithm

3 Prototype Prototype of the inte-

grated main system

Architectural design of im-

portant functions is docu-

mented. Depending on size

and complexity of the im-

plementation.

Some solutions to a range of

problem. Main use cases

implemented.

A subset of the overall function-

ality is implemented and tested

to allow the demonstration of

performance.

V&V in a simulated laboratory

environment.

Feasibility to build an

operational system

taking into account

performance and usa-

bility aspects demon-

strated.

4 ALPHA ver-

sion Most functionality

implemented.

Documentation as for TRL 3

plus:

1. User Manual

2. Design File

Clear identification of the

domain of applicability.

Requirements for solutions

to a range of problems speci-

fied. All use cases imple-

mented.

V&V process is partially com-

pleted, or completed for only a

subset of the functionality or

problem domain. V&V in a

representative simulated labora-

tory environment.

Feasibility to complete

missing functionality

and reach a product

level quality demon-

strated

5 BETA version Implementation of

the complete software

functionality.

Full documentation accord-

ing to the applicable soft-

ware standards, including

test reports and application

examples.

Formal definition of the

domain of (re)use and asso-

ciated variability features of

the implementation. All use

cases and error handling

specified.

Validated against the require-

ments of the complete domain

of applicability including ro-

bustness. Quality assurance

aspects taken into account.

V&V in an end-to-end repre-

sentative laboratory environ-

ment including real target.

Feasibility to fix all the

reported problems (e.g.

all open SPRs) within

available resources

demonstrated. User

support organization in

place.

6 Product RE-

LEASE

Ready for use in an

operation-

al/production context,

including user sup-

port.

Documentation according to

the applicable SW eng and

Quality standards for a soft-

ware product.

Building block: Process for

reuse, for instantiation in the

domain of the implementa-

tion and its test environment.

Tools: all use cases and error

handling implemented.

User friendliness validated.

Building block: validated

against the requirements of the

complete domain, validation

environment also reusable,

reuse file available.

Tools: V&V process is com-

plete for the intended scope,

including robustness. Configu-

ration control and Quality as-

Feasibility to be ap-

plied in an operational

project demonstrated.

Availability of a data

package suitable to

support future qualifi-

cation.

Page 63


surance processes fully de-

ployed

V&V in an End-to-end fully

representative laboratory envi-

ronment including real target.

7 Early adopter

version

Building block: quali-

fied for a particular

purpose

Tool: ready for mar-

ket deployment

In addition to TRL 6 Docu-

mentation, updates to docu-

mentation and qualification

files SPR database

Lessons learnt report

Requirements traced to mis-

sion requirements. Validity

of solution confirmed within

intended application. Re-

quirements specification

validated by the users.

Building block: Integrated in the

spacecraft following the appli-

cable software standards

Tools: The tool has been suc-

cessfully validated in a pilot

case, representative of the in-

tended project application

Engineering support

and maintenance or-

ganization in place,

including helpdesk

8 General

product

Ready to be applied

in the execution of a

real space mission

Full documentation includ-

ing specifications, design

definition, design justifica-

tion, verification & valida-

tion (qualification file), users

and installation manuals and

software problem reports

and non- compliances. In-

cluding also qualification

files, SPR database. Lessons

learnt report.

Requirements traced to mis-

sion requirements. Validity

of solution confirmed within

intended application. Re-

quirements specification

validated by the users.

Building block: Integrated in the

spacecraft/ground segment and

completed successfully system

qualification campaign. Tool:

the tool has been successfully

applied in an operational project

but has not yet been validated

against the in- flight experience

Engineering support

and maintenance or-

ganization in place,

including helpdesk.

Capability for in-orbit

data exploitation and

post flight analysis.

Capabilities.

9 Live product Has been applied in

the execution of a

real space mission

In addition to TRL 8 Up-

dates to documentation and

qualification file

SPR database

Lessons learnt report Track

record of application in

space projects

Building block: Maintained

Tools: Full process imple-

mented, Maintenance, up-

dates, etc.

Building block: fully validated

for the mission and qualified for

intended range of applicability.

Tool: the tool has been success-

fully validated in one or several

space missions, including ex-

ploitation of in-orbit data. All

anomalies encountered have

been analysed and resolved.

Sustaining engineering,

including maintenance

and upgrades in place

Table 7. Detailed description of TRL scale for software production at ESA

Page 64


TRL questionnaire

In this paragraph a questionnaire for TRL assessment&monitoring is proposed. A list of questions is provided to help the partners check/address the specific TRL planned for the exploitation result. It is here suggested that all questions shall have positive response for the specific TRL be checked as satisfied.

TRL Questions Y/N Comments

1 Basic principles observed

Has a reasonable software concept been proposed? ☐

Have mathematical formulations of concepts been developed? ☐

Do rough calculations support the concept? ☐

Do computing platforms support the software implementation? ☐

2 Technology concept formulated

Have functional requirements been determined? ☐

Have results of analytical studies been reported in peer- reviewed papers? ☐

Have the basic components of the technology been identified and partially

characterized? ☐

Have performance predictions been documented for each component? ☐

Has preliminary qualitative risk analysis been documented? ☐

Have analytical studies verified performance predictions and produced

algorithms? ☐

3 Experimental proof of concept

Are the technology or system performance metrics established? ☐

Does published research provide evidence for successful integration of

technology and system components? ☐

Have scaling studies been initiated? ☐

Have technology or system performance characteristics been confirmed

and documented with representative data sets? ☐

Has analysis of alternatives been completed? ☐

Have programmatic risks been identified and mitigation strategies been

documented? ☐

4 Technology validated in lab

Have system requirements been finalized and documented? ☐

Have design requirements been derived from system requirements? ☐

Have system performance metrics been updated? ☐

Have scalable technology prototypes been produced? ☐

Has the performance of components been demonstrated at lab-scale? ☐

Does process simulation verify feasibility of the process at full scale? ☐

Has a formal risk management program been initiated and integrated with

project management? ☐

Are most system components available? ☐

5 Technology validated in relevant environment

Have system interface (internal and external) requirements been docu-

mented? ☐

Does the software operate under realistic conditions? ☐

Have individual software components been verified and validated through

testing? ☐

Page 65


Has a configuration management plan been documented and implement-

ed? ☐

Has formal review of all documentation been completed? ☐

Is user support in place? ☐

6 Technology demonstrated in relevant environment

Have system integration issues been addressed? ☐

Is the operational environment fully known and documented? ☐

Have performance characteristics been verified and validated in a simulat-

ed operational environment? ☐

Has prototype been tested in real operating environment? ☐

Has engineering feasibility been fully demonstrated? ☐

Has system requirements specification document been completed? ☐

7 System prototype demonstration in operational environment

Has software components been tested individually under stressed and

anomalous conditions? ☐

Do prototypes represent actual form, fit, and function? ☐

Has the engineering and maintenance support been organized and in

place? ☐

8 System complete and qualified

Are all technology/system components form, fit, and function compatible? ☐

Is technology/system form, fit, and function compatible with operational

environment? ☐

Has technology/system form, fit, and function been demonstrated in oper-

ational environment? ☐

Have final architecture diagrams been completed? ☐

Have software algorithms been verified and validated with existing sys-

tems? ☐

Is maintenance documentation completed and under configuration con-

trol? ☐

9 Actual system proven in operational environment

Does technology/system function as defined in Operational Concept doc-

ument? ☐

Has technology/system been deployed in intended operational environ-

ment? ☐

Has technology/system been fully demonstrated? ☐

Has Operational Test and Evaluation (OT&E) been successfully complet-

ed and documented? ☐

Have design to cost (DTC) goals been met? ☐

Have safety/adverse effects issues been identified and mitigated? ☐

Has all programmatic documentation been completed? ☐

Table 8. Tee TRL questionnaire designed for the HERCULES TRLs

Page 66


TRL Conclusion

The Technology Readiness Assessment has been defined for the exploitation activities of the HERCULES project. It is based upon the Technology Readiness Level (TRL) scale as defined by the Horizon2020 pro-gramme. Since TRL meaning is strictly connected with the technology to develop, a survey on TRAs/TRLs methodologies deployed by major organizations working on technology has been done. Basic TRL definition has been expanded and applied to software development, following procedures used for ESA projects. Finally, a questionnaire has been introduced, to help HERCULES partners assess and monitor the TRL number of their respective exploitation results.

Documents

HERCULES: High-Performance Real-time …hercules2020.eu/wp-content/uploads/2016/04/D6.2_Final...HERCULES final exploitation strategy is based on two main pillars: • Exploitation