Keywords

1 Introduction

Manufacturing companies produce goods in large scale to meet customer requirements and to manage to stay competitive in the market. In this context, they must constantly adopt new computation technologies and develop innovative solutions in their production lines [1]. This constant evolving context increases both plants and product/service’s complexity offered by the companies [2]. Commonly, asset lifecycle is composed by different phases, starting from conception and planning, going through design and engineering, and then construction, validation, verification, and commissioning [3]. Through each one of these phases, it is highly relevant for the vendor and the asset user to clearly identify the development stage of the same. This is even more important while introducing in their solutions technologies belonging to the Industry 4.0 domain (as Cyber-Physical Systems (CPS)), vital for the constant development of the manufacturers production systems [4]. The development phase can be empowered by the adoption of Model-Based Design (MBD) approaches to which each company can have access to, depending on their level of expertise, flanked by related tailored tools [5]. Small and Medium Enterprises (SMEs) face several barriers when adopting digitalization [6]. Some of the areas where these barriers are most challenging are in the adoption of model-based driven models and tools (MBD assets) [7]. SMEs usually lack of expertise in the implementation of MBD assets due to the high investment costs that they imply (e.g., licensing, development, training, etc.). To encourage the technological transformation, ease the utilization of MBD and address cross-cutting challenges along European SMEs, the HUBCAP (Digital Innovation HUBs and CollAborative Platform for cyber-physical systems) project was funded by the European Commission (EC) under the Smart Anything Everywhere initiative. The objective of HUBCAP is to provide a one-stop-shop for European SMEs that intend to adopt CPS through MBD assets (through different techniques assimulation, model checking, contract-based analysis, model-based safety assessment). The project wants to create a growing and sustainable network where SMEs can undertake experiments, seek investment, access expertise and training, and network with other companies and institutions with support of specialized DIHs. In this perspective, the awareness on the level of development of the tools deployed in the platform becomes highly important for both users and asset providers. For the users, it represents more complete and accurate information to better understand the suitability of the tool to their specific purposes and applications. On the other hand, the asset providers have to be aware on the next steps of development they should follow to offer a complete product in the platform. To this aim, the well-known and consolidated Technology Readiness Level (TRL) models coming from NASA [8], and its modified EC [9] version, were considered. Due to the need to adapt these standards to the main assets of the HUBCAP platform, i.e. MBD tools, the aim of this paper is to present and propose the TRL template developed in the HUBCAP project to support the uploading, updating, and control of the methods and tools added to the collaborative platform by the solution providers. The template can play a key role in supporting the lifecycle management of manufacturers’ assets, fostering the exploitation of the related data and knowledge since the development phase of the CPS technologies employed. The paper is structured as follows. Section 2 presents the TRL standards. Section 3 shows the research methodology needed to develop such an adaptation of TRL standards to the MBD domain (shown in Sect. 4). Section 5 provides concluding remarks.

2 The Research Context: Technology Readiness Level

The metric of TRL was defined as a relevant parameter to be included in HUBCAP with the intention to give its users and stakeholders a better understanding of the level of development of the MBD assets offered on the platform. More specifically, it is intended to be implemented in the tools offered as are the digital assets for which its level of development can be valutated.In the context of NASA [8], the model was conceived in 1974 with 7 levels intended to assess the level of maturity of technologies to be utilized in a specific field, space missions. In 1990, the model gained recognition and was extended to 9 levels, beings broadly utilized in NASA [10], including relevant parameters for NASA technologies such as (i) test and demonstration, and (ii) proven operation. In 1995, [8] offered a more detailed definition to each level and from this year until 2006, the model gained recognition internationally. Based on the white paper published by NASA to define the TRL metric, the model can be adapted to different environments as long as five main steps of the development process of the application are always considered [8]: 1. “Basic” Research in the technology or concept, 2. Focused technology development addressing specific technologies or concepts for an application, 3. Technological development of the application, 4. System development, 5. System “launch”. With time, TRL gained recognition in other fields of different countries and industries being utilized in some cases as-is, while in others it has been adapted to meet specific requirements [11]. The European Space Agency (ESA) was one of the firsts in implementing the TRL model as-is but adding some additional levels with additional standards [12]. Also the Department of Energy (DoE) implemented the nine level model with small variations in the initial and in the last levels [13]. The last level of the DoE’s TRL specifies that the technology must be proven in a “full range” of spected conditions. In other cases, the TRL was modified to assess readiness of not only technology, but the process of incremental innovation. In [14], the Innovation Readiness Level is defined. In the manufacturing industry, this metric gained high levels of attention, until being specifically addressed by the EC who proposed a new version in the context of EU Horizon programs with some slight differences from the original one from NASA [9]. Table 1 shows the two models and their main differences in each of the 9 steps.

Table 1. TRL models proposed by NASA and European Commission
Full size table

In the EU Horizon programs context [9], the TRLs were defined with the intention to narrow down the topics of the H2020. Additionally, the definition of this metric, gives an idea on the next steps that the project must follow and an initial iteration on the distance of the technology from the market. In the context of HUBCAP, the definition of the TRLs became vital since it can support stakeholders to define the current development step of the tool in discussion, identify its possible benefits and limitations, and give a broad idea on the further steps that it will have.

3 Research Method

In this section, the process of development of a TRL template adapted for HUBCAP’s MBD assets is described, based on the initial NASA [8] and EC [9] models. The research process is composed by 5 main steps (Fig. 1):

Fig. 1.
figure 1

TRL adaptation process for HUBCAP context

Full size image
  1. 1.

    the conceptualization of the HUBCAP TRL template was done starting from the NASA and EC versions, adding three parameters to each level of the template (a. considerations in the stage and some examples, b. what question should the tool provider answer, c. expected output documentation that justifies the selected TRL).

  2. 2.

    To perform additional activities to verify the suitability of the TRL with the MBD assets provided in HUBCAP, a workshop to receive feedback about the template concept was conducted involving MBD experts belonging to the HUBCAP project.

  3. 3.

    The feedback gathered from the workshop with the experts involved can be wrapped up in Table 2 reporting the relevant points of improvement:

Table 2. Feedback gathered from meetings and countermeasures for HUBCAP TRL
Full size table
  1. 4.

    A further workshop was done to explain the MBD TRL template to the SMEs providing MBD assets on the HUBCAP platform (the users of the TRL template). Some additional corrections (description and levels of specifications) were gathered.

  2. 5.

    The new feedback were implemented first in the template itself and then in the platform on which it had to be embedded.

4 Results: TRL Template for MBD Methods and Tools

The MBD TRL proposed is structured in 9 levels, classified in three main phases, as the traditional one. Phase 1 (MBD asset concept definition (levels from 1 to 4) focuses on the definition of the tool concept and its validation.Phase 2 (MBD asset concept validation and test (levels from 5 to 8)) focuses on piloting activities and demonstration. Phase 3 (MBD asset deployment (level 9)) is reached after the last “bug fixing” aspects. Table 3 specifies the name of the level, the development action taken (i.e. the steps that the MBD tool provider have taken in order to reach the TRL), what to consider in this stage and examples (in this column is mentioned the main thing to consider when evaluating the tool under the TRL including also an example to guide the provider), question for tool provider (i.e. a question for the provider to assess TRL), output (possible outputs that the provider should have when the TRL is reached).

5 Discussion

The adoption of the MBD TRL template defined for HUBCAP brought successful results as each provider was able to better define their current level of development, provide a short description of the asset state of development, and additionally, generate further documentation that can be accessed and exploited by their stakeholders. However, since the TRL template is a new platform feature, not all the MBD asset providers have been able to offer a complete documentation of their current TRL yet. From the experience that each asset provider had in the definition of the asset TRL, the time required to perform the assessment depends on the availability of information that they actually had internally. In most of the cases the tool providers were able to identify their TRL but were not able to offer the right documentation that justifies their selection. For this reason, additional time were required by them to develop the new documentation required. For the asset providers that had available the documentation, the time required for the assessment varied depending on the completeness of the information that each MBD asset provider has available.

Table 3. MBD TRL template
Full size table

The providers that had complete information that justifies the TRL of their tool required approximately 1 h to identify and justify it in the platform. The providers that did not have available documentation in regard to their TRL required additional time, this due to the fact that they needed to prepare from scratch the documentation to justify it.

Fig. 2.
figure 2

TRL section for HUBCAP tool

Full size image

To better support the adoption and implementation of the TRL template in the HUBCAP platform, additional input boxes for each one of the assets available were added. In this way, the TRL defined by the asset provider can be found by the platform users while they access the asset webpage in the catalog on the platform (Fig. 2). As the process is still in an early stage of adoption in the platform, most of it must be done manually by the MBD asset provider, implying possible human errors and further revisions on the quality of the TRL assessments.

6 Conclusions

This paper presented a new TRL template for updating and controlling MBD methods and tools of a collaborative platform. This new template can be considered an improvement and adaptation to the MBD domain of the EC and NASA TRL standards. After the implementation of the tool, new feedback from the tool providers were gathered.

  1. 1.

    inclusion of additional details for the documents to be uploaded into the platform: at the moment, the format is not specified as it can highly vary from company to company (it is needed a list of types of verification documents that can be utilized in the various stages of the TRL or a standardized document template that asset providers will feed with the information related to their tools and methods).

  2. 2.

    inclusion of the verification of TRL definition in the Quality Assurance process, currently being designed for the HUBCAP platform (due to the fact that even when specifications regarding the TRL proving documents were given in the template, some users did not comply with them, triggering a manual verification).

  3. 3.

    exploration of the feasibility of the template extension to additional TRLs to consider additional phases of the MBD assets’ life cycle.

In addition to the previous improvements to be done in the current implementation of the TRL template, some weaknesses are identified in the paper. Currently, the verification of the correct implementation has been done in some of the assets currently offered in the platform (13 of 49). The model must still be applied to all the tools added on the HUBCAP platform to further verify its applicability. Furthermore, improvements are intended to be implemented to the platform with the intention to make easier the assessment and verification of the assets’ TRL, intended to be executed by the HUBCAP platform providers. Nevertheless, additional effort will be done to address the sustainability of the TRL definition process and the verification procedure.