Structuring the Technology Landscape for Successful Innovation in AIoT

Abstract

The InSecTT consortium started with a ground-breaking vision: to combine IoT and AI, or in short: AI + IoT = AIoT. But how can research and development in such a large project with many partners be structured and managed to lead to successful innovations? Especially in such a highly competitive market of digital solutions? This section provides an overview of processes and methods, from requirement engineering, followed by technology structuring, leading into joined development of re-usable technical building blocks. To validate and proof the approach, these technologies were integrated into a wide range of demonstrators in many different industrial domains. An iterative approach allowed to learn and improve along that way. Additional measures like use case marketplaces allowed to identify and exploit synergies. Finally, measures to support the exploitation of results are introduced.

1 Motivation

Digitalization has entered our lives in many subtle, and not so subtle ways. Many of us got used to witness one technology revolution after another. Incredible wealth, at least measured by stock value, has been created in comparatively short time by companies in the IT domain, most prominently those called Big Tech.

Digital computers have gone a long way, from huge mainframes filling data centres to personal workstations, and can now be found as smartphones in our pockets and even close and in our bodies as wearables. But the real breakthrough came by combining those approaches. Linking powerful computing centres (now called cloud) with personal devices and local smart devices, embedded in everyday objects, via network of networks, opened plenty opportunities for digitization. Something we have started to call the Internet of Things (IoT), joining locality and interaction in the physical world we live in, with digital services across layers unlocked the virtual world.

But how is this digital world built? Similarly to digitization itself, engineering digital systems has seen (and still experiences) its fair share of fast-paced revolutions. For a long time, computing paradigms have been governed by the von-Neumann architecture, and software was mostly developed by legions of human programmers, explicitly writing down the desired behaviour using some of a wide variety of computer languages. After decades of research and development, it appears that this paradigm is to change, or at least it is joined by an alternative way: having the computer to learn (and at some time, to reason) what we expect it to do. Branded as AI, with ML being arguably the most well-known subset, we start seeing real progress in real-world problems, like object detection, speech recognition or automation of simple administrative tasks.

The InSecTT consortium was established in 2019 with a ground-breaking vision to combine these two approaches: IoT and AI, or in short: AI + IoT = AIoT. Also considering aspects of security will finally ensure that the AIoT will be resilient and trustworthy and thus accepted by users.

2 How to Structure Research and Development to Enact an Ambitious Project Vision

With the two base ingredients, IoT and AI, being already such huge fields of technologies, the question came up quite early during the conception of the InSecTT project. It became even more relevant when planning and implementing the concrete work: how to structure these fields?

Structure is needed for several reasons: (i) to capture the current state of the art for the fields in scope and identify the gaps, (ii) to formulate research questions and problem descriptions setting objectives for the project, (iii) to identify stakeholders and form teams to handle the tasks efficiently in the consortium, (iv) to identify relevant technology constraints and system boundaries.

Another important aspect comes from the fact that project InSecTT intends to demonstrate all research results by applying into real-world use-cases. InSecTT is designed as an use-case driven, pan-European project, showing solutions in domains like sustainable mobility, smart health, or smart production. This required the consortium to find a structure which is able to detail technology needs and technology results. It allows to link and map technology providers with technology users, to ensure all demonstrators can be implemented to the desired technology readiness level (TRL, for most use cases between 5 and 7) within the planned project duration of 3 years.

The following sections in this chapter describe the approach chosen by the InSecTT consortium to tackle this challenge.

3 Requirements and Constraints

The InSecTT consortium designed the processes and structures used to navigate the technological landscape in scope of the project, and to govern the research and development work spread over multiple work packages and tasks.

While overall project objectives clearly have served as reference and starting point for all technical work in InSecTT, an effective and efficient implementation also had to consider the high number of project partners spread over different countries and cultures, as well as the diversity of addressed domains and related interests, including aspects of IP management and know-how sharing. It needs to be aware of and support the fact that partners follow their individual innovation processes and might have different IP strategies (e.g., open/shared/protected). Given the objective to ensure multi-domain re-use of technical building blocks, a wise balance between re-usability on one hand, and “fit-for-purpose” usage in Use Cases on the other hand had to be found. For the requirements engineering process this means that a top-down approach (Use Cases to define their requirements for components) has been leading, but in parallel and driven by technology experts, bottom-up input has been made to find the best possible balance between both challenges.

4 Requirement Engineering Process

An important part of any engineering endeavour is to understand the requirements and expectations of the application domain in order to drive the design. In order to foster both, deep-dive research combined with applied engineering, the consortium settled on an iterative process, dividing the project runtime into 3 iterations (Y1, Y2 and Y3). While the first iteration was dedicated to classic requirement engineering and first technology evaluations/demonstrations, Y2 and Y3 allowed to integrate new inputs during the project, react to requests from the application domain in a more agile way, and to learn from results of the first generations of demonstrators.

An important decision to make was the intended level of detail, the granularity, of requirements defined in this process. A typical product development process usually needs detailed specification of functional and non-functional requirements, with unambiguous description of each and every aspect (agile processes might accumulate this information over several iterations). In project InSecTT however, the requirements serve primarily as an interface between technology work packages (WP2, WP3) and use cases (WP5), specifying the needs for research and technology development. The consortium therefore decided deliberately to focus on and describe domain- and application specific needs and constraints through the requirement specification, and to define functionalities on a rather high level only.

Each requirement is mapped onto one technology Building Block (BB), and defines clear role responsibilities. A partner of the consortium needs to take on the lead implementer role, and to confirm the requirement as a first step. With these four entities (requesting Use Case, supplying building block, lead implementer, requirement author), all required relations and responsibilities for the life cycle of the requirement were defined.

As requirements are independently created by different use cases, requesting certain technologies from a specific BB, they might address similar but not or only partly congruent aspects. InSecTT uses therefore the requirement harmonization process during this first phase in the project, where requirement creators and technology supplier can negotiate, trying to refine the requirements in a way which optimizes synergies through reuse and interoperability of the to-be-developed BBs.

Finally, the iterative approach towards defining requirements described above also allows a clearly structured change process for requirements.

5 Navigating the Landscape: Planning R&D Work

After setting the vision and defining the mission, followed by a definition of the main use cases by the industrial partners, the main focus of the consortium was on defining the technology landscape and setting up processes and data structures to guide the main work streams in InSecTT. Again, the concept of re-usability on one hand and clear accountability in supporting use cases on the other hand have been the leading principles. From the requirements defined (see above) the consortium derived and further detailed the research and development needed to satisfy these requirements.

Therefore both, methodology as well as execution approach used in InSecTT technical Work Packages, have been defined in a way that (a) is in line with the overall InSecTT implementation framework, (b) enables lean but still efficient WP- and Task management, as well as interaction within the overall InSecTT governance framework, (c) allows partners to mostly focus on content related technical work and cooperation, and (d) provides an unified model between the two technical work packages, in order to foster co-operation and joint innovations.

This unified model has been developed in a cooperative project effort and has led to a three-layer approach as far as the technical work (i.e. the work on the technical Building Blocks) is concerned:

• Layer 1: Building Block (=Task)

This layer reflects the high-level structure as used in the project submission and for managerial and reporting purposes. It is absolutely needed for organizational reasons, but it has been experienced as being too comprehensive and too diverse from a technical perspective to ensure clear ownership on partner level and to facilitate efficient cooperation. As a result, the Sub-BB concept has been developed and introduced in InSecTT.

• Layer 2: Sub-Building Blocks

This layer has been developed as the main layer to organize and manage technical cooperation and alignment, offering the right granularity level for joint development targets and to exploit potential development and exploitation synergies. Also (technical) dependencies have been highlighted mostly on this layer.

• Layer 3: Component

This layer has been introduced to understand, how the different partner level contributions do contribute to certain Sub-BBs and how they feed into the UC integration work. This also ensures clear accountability on partner level. “Component” in this context can mean any contribution, be it hardware (HW), software (SW), methodology, or any combination of them.

Figure 1 highlights how the three layers interact.

Fig. 1

InSecTT layer model and terminology

We see this three-layer model as an appropriate methodology to effectively address the significant size and the high complexity and diversity of a project like InSecTT. The target is to not de-focus partners from their technical work by too much managerial and methodological “overhead”, but to still foster and facilitate cooperation and synergies as much as possible. In addition to the mapping table between use cases and (Sub) Building Blocks it offers an efficient methodology for a project of the size of InSecTT to stay on top of activities, both in terms of technical work and use case integration activities, while still ensuring clear accountability on one hand and facilitating technical cooperation on the other hand.

As an example for the structure described, Fig. 2 depicts the composition of BB 3.5 (Verification, Validation, Accountability) into sub-BB (A..D) and respective components (a..h).

Fig. 2

Structure of BB 3.5 (verification, validation, accountability) into sub-BB (A..D) and respective components (a..h)

The final result of this structuring work provides the complete map of research and development in the technological landscape of AI and IOT. It provides full traceability top-down from the application (the use case) through specified requirements to technology needs, and maps these into building blocks (BB), sub-building-blocks (sub-BB) and components as defined. In the other direction (bottom-up) it allows to align and aggregate activities in the technological fields, with the goal to support re-use and interoperability through compatibility for the components developed.

To facilitate these aspects, all BB and sub-BB were analyzed to identify their relationships (dependencies, input, output). Figure 3 shows Sub-BB 3.1.B (Intrusion detection systems) as an example.

Fig. 3

Relationship analysis on sub-BB level (example: Sub-BB 3.1.B)

Another aspect of planning technical work is to identify if there are any gaps in the landscape designed, in other words if there could be technologies missing, but required for the use cases defined. One way to do this analysis is to map technologies against layers, as shown for example in Fig. 4 (shown for WP2).

Fig. 4

Mapping technologies along layers

6 External Alignment

Along with the structuring and mapping done within project InSecTT it is certainly beneficial to align with external architectural models and research agendas. Highly relevant is the Electronic Components & Systems (ECS) Strategic Research and Innovation Agenda (SRIA) released by the three Industry Associations AENEAS, EpoSS, and Inside, under the joined umbrella of the KDT JU (Key Digital Technologies Joint Undertaking) (since end of 2023 called Chips JU). A more detailed discussion and analysis of the technologies and mappings can be found in chapter “Reference architecture for AIoT systems”.

Even a large assembly of experts like the InSecTT consortium can benefit from additional expertise from outside. This is why during the first two years several liaisons were established between InSecTT and other European research projects running in parallel:

• ERATOSTHENES, IoT Trust and Identity Management Framework, funded under H2020-EU.3.7.4. (Liaison established 2021)

• DAIS, Distributed Artificial Intelligent System, a KDT JU project (liaison established 2022)​

• ANIARA, Automation of Network edge Infrastructure and Applications with aRtificiAl intelligence, an EU flagship project, focusing on edge cloud (liaison established 2022).

7 Documenting Scope, Work and Results

An important aspect of research is to communicate its existence, its progress and especially its results to the intended target groups. Naturally, this faces challenges like (i) efficient soliciting and collecting information in a large and heterogeneous team of a cross-European project, (ii) finding suitable channels for communication, and (iii) processing and transforming information to draw the interest of target groups, while honouring the interests and potential confidentially aspects of project partners. InSecTT is set up so that most dissemination and exploitation is done directly by the partners. However, a dedicated task (T6.1, Dissemination and Exploitation) was established to support such activities, by creating opportunities, networking, counselling partners etc.

InSecTT has been designed in a way that motivates broad exploitation of the work done in the technical Work Packages (WP2 and WP3), beyond the integration into the InSecTT use cases (WP5). Progress of the technical work was reported annually, highlighting progress beyond state-of-the-art and planned exploitation activities. Two public deliverables at the end of the project, summarizing technological step-ups achieved in WP2 and WP3 support broad dissemination of results.

Each use case is represented by a task in WP5, forming T5.1 through T5.16.

A dedicated work package WP4 (Cross-domain use case coordination) supports identifying and exploiting synergies between use cases, and provides uniform means of documentation and reporting like the Use Case Booklet (https://www.insectt.eu/download/d4-4-insectt-industrial-use-case-booklet/).

Another example for unifying use case management is the common deliverable (‘D’) structure and release schedule all use case have to follow:

• D5.1-5.16 Use Case specification (M6)

• D5.17-5.32 Use Case progress report Y1 (M11)

• D5.33 InSecTT industrial demonstrators Y1 (aggregates all use cases, M12)

• D5.34 Use Case specification update (aggregates all use cases, M18)

• D5.35-5.50 Use Case progress report Y2 (M23)

• D5.51 InSecTT industrial demonstrators Y2 (aggregates all use cases, M24)

• D5.55-5.71 Use Case progress report Y3 (M36)

• D5.72 InSecTT final demonstrators (aggregates all use cases, M36).

8 Progress Assessment and Validation

InSecTT is a use-case centred project. As a result, research work and development of technologies are guided by the needs specified in the use cases. Structuring, managing and monitoring of work is important, especially in a large, distributed team of a large consortium.

R&D results are supposed the fill the gaps (as identified by the use cases) in the technological landscape. But how can the consortium, and in general any stakeholder, validate that the results really fit the landscape as intended? How can we evaluate progress of work, as well as its practical use?

Project InSecTT uses requirement-based progress assessment. The status (definition, confirmation, grade of implementation) of each requirement is individually assessed by the requirement owner (typically the stakeholder who defined the requirement). This is done as a coordinated effort in the whole project in three assessment time windows throughout the three years of the project. As all requirements are managed in a SharePoint repository, so can the assessment be done interactively in SharePoint as well. Each requirement has a state, see Fig. 5.

Fig. 5

A mandatory attribute of each requirement is its state

The fine granular progress assessment is done by the owner of the requirement. This person has to provide a number (0..100%) as progress estimation on technical level. As a pragmatic guideline, the following definitions are suggested:

• 40% … Implemented on BB level to small extent

• 70% … Implemented on BB level to large extent

• 100% … Fully implemented on BB level.

One number per requirement can be easily used to summarize and report, but obviously is quite a generalization and might aggregate too many aspects. This is why each assessment can be accompanied by a short, written comment (free text), to explain the rational or describe the context.

Results are used to manage and monitor work on individual requirements level, as well as on BB level and on UC level, see Fig. 6.

Fig. 6

Evaluation of requirement assessments on BB and on UC level

9 Demonstrators

Demonstrators are a major pilar of InSecTT. Typically, demonstrators integrate implementations of research results from one or more partners in a prototypical way, and evaluate it in the intended context (TRL 6: Technology demonstrated in relevant environment; TRL 7: System prototype demonstration in operational environment). Demonstrators therefore serve as inevitable check point for the partners involved. But there is more: demonstrators are also used to prepare markets as well as stakeholders like potential users and customers. Project InSecTT is structured in three distinct 12 months long iterations, having partners providing at least yearly generations of demonstrators. Demonstrators can be on UC (primary) or BB level (secondary), see also Fig. 7. Besides used as checkpoint and for validating the results, demonstrators are also used to introduce and present technologies, to foster generating new ideas and therefore opening (additional) paths of exploitation, e.g. at the Use Case Marketplace (Fig. 8).

Fig. 7

Primary and secondary paths of exploiting research results; TBB denotes “technical” BB

Fig. 8

UC Marketplace at the F2F Meeting in Gdansk, Poland (2022-06-13)

10 Preparing for Market: Exploitation

The explicit goal of all research and development done in this project is to apply its results towards progressing European commercial success and to raise the quality of living, especially regarding safety and security, for Europe’s citizens, and in general to benefit humankind.

All partners in the InSecTT consortium, strongly encouraged by the EC and national funding agencies as providers of the funding, therefore focus on supporting exploitation of results. This is supported in the project by a portfolio of activities, with some described below.

Groundwork has been laid already during writing the proposal for the project. After analysing the current level of technologies and applications and from that identifying the gaps, which led to the definition of InSecTT’s vision AI + IOT = AIOT, partners have specified concrete industrial use cases in WP5, applying the technologies developed in WP2 and WP3. These use cases have been developed from the domain knowledge of the industrial partners in the consortium and are supported by analysis of market needs. As a result, in total 16 use cases have been described, and embody the primary way of commercialization of project results.

Use cases demonstrate technologies in the context of the “real world”, typically at technical readiness levels of TRL 6 and above. The proposal writing stage also included a brief overview of market and exploitation strategies of the industrial partners to ensure it will match.

The second path towards commercialization is on the level of technical building blocks (TBB’s) derived from the BBs developed in WP2 and WP3. While the UC path typically defines markets and their access, exploitation on TBB level can be more open regarding target markets. This is both opportunity and challenge, which is why project InSecTT has set up the Exploitation Board, and organizes activities like an internal Open Innovation Contest (OIC 2022, Fig. 10) and Use Case marketplace (see Fig. 8). An overview depicting these paths of exploitation is shown in Figs. 7 and 9.

Fig. 9

Open innovation (inspired by Chesbrough (2003b): the era of open innovation. MIT Sloan management review, 2003)

Fig. 10

Trophies from the internal open innovation contest (Gdansk 2022)

11 InSecTT Exploitation Board (EB)

In order to further foster exploitation, and to support all partners, especially SME’s, in the consortium, the InSecTT Exploitation Board (EB) has been formed. Confidentiality is ensured via the project consortium agreement (PCA).

The EB has an advisory function regarding the exploitation strategy and forms a natural interface between confidential exploitation plans created by the parties and all important stakeholders of InSecTT.

In short: Exploitation Board activities are focused on (increased) monetization of the project outcomes, aiming

• to analyse exploitation plans provided by partners, and to look for synergies within and also outside the consortium.

• to support partners in development of common exploitation strategy and corresponding activities that should be undertaken; and

• to prepare documents in coordination with the Strategic Board that can be passed to third parties, e.g. SMEs outside of the InSecTT consortium, or specialized organisations that can support InSecTT’s long-term strategy.

12 Use Case Marketplace

Use cases provide the primary path towards exploitation of technologies in the project. InSecTT has defined and organized so called Use Case Marketplaces (see Fig. 8), in order to

• demonstrate results in use cases (and naturally of the TBB’s used in the UC),

• gain in-time feedback for technical work from first implementations,

• allow to discuss results to fertilize interoperability and cross-domain use,

• support discussions to open additional exploitation opportunities for TBB’s used in the use case.

The project is designed into three iterations, therefore allowing typically three (in some cases more) generations of UC demonstrators, with increasing maturity.

13 Open Innovation

Open innovation applies know-how from “outside” during research and development, and allows to engage stakeholder already during R&D, see Fig. 9.

InSecTT developed its Open Innovation process in three steps, starting with a small and confined test run with just a few partners from the consortium and with a limited time window. The 2nd iteration was advertised in the full consortium, but still participants were only allowed from within the consortium.

A final event handing out in total 10 awards at the F2F Meeting in Gdansk (June 2022) provided enough motivation to solicit many interesting ideas already. As this was still done within the consortium only, participants could exchange ideas without being restricted by any NDA considerations.

The main concept, shown in Fig. 11, is based on

Fig. 11

The main concept of the 2nd iteration of an open innovation contest in InSecTT

• 1. a description of a component which is already available or under development in the project, e.g.: hardware solution, (AL/ML) algorithm, methodology, software, embedded device). The description is drafted by the lead implementer (called Partner A) in Fig. 11

• 2. ideas, e.g. suggested by partner Z, bringing this component into a new use case, e.g., a new application area, or exploiting new synergy with an existing product, to provide additional benefits, address new market or users

The expected effects can be summarized as

• New ideas for InSecTT technology development (small adaptions for accessing new potentials in new use cases and new innovations)

• Alternative use cases opportunities and possible B2B collaboration

• New project proposals.

14 Publications to Prepare Markets

Quite naturally as in most research projects, presenting papers at conferences or putting publications in journals and other platforms are used extensively to promote results and to solicitate feedback from the research and engineering community.

The addressed stakeholders of such channels typically include academic communities, researchers and experts from the field of policy, science, and industry, students (Ph.D./Master) and applied researchers in industry, and are therefore probably more focused on results with lower TRL.

This is supported by organizing workshops and special sessions as part of established conferences, again to provide a platform for discussion and networking in the research community.

In 2021, the InSecTT consortium applied for and was granted to organize a full-day workshop at the IEEE WF-IoT 2021 conference, title: Wireless Intelligent Secure Trustable Things: bringing IoT and AI together (https://wfiot2021.iot.ieee.org/wstrack3/).

In 2022, the InSecTT consortium applied for and was granted to organize a workshop at the MIKON 2022 conference, title: Focused session 1—Intelligent, Secure and Reliable Wireless Systems (https://mrw2022.org/mikon-focused-sessions/).

15 Website and Social Networks

A key factor to reach stakeholders and build networks is an informative, easy-to-find project website (https://www.insectt.eu/). Frequent updates provide current project news to the public, and allow a low-barrier introduction of project objectives, activities and partners and contacts. It also acts as repository for (public) deliverables.

Quite important is to accompany this web presence by appropriate activities using social media. InSecTT uses multiple channels of social networks, to provide fast, low-latency updates about InSecTT activities, and to reach the broadest spectrum possible of potential stakeholders and interested citizens (Tables 1 and 2).

Table 1 InSecTT's podcast channel

Table 2 Social networking channels used by InSecTT

16 Industrial Conferences, Trade Fairs and Podcasts

The project started in June 2020 and finished in August 2023. Unfortunately, it has therefore experienced constraints and challenges coming from a world-wide COVID-19 pandemic and a war between Russia and Ukraine, severely impacting both world economy and typical research project dissemination and exploitation support actions (travel, conferences, trade fairs etc.). Some remedies have been initiated by the InSecTT consortium, like releasing Podcasts (https://podcasts.apple.com/at/podcast/project-insectt/id1605747720) as a low-barrier channel to reach potential stakeholders, see Table 1.