<figure><img src="image_1.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Developing a Technology Readiness Level Template for Model-Based Design Methods and Tools in a Collaborative Environment

Roman F. Bastidas Santacruz<fnref n="1" />, Brendan P. Sullivan<fnref n="1" /> ID, Sergio Terzi<fnref n="1" /> ID,
and Claudio Sassanelli<fnref n="2" />(✉) ID

**Abstract.** Currently, companies in the manufacturing field are experiencing the need to go digital, compelled by rising competitiveness and efficiency requirements. Digitalization implies the development and implementation of complex systems in manufacturing plants as well as in the delivery of product-service systems and solutions, asking both for the adoption of Model Based Design (MBD) tools and methods. In this context, the assessment of suitability of MBD tools is vital for the companies that try to digitalise their operations. Due to the high relevance that this characteristic has for users and providers, a vital part of the implementation process is assessing the level of development or maturity of the tools. This paper presents and proposes a Technology Readiness Level (TRL) template developed in the HUBCAP project. This template aims to support MBD tools providers (guiding them in the description of the tool added on the platform), the platform management (easing governance tasks) and its users (clarifying the tool description for them) along the upload, update and control processes of the MBD tools in the collaborative platform.

**Keywords:** Technology readiness level · Model-based design · Cyber-physical system · Collaboration platform · Digital innovation hub

## 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,

<footnote n="1">¹ Department of Management, Economics and Industrial Engineering, Politecnico di Milano,
Piazza Leonardo da Vinci 32, 20133 Milan, Italy</footnote>

<footnote>{romanfelipe.bastidas,brendan.sullivan,sergio.terzi}@polimi.it</footnote>

<footnote n="2">² Department of Mechanics, Mathematics and Management, Politecnico di Bari, Via Orabona 4,
70125 Bari, Italy</footnote>

<footnote>claudio.sassanelli@poliba.it</footnote>
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 bar-
riers 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 Innova-
tion 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 HUB-
CAP 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 specified 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><caption>**Table 1.** TRL models proposed by NASA and European Commission</caption><thead><tr><td>TRL</td><td>NASA</td><td>EU</td></tr></thead><tbody><tr><td>1</td><td>Basic principles observed and reported</td><td>Basic principles observed</td></tr><tr><td>2</td><td>Technology concept and/or application formulated</td><td>Technology concept formulated</td></tr><tr><td>3</td><td>Analytical and experimental critical function and/or characteristic proof-of-concept</td><td>Experimental proof of concept</td></tr></tbody></table>

(continued)
<table><caption>**Table 1.** (continued)</caption><thead><tr><td>TRL</td><td>NASA</td><td>EU</td></tr></thead><tbody><tr><td>4</td><td>Component and breadboard validation in laboratory environment</td><td>Technology validated in laboratory</td></tr><tr><td>5</td><td>Component and/or breadboard validation in relevant environment</td><td>Technology validated in relevant environment (industrially relevant environment in the case of key enabling technologies)</td></tr><tr><td>6</td><td>System/subsystem model or prototype demonstration in a relevant environment (ground or space)</td><td>Technology demonstrated in relevant environment (industrially relevant environment in the case of key enabling technologies)</td></tr><tr><td>7</td><td>System prototype demonstration in a space environment</td><td>System prototype demonstration in operational environment</td></tr><tr><td>8</td><td>Actual system completed and “flight qualified” through test and demonstration (ground or space)</td><td>System complete and qualified</td></tr><tr><td>9</td><td>Actual system “flight proven” through successful mission operations</td><td>Actual system proven in operational environment (competitive manufacturing in the case of key enabling technologies or in space)</td></tr></tbody></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):
<figure><img src="image_2.png" /><figcaption>Fig. 1. TRL adaptation process for HUBCAP context</figcaption></figure>

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. 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. The feedback gathered from the workshop with the experts involved can be wrapped up in Table 2 reporting the relevant points of improvement:

<table><caption>Table 2. Feedback gathered from meetings and countermeasures for HUBCAP TRL</caption><thead><tr><td>N</td><td>Feedback gathered during meetings</td><td>Countermeasure</td></tr></thead><tbody><tr><td>1</td><td>Inclusion of output for each level of the TRL was requested by the partners. It is highly relevance as the platform counts with</td><td>The output for each TRL level was defined as an additional parameter to the TRL model. Nevertheless, as it can have high variations from one provider to another, it was defined as a general output</td></tr><tr><td>2</td><td>Corrections and clarifications of the definitions of each level. More specifically</td><td>The column “Development actions taken” were expanded to clarify them and make it clearer each TRL level to the tool providers</td></tr><tr><td>3</td><td>The level 9 could lead to misunderstandings as it was not clear what is the last level of development that a technology can have</td><td>The level 9 was better defined and the context of the HUBCAP tools better explained. It was specified that the last level of the HUBCAP TRL model is reached when a tool is for first time successfully deployed in a real application for a customer</td></tr></tbody></table>

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.

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.

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.
<table><caption>**Table 3.** MBD TRL template</caption><thead><tr><th>Phase</th><th>TRL</th><th>Development stages</th><th>Development action taken</th><th>What to consider in this stage and examples</th><th>What question should the tool provider answer?</th><th>Output</th></tr></thead><tbody><tr><td rowspan="2">Phase 1: Tool concept research and validation</td><td>1</td><td>Basic principles observed and reported</td><td>Scientific research translated into applied research and development. Most relevant topics related with the tool end goal were investigated and applied to the tool methodology. This includes physical principles or basic topics over which the intended tool will be built on</td><td>The basic principles of the tool are researched. Ex: The analysis of the different types of the battery control methodologies</td><td>[Is the tool basic principle already researched?]</td><td><ul><li>Documents about basic physical principles or basic topics over which the intended tool will be built on</li><li>Further information about how scientific research (with related references) has been translated into applied research and development</li></ul></td></tr><tr><td>2</td><td>Tool concept and/or tool formulation</td><td>The tool is discussed and defined around the basic principles defined in the previous level. The previous topics converge in the definition of the tool objective, being merely speculative: without experimental proof or detailed analysis that supports the conjecture</td><td>Practical applications of the basic principles are invented or identified. Ex: the potential application of a certain control methodology is explored, like its utilization for electric trucks</td><td>[The applicability of the basic principles has been proposed?]</td><td><ul><li>Document reporting the tool objective connected with the physical principles and basic topics found in the previous stage</li></ul></td></tr></tbody></table>

(continued)
<table><caption>**Table 3.** (continued)</caption><thead><tr><th>Phase</th><th>TRL</th><th>Development stages</th><th>Development action taken</th><th>What to consider in this stage and examples</th><th>What question should the tool provider answer?</th><th>Output</th></tr></thead><tbody><tr><td></td><td>3</td><td>Analytical and experimental critical function and/or characteristic proof of concept</td><td>Active R&D starts. Starting from the basic principles investigated and the definition of the tool, an appropriate context of the tools is defined, and studies are performed to validate that the analytical predictions are correct. This is translated into a "Proof of concept" of the tool concept</td><td>A proof of the concept over which the tool is built had been developed. Ex: If the tool is based on the implementation of a battery management system (BMS) for electric trucks, then this stage is achieved when it has been theoretically proven or modelled that the theoretical model behind the tool is feasible for the application. Ex.: the theory behind the battery control has been proved</td><td>[Is the theory behind the tool and the application already theoretically proven for this type of applications?]</td><td><ul><li>Proof of concept of the tool</li><li>Document reporting the validation of the concept of the tool (feasibility analysis of tool/model)</li><li>Document reporting requirements of potential real applications of the tool</li></ul></td></tr><tr><td></td><td>4</td><td>Tool concept validation in laboratory digital environment</td><td>A validation in a digital environment must support the concept formulated in the previous step being consistent with the requirements of potential real applications</td><td>This validation can be done in a digital environment without considering all variables as in real application cases. Ex.: Testing the tool with a virtual battery for a vehicle or truck</td><td>[Is the Tool already tested in a digital environment proving that it is feasible to be applied?]</td><td><ul><li>Report of the validation conducted in a digital environment</li></ul></td></tr></tbody></table>

(continued)
<table><caption>**Table 3. (continued)**</caption><thead><tr><th>Phase</th><th>TRL</th><th>Development stages</th><th>Development action taken</th><th>What to consider in this stage and examples</th><th>What question should the tool provider answer?</th><th>Output</th></tr></thead><tbody><tr><td rowspan="2">Phase 2: Tool pilot line and demonstration projects</td><td>5</td><td>Tool concept validation in relevant environment</td><td>The basic tool elements must be integrated with reasonably realistic environments. The demonstration might represent an actual system application, or it might be similar to the planned application, but using the same technologies</td><td>The validation in this stage must be done by implementing the tool in a similar environment than the application case. Ex.: Testing the model for a truck battery control with a real truck or a similar vehicle</td><td>[Is the tool already tested and its results were taken to a similar environment to the real environment?]</td><td><ul><li>Tool prototype (Tool concept validated)</li><li>Report of the validation of the tool concept in a relevant environment, showing conformity with the requirements previously defined</li></ul></td></tr><tr><td>6</td><td>Tool prototype demonstration in a relevant environment</td><td>A model or prototype system would be tested in a relevant environment. At this level, considering the NASA definition, if the only “relevant environment” is the space, then the model/prototype must be demonstrated in space. The demonstration might represent an actual system application, or it might only be similar to the planned application but using the same technologies. At this level, several-to-many new technologies might be integrated into the demonstration</td><td>In this stage all the variables of the application are considered. Ex: In this stage, not only the model behind the tool must be tested, but also including additional variables such as movement, time, etc. which could affect the model of the tool</td><td>[The previous test had been performed including external environment variables?]</td><td><ul><li>Report of the demonstration of the tool prototype in a relevant environment considering additional variables of the application</li><li>Validation of integrability with new technologies</li></ul></td></tr></tbody></table>

(continued)
<table><caption>**Table 3.** (continued)</caption><thead><tr><th>Phase</th><th>TRL</th><th>Development stages</th><th>Development action taken</th><th>What to consider in this stage and examples</th><th>What question should the tool provider answer?</th><th>Output</th></tr></thead><tbody><tr><td></td><td>7</td><td>Tool system prototype demonstration in an operation environment</td><td>This TRL is not always implemented. In this case, the prototype should be near or at the scale of the planned operational system and the demonstration must take place in the specific conditions of the real operational environment of the tool. The driving purposes for achieving this level of maturity are to assure system engineering and development management confidence (more than for purposes of technology R&D). Therefore, the demonstration must be of a prototype of that application. Not all technologies in all systems will go to this level. TRL 7 would normally only be performed in cases where the tool and/or subsystem application is mission critical and relatively high risk</td><td>This stage is important in case that the tool is related with safety or critical risks for the customer company. Ex.: If the battery control system includes the modelling of the support of security systems in the truck, the experiment must be performed including all the variables that can influence this</td><td>[In case the tool has critical risk or security concerns, it has been tested in a real environment with the variables that affect these risks?]</td><td><ul><li>Tool system prototype (Proven in risk environments)</li><li>Document reporting the demonstration of the tool/system prototype in an operational environment granting that critical risks and security concerns had been considered</li></ul></td></tr></tbody></table>

(continued)
<table><caption>**Table 3.** (continued)</caption><thead><tr><th>Phase</th><th>TRL</th><th>Development stages</th><th>Development action taken</th><th>What to consider in this stage and examples</th><th>What question should the tool provider answer?</th><th>Output</th></tr></thead><tbody><tr><td></td><td>8</td><td>Actual tool system completed with a test made in an environment similar to potential customer applications</td><td>In this stage, the tool had been already tested in applications alike to the customer applications. In other words, the tool has been tested in a situation or application similar to the one that the potential customers would have</td><td>The tool has to be tested in a real environment. Ex.: Tested in a set of truck batteries</td><td>[Is the tool already tested in a real environment as the ones that customers would use it on?]</td><td><ul><li>Functional tool</li><li>Document reporting the test made in a similar environment to the one that the potential customers would have</li></ul></td></tr><tr><td>Phase 3: Tool (initial) deployment</td><td>9</td><td>Actual tool system proven to have successful application for customer needs</td><td>All the tools that are being implemented by companies are in TRL 9. This stage is reached after the end of the last "bug fixing" aspects of the tool development</td><td>The tool had been successfully implemented in real environments. Ex: The tool for battery control simulation had been tested in the application of an electric truck of a company with successful results in meeting customer needs</td><td>[Is the tool already proven with customers and showed that it successfully meets their requirements?]</td><td><ul><li>Report of tool deployment in a customer application environment</li></ul></td></tr></tbody></table>

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** TRL section for HUBCAP tool</figcaption></figure>
To better support the adoption and implementation of the TRL template in the HUB-CAP 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. 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. 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. 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.

# References

1. Stasiak-Betlejewska, E.R., Parv, A.L., Gliń, E.W.: The influence of Industry 4.0 on the enterprise competitiveness. Sciendo 1(1), 641–648 (2018). https://doi.org/10.2478/mape-2018-0081

2. Dalenogare, L.S., Benitez, G.B., Ayala, N.F., Frank, A.G.: The expected contribution of industry 4.0 technologies for industrial performance. Int. J. Prod. Econ. 204, 383–394 (2018). https://doi.org/10.1016/J.IJPE.2018.08.019
3. Stark, J.: Product Lifecycle Management, 2nd edn. Springer, London (2011). https://doi.org/10.1007/978-0-85729-546-0_16

4. Rüßmann, M., et al.: Industry 4.0: the future of productivity and growth in manufacturing industries (2015). https://doi.org/10.1007/s12599-014-0334-4

5. Jensen, J.C., Chang, D.H. Lee, E.A.: A model-based design methodology for cyber-physical systems. In: IWCMC 2011 - 7th International Wireless Communications and Mobile Computing Conference, pp. 1666–1671 (2011). https://doi.org/10.1109/IWCMC.2011.5982785

6. Sassanelli, C., Panetto, H., Guedria, W., Terzi, S., Doumeingts, G.: Towards a reference model for configuring services portfolio of digital innovation hubs: the ETBSD model. In: Camarinha-Matos, L.M., Afsarmanesh, H., Ortiz, A. (eds.) PRO-VE 2020. IAICT, vol. 598, pp. 597–607. Springer, Cham (2020). https://doi.org/10.1007/978-3-030-62412-5_49

7. Lachiewicz, S., Matejun, M., Pietras, P., Szczepańczyk, M.: Servitization as a concept for managing the development of small and medium-sized enterprises. Management **22**(2), 80–94 (2018). https://doi.org/10.2478/manment-2018-0024

8. Mankins, J. C.: Technology readiness levels: a white paper, January 1995 (1995). http://www.hq.nasa.gov/office/codeq/trl/trl

9. Héder, M.: From NASA to EU: the evolution of the TRL scale in public sector innovation. Innov. J. **22**(2), 1–23 (2017)

10. Banke, J.: NASA, technology readiness levels demystified (2010)

11. Mankins, J.C.: Technology readiness assessments: a retrospective. Acta Astronaut. **65**(9–10), 1216–1223 (2009). https://doi.org/10.1016/J.ACTAASTRO.2009.03.058

12. Tec-shs, technology readiness levels handbook for space applications. European space agency (ESA) (2008)

13. U.S. Department of energy, technology readiness assessment guide (2009)

14. Lee, M.-C., Chang, T., Chien, W.-T.C.: An approach for developing concept of innovation readiness levels. Int. J. Manag. Inf. Technol. **3**(2), 18–37 (2011). https://doi.org/10.5121/ijmit.2011.3203