The InSecTT Reference Architecture

Abstract

This chapter presents an overview of the Reference Architecture (RA) of the project InSecTT. The chapter makes emphasis on the impact generated by the new AI (Artificial Intelligence) algorithms and their associated building blocks (BBs) on standard architectures for IoT. The chapter focuses on the main views or perspectives of the architecture, on how AI interacts with each one of these perspectives and in the end we provide two examples of use case alignment and the analysis of the impact of AI on the individual architectures.

Acronyms

 

5G:

Fifth Generation mobile systems

3GPP:

Third Generation Partnership Project

AI:

Artificial Intelligence

AIOT:

Artificial Intelligence of Things

AIOTI:

Alliance for Internet of Things Innovation

AFDX:

Avionics Full-Duplex Switched Ethernet

ARINC:

Aeronautical Radio, Incorporated

BB:

Building Blocks

BGW:

Bubble Gateway

BLE:

Bluetooth Low Energy

BT:

Bluetooth

BS:

Base Station

CAL:

Cloud and Application Layer

CAN:

Controller Area Network

CL:

Cloud Layer

CLM:

Cross-Layer Management

CMMS:

Computerized Maintenance Management System

CNN:

Convolutional Neural Network

CoAP:

Constrained Access Protocol

CSV:

Comma Separated Values

DEWI:

Dependable Embedded Wireless Infrastructure

DL:

Device Layer

ECAL:

Edge, Cloud and Application Layer

EMR:

Electronic Medical Record

EU:

External User

ETSI:

European Telecommunication Standards Institute

GDPR:

General Data Protection Regulation

GNSS:

Global Navigation Satellite System

GPS:

Global Positioning System

HLA:

High Level Architecture

HTTP:

Hyper Text Transfer Protocol

InSecTT:

Intelligent Secure Trustatble Things

IEEE:

Institute of Electrical and Electronic Engineers

IoB:

Internet-of-Bubbles

IoT:

Internet-of-Things

IP:

Internet Protocol

ISO:

International Standards Organisation

ITU:

International Telecommunications Union

ITS:

Intelligent Transportation System

IU:

Internal User

JSON:

Java Script Object Notation

LTE:

Long Term Evolution

M2M:

Machine to Machine

MAC:

Medium Access Control

MIMO:

Multiple Input Multiple Output

MQTT:

Message Queuing Telemetry Transport

MTP:

Media Transfer Protocol

NAT:

Network Address Translationn

NB-IoT:

Narrow Band IoT

NFC:

Near Field Communications

NL:

Network Layer

NR:

New Radio

NOMA:

Non-Orthogonal Multiple Access

OTA:

Over-The-Air

PHY:

Physical Layer

RA:

Reference Architecture

REST:

Representational State Transfer

RFID:

Radio Frequency Identification System

RNN:

Recurrent Neural Network

RSSI:

Received Signal Strength Indicator

RSU:

Road Side Unit

RTLS:

Rela Time Locating Systems

SCOTT:

Secure COnnected Trustable Things

SL:

Security Layer

SLM:

Security Layer Management

SNRA:

Sensor Network Reference Architecture

SOAP:

Simple Object Access Protocol

SSL:

Secure Socket Layer

TCN:

Train Communication Network

TCP:

Transmission Control Protocol

TLS:

Transport Layer Security

TLV:

Type length Value

TMS:

Transport Management System

UDDI:

Universal Description, Discovery, and Integration

USB:

Universal Serial Bus

UWB:

Ultra-Wide-Band

WAICs:

Wireless Avionics Intra-Communications

WiFi:

Wireless Fidelity

WSANs:

Wireless Sensor and Actuator Networks

WSN:

Wireless Sensor Networks

XLM:

eXtensible Markup Language

V2V:

Vehicle-to-Vehicle

V2x:

Vehicle to Everything

VBGW:

Virtual Bubble Gateway

 

1 Introduction

The proliferation of objects with embedded processing and networking capabilities is regarded as the new industrial revolution that will radically change our daily lives. Millions of distributed sensors and actuators will be controlled and automated directly by algorithms running in the cloud or edge processing servers.

The success of the Internet-of-Things (IoT) is being reflected on an increasing demand for more complex and critical applications. Examples of the new wave of applications are autonomous vehicles, automated wireless aircraft operation, remote health monitoring, virtual reality real-time surgeries, etc. New wireless technologies and in general improved IoT infrastructure are being designed particularly to support object/machine connectivity with higher data rates, higher security levels, and with real-time capabilities (e.g., 5G or fifth generation systems).

The fast market penetration of IoT has created many interoperability, design, compatibility, and regulation issues. Standardization bodies have proposed a series of reference documents, guidelines, standards and recommendations that are meant to facilitate the design of such massive critical systems.

Perhaps the first reference architecture for connected objects was the ETSI M2M [1] and ETSI oneM2M [2] architectures that addressed inter-operability and interfaces of M2M (machine-to-machine) systems. One of the first reference architectures for IoT was proposed in the European project IoT-A [3], using the concept of multiple views or perspectives of the architecture. This multi-dimensional approach matches the multiple factor and multiple stakeholder framework for the design of modern systems. Major standardization bodies proposed their own architectures, for example the ITU architecture in [4], the IEEE architecture [5] and the ISO-standard architecture [6]. The alliance for IoT industrial innovation (AIOTI) [7] proposed a framework of interoperability between many of the existent reference architectures.

The predecessor projects of InSecTT, the project SCOTT [8] and the project DEWI [9] have also proposed high-level architectures compatible with international standards and supporting details of the objectives of each project. In the case of InSecTT [10], the major goal is to investigate the impact of AI and the new supporting technical building blocks (see Tables 1 and 2) on the different views and perspectives of standard reference architectures. This also includes to determine in which parts of the architecture AI algorithms reside, or in which parts the different functionalities associated with AI operate or can be supported. This analysis also conveys a stress and security tests for the different interfaces of the architecture. The final objective is to have an overview of how AI interacts with the IoT world, particularly using edge infrastructure and provide useful recommendations to the general user/designer based on the outcomes of the analysis of the different domains and use cases.

The organization of this chapter is as follows. Section 2 provides an overview of existing approaches investigating the impact of AI on IoT architectures. Section 3 provides an overview of the InSecTT architecture. Section 4 presents the entity model of the architecture, while the domain model is described in Sect. 6. Section 7 presents the functionality model, while Sect. 8 presents the information and communication models of the architecture. Section 9 presents the new AI perspectives of the architecture and their impact on the rest of the views. Finally, Sect. 10 presents examples of the alignment of use cases to the InSecTT reference architecture.

2 AI in IoT Architectures

The last decade has witnessed an exponential increase in applications of AI for a variety of aspects of IoT applications. These aspects range from the lower layer transmission improvements, to upper layer applications including intelligent services, consumer preference prediction, etc. However, the impact on the IoT architectures is rarely addressed consistently in the literature. One example is the work in [11], where the authors study the use of specific AI functionalities across different layers and entities of an IoT architecture enabled with block-chain technology. The use of AI in Edge computing architectures is presented in [12]. This work focuses more on the entity and logical model views of Edge processing architecture and the impact of AI.

Other works offer a semantic decomposition of AI algorithms and their specific processes in IoT architectures or applications. The authors in [13] propose the use of specific sub-functionalities generic to different AI algorithms such as feature extraction, learning, knowledge storage, decision making and automation control. This type of decomposition seems the most attractive to include specific AI processes in future AIoT (Artificial Intelligence of Things) architectures.

The work in InSecTT was to propose a relative advance in the state of the art on how AI tools have an impact on IoT reference architectures. More specifically the work was initially intended to decide whether the AI impact is high enough to include specific sublayers or views or another types of tools in the official InSecTT reference architecture. The next step was to modify the official architecture and align the existing use cases and the InSecTT universe of AI algorithms. Some of our conclusions are expressed in this chapter.

3 Overview of the InSecTT Architecture

Let us now define the InSecTT RA as the set of guidelines for infrastructure organization of IoT (Internet-of-Things) use cases targeting industrial-grade connectivity, security, dependability, interoperability and trustworthiness with the help of artificial intelligence (AI). It provides the high-level view of (sub-)building blocks, interfaces, vulnerabilities, security solutions, protocols, and in general the detailed information flow of InSecTT use cases in different industrial domains (aeronautics, automotive, railway, building, healthcare, maritime, etc). This provides us with a tool to analyse reusability, standardization, certification and verification issues across domains.

The InSecTT RA hosts a set of best practices collected across three EU projects: DEWI [9], SCOTT [8] and InSecTT [14]. The DEWI RA focused on dependability, using IoT protocols as a method to provide interoperability. The concept of DEWI Bubble was used as the encapsulation of legacy infrastructure. The DEWI RA was built on top of the ISO SNRA (sensor network reference architecture) [15]. The extension considered dependability improvement features. The SCOTT project saw the extension towards a full IoT architecture with improvements on high level aspects such as Edge/fog processing, security, privacy, safety and trustworthiness. This was achieved by combining multiple standard architectures. The InSecTT RA reuses the DEWI/SCOTT frameworks and the Bubble concept to investigate the impact of AI on IoT architectures. The material used in this chapter is an extension of the work previously published in [14, 16].

The core of the InSecTT solution is the concept of Bubble. An InSecTT Bubble is a logical entity formed by a group of nodes, gateways, internal users and existing (legacy or new) industrial infrastructure. The main property of a Bubble is that it provides a single point of access (the Bubble Gateway) to the information of the entities in the intra-Bubble space. The InSecTT Bubble is therefore useful to encapsulate multiple industrial protocol standards into a consolidated IoT technology format improving and enforcing inter-operability, dependability and cross-domain development. The Bubble recommendations target the dependable integration of wireless/wireline industrial infrastructure using a three-layered intra-Bubble hierarchy that facilitates intra-domain adaptation and protocol translation, and a new trustworthiness-by-design philosophy. InSecTT foresees a landscape of communicating intelligent Bubbles implemented in different industrial use cases that can be called the Internet-of-Bubbles (IoB). Each Bubble can decide, if convenient, to allow transparent access to the nodes inside the Bubble or provide only consolidated, aggregated or processed information.

3.1 Evolution of the Bubble

In the DEWI project, the Bubble was introduced for the first time as encapsulation of industrial infrastructure which was useful to improve dependability and interoperability. The Bubble in DEWI was also created with a mechanism of technology cross-domain utilization, using a proprietary protocol for dynamic sharing of software or middle-ware components between Bubbles. By contrast, in SCOTT the Bubble evolved towards a type of advanced Edge infrastructure with security as added value. The extension to SCOTT included the use of multiple modifications to interfaces and functionalities to enable the Bubble as a secure encapsulation of industrial communications and secure exchange of technical building blocks. The evolution from DEWI to SCOTT also included the use of security and trustworthiness metrics for different layers of the architecture. The Bubble was therefore modified to support communications between Bubbles based on trustworthiness metrics, which leads directly to the use of adaptive security enhancement solutions. The SCOTT architecture was created based on the combination of multiple standards for IoT architecture, preserving the Bubble for encapsulation, dependability and security of industrial use cases. In InSecTT, the Bubble evolved to cope with a more dynamic interface scenario inside the Bubble and with the ability to host AI algorithms in different levels of the architecture or in different entities. The Bubble became “intelligent”. This evolution is reflected in Fig. 1.

Fig. 1

Evolution of the Bubble

Table 1 InSecTT sub-building blocks

Table 2 InSecTT sub-building blocks

3.2 Modern Reference Architectures

The InSecTT RA follows the multiple-perspective approach used by modern IoT systems matching the needs of multiple stakeholders and multi-level quality of service end user applications. Figure 2 shows the perspectives of the InSecTT RA in contrast with the views of the ISO IoT reference architecture in [6]. In blue are shown those views that are part of the InSecTT RA and that were extended from the ISO model. In orange are those that belong to the ISO model but were not entirely developed in this project. In yellow the views that are not ISO and were not developed in detail here, but they are borrowed from other projects. In green those in the ISO model but not included in InSecTT. Finally, in grey the additional views included in this project that are not ISO. We will describe the main views of the architecture and the impact of artificial intelligence on each perspective. We will describe the main views of the architecture and the impact of artificial intelligence on each perspective. Additionally we describe our own AI perspective of the reference architecture. It is worth pointing out that the different perspectives of the RA are not completely independent and we usually find overlapping aspects between them. In several alignment exercises it is sometimes necessary to use a hybrid view representation, which combines relevant aspects of two or more of the perspectives portrayed in this framework.

Fig. 2

Architecture perspectives

4 Entity Model

The main perspective of the InSecTT RA is the layered physical entity model portrayed in Fig. 3. In addition to the definition of each entity in an IoT network, the InSecTT RA provides a layered hierarchy which has been specifically designed for the integration of new and legacy wireless and wireline industrial infrastructure in a dependable and secure manner. The proposed three-layers reflect the interaction between the wireless or Level 0 (L0) world, with the existing and potentially critical wireline industrial infrastructure (called Level 1 or L1), and Level 2 (L2) that acts as the encapsulation of the previous two layers. This encapsulation is in the form of a Bubble using a physical or virtual InSecTT Bubble Gateway (BGW) providing external services that can be invoked by other applications or other Bubbles based on multiple trustworthiness metrics. Note that AI algorithms or functionalities of these AI algorithms can be distributed in different elements and levels of this layered model, and each implementation has different implications in terms of complexity, security, communication interfaces and functionalities.

Each layer of the architecture can also host different functionalities related to the new wave of AI algorithms. The BGW is therefore the main entity controlling access to the information of the internal nodes of the Bubble. Other GW entities can be defined inside the Bubble to deal with decentralized processing (AI) and dependability control between L0 and L1. The three-layer architecture allows designers to distribute complexity and AI functionalities in different layers and different types of gateways, providing encapsulation of legacy technology in modern IoT protocols for interoperability and secure information transport. Level 0 (L0) is the wireless technology used inside the Bubble for one or more WSNs. Level 1 (L1) is the infrastructure inside the InSecTT Bubble to connect several WSNs to the corresponding BGW. This can be for example, the internal bus of a vehicle or the proprietary network of a building. Level 2 (L2) is the infrastructure providing a common external access to the Bubble (usually based on a request-response paradigm).

Fig. 3

Entity model

The main physical entity in the InSecTT architecture is called Bubble. A Bubble will be able to contain one or more wireless sensor or node networks. Each WSN or node network will be managed by an L0 Gateway (also called WSN gateway or WGW). Therefore, the Bubble Gateway will be in charge of managing all the L0 Gateways inside the Bubble, while also providing external/internal secure access to the information of Nodes (sensors and actuators) of each WSN or node network. This internal/external access to the Bubble information is encapsulated in a set of Bubble Services that can be invoked by internal and/or external users (AI algorithms external to the Bubble can invoke these services or bubbles can also host AI services). This also means that all Bubble operation and management of high-level services will be hosted by the Bubble Gateway. In principle, the bubble services can also include the functionalities related to AI, such as learning, or sharing data sets (federated learning). This infrastructure arrangement naturally leads to the definition of three levels or layers of communication (one of them being optional):

Level 0 (L0) is the communication technology/architecture inside a specific wireless sensor network (intra-WSN). Each WSN can have a different Level 0 technology. Several WSNs can be hosted by one Bubble Gateway. L0 is in general the most unreliable of the three levels of the architecture. Therefore, multiple AI algorithms can be destined to overcome the issues found in L0, such fading, shadowing, interference, eavesdropping, etc. Particular changes have been implemented in the final version of the architecture to deal with long range L0 technologies such as 5G.

Level 1 (L1) is the communication technology/architecture inside the InSecTT Bubble to connect several WSNs to the corresponding Bubble Gateway. L1 technology is optional, mainly because some scenarios will deploy only one WSN per Bubble. In such cases, the Bubble Gateway will control all the nodes directly. L1 technology depends on the use-case (UC). Some of the UCs require L1 to be a real-time technology. Middleware solutions for L1 usually deploy publish-subscribe approaches to reduce operations and latency. Several AI implementations at the edge can take advantage of L1 technology being real time to reduce latency and improve reliability. In particular, resource allocation AI algorithms to improve L0 performance can reside in this L1 hierarchy. L1 technology is largely vulnerable to new attacks that come from the new wireless medium. AI algorithms can help in protect L1 infrastructure which in general is more critical than the L0 technology.

Level 2 (L2) is the communication technology/architecture outside the Bubble (extra-Bubble). It provides a common(standard) external access to the Bubbles. This technology should be a standard for all industrial domains, so clients (humans and machines) can gain access to any kind of Bubble to use the available Bubble Services. Middleware approaches usually deploy a request-response approach consistent with an Internet cloud technology with non-critical traffic support. External AI algorithms can run in this level of the architecture, but usually in a non-critical fashion. In general they can be used to update data sets using learning algorithms resident in the cloud or back end servers. This distributed learning scheme needs security and privacy.

The Bubble helps designers to enforce different trustworthiness metrics inside the Bubble. By explicitly isolating critical infrastructure and providing specific mechanisms (secured) that external entities are allowed to access or request, security is improved and therefore external attacks can be controlled or reduced. In addition, the concept of the Bubble has been found compatible with modern technologies such as block-chain, Edge/fog computing, and now AI. The Bubble is well suited for distributed AI in the three levels of the architecture with different levels of complexity that have been showcased in different industrial domains. The virtual Bubble GW is adapted to include direct cloud links or hybrid combinations of short range with long range direct cloud links inside the Bubble. This means that the BGW can be completely virtualized in the cloud or edge infrastructure of a service provider. This is also compatible with futuristic implementations of 5G/6G systems with network slicing. The layered approach of the InSecTT Bubble is shown in Fig. 3 with the different types of HW interfaces between entities.

The InSecTT RA hosts a set of entities with different roles and functionalities. The main entities and the hardware interfaces enabled between them are shown in Fig. 3. The main entities are the Bubble nodes, the different types of Bubble Gateways, the different types of users of Bubble services and the external entities to the Bubble. The Bubble GW has a dominant role in being the enabler of the Bubble services and controls all access to the information inside the Bubble. The Bubble will also host the majority of AI algorithms. We highlight the possibility of the virtual Bubble GW (VBGW) to deal with those use cases where direct cloud links can be used by nodes inside the Bubble. The virtual and physical BGW can coexist, but always they should be integrated to mimic a single entity for security reasons. This also leads to the concept of hybrid user which is particularly suited for modern terminals with multiple radio interfaces and flexible mobility that can roam in and out the Bubble providing different levels of connectivity between nodes and external entities or with the virtual Bubble GW. We highlight the use of multiple gateways per level of the hierarchy to preserve the quality of service, delay, security, and offer encapsulation of underlying industrial technologies. Unlike other standard architectures, the InSecTT RA provides with specific procedures to support this detailed industrial connectivity and dependability issues between wireless and internal industrial wireline protocols. This is particularly useful, for example, in automotive use cases where wireless sensor readings are relayed to the internal network of the car, or also on board aircraft where sensor nodes using the new wireless avionics technologies relay information to the internal critical aeronautics network. The node and entities of InSecTT are allowed to use multiple interfaces creating new challenges in routing, security, authentication and privacy that can be addressed by the InSecTT building blocks. The InSecTT builiding blocks are displayed in Tables 1 and 2. The RA also has specific procedures for service and object virtualization which are important in applications such as digital twins and for security enhanced remote control.

The following elements constitute the intra- and extra-Bubble space of the RA:

Bubble Node (BN): Any tag, sensor, and actuator (or combination of some of them as one single node entity) working under the Bubble framework. Bubble Nodes implement several of the functions of the functionality model described in subsequent sections of this document. The nodes may have different radio technologies for communication and may not necessarily lie within the wireless range of each other. Multiple interfaces simultaneously are allowed in a single device. Some nodes could also host AI algorithms, depending on the complexity constraints.

Bubble Gateway (BGW): The entity that acts as the main logical interface of a Bubble to communicate with other Bubbles, users (internal and external), and with other external (extra-Bubble) entities. It also provides protocol translation and management functionalities for all the InSecTT nodes and all the WSNs inside the InSecTT Bubble. For redundancy purposes, alternative gateways can be deployed, but there must be always only one logical gateway acting as interface of the InSecTT Bubble. The majority of AI algorithms or associated functionalities are expected to be hosted by one of the BGWs described here.

EDGE Bubble Gateway (EBGW): An InSecTT Bubble Gateway with explicit Edge processing capabilities. An Edge BGW is particularly suited for low latency and security enforced near the edge of the network. In InSecTT, the Edge Bubble Gateway has a particular importance for hosting most of the AI processing capabilities.

Virtual Bubble Gateway (VBGW). A cloud-mirror implementation of an InSecTT Bubble Gateway in charge of the remote control of external connections invoking specific out of band connections to the Bubble Gateway services. The virtual Bubble Gateway can act in collaboration with a physical Bubble Gateway, or as standalone, thus defining a virtual Bubble completely managed by the Virtual Gateway. The need of a Virtual Gateway comes from the new complex use cases with multiple users or nodes using a variety of short-range or direct cloud technologies to interact with the Bubble infrastructure. An advantage of the virtual Bubble implementation is the invoking of AI algorithms centralized in the cloud or in Edge processors. This enables low latency end to end for AI services.

Relay Gateway (RGW): A device that allows direct Bubble-to-Bubble (B2B) communication without the need of specific infrastructure. It also relays the functionalities of a DEWI Bubble Gateway. The relay gateway allows the concept of the Bubble to acquire full strength. A Bubble makes the information available to the external world only by accessing the boundary of the Bubble, through the designated relay or main Bubble gateways. A pending issue is the use of relay gateways to invoke AI services of other bubbles. This is a security issue that must be tackled in the future.

WSN Gateway (WGW): A device in charge of the management and protocol translation of an intra-Bubble WSN, e.g., a ZigBee gateway, or a Bluetooth master device. The WSN Gateway can be a legacy device. The WSN Gateway communicates with the Bubble Gateway, which is in charge of the management of all the WSN Gateways inside the same Bubble. In some cases, these devices host some of the AI algorithms, particularly those focused on the improvement of the physical layer.

Users (internal and external): The entities that can access and use the set of Bubble services provided by the Bubble Gateways or Relay Gateways. Internal Users are meant to be inside the Bubble accessing the Bubble Gateway via the intra-Bubble communication infrastructure. However, in InSecTT the internal users can be provided also with a direct connection to the cloud, usually a virtual mirror cloud application of the Bubble Gateway. The external users access the Bubble services through the extra-Bubble communication framework (cloud). This access is mainly via Internet and over open standard middleware application program interfaces. With the use of AI, new issues arise related to the privacy and confidentiality of data used to train different algorithms. Some of the users of the bubble services could access data used by learning algorithms in different parts of the architecture. We highlight the need to protect data confidentiality even from the internal users of the Bubble.

Service providers and back-end servers: An entity or set of entities that provide services to third parties based on the aggregation of multiple Bubbles. In distributed AI, we can have AI services or AI functionalities invoked as services in different bubbles. Therefore, the InsecTT Bubble can also becomes an intelligence service provider

5 Layered Model

5.1 Level 0

Level 0 (L0) is the technology used inside each WSN of a InSecTT Bubble. L0 technology can be used to interconnect the InSecTT Nodes with two different entities:

• 1. the WGWs (in case the InSecTT Bubble contains more than one WSN) or

• 2. the InSecTT BGW (in case a InSecTT Bubble only hosts one WSN, i.e. L1 does not exist).

• 3. directly to the cloud, in case the nodes have multiple interfaces and one of them provide direct 5G access to cloud infrastructure.

Level 0 technological choice is independent for each use-case. Level 0 is usually the wireless technology used to interconnect, manage and retrieve the information from/to sensors and actuators (InSecTT Nodes). The challenge in the design of the HLA and its appropriate infrastructure is to host such a diverse and heterogeneous landscape of technologies communicating with each other. The project DEWI focused on the dependability issues of L0 infrastructure. SCOTT project dealt with security and trustworthiness (trust) issues of IoT using a diverse set of L0 technologies. InSecTT project now builds upon these two previous projects dealing with the improvement of both dependability, trust, and security/safety using AI technology at the edge of the network. It is worth pointing out the generational change experienced from the beginning of the DEWI project and now in the course of the InSecTT project regarding wireless technology. 5G is now a reality in commercial implementations, which allows direct cloud connections from virtually anywhere inside the cellular provider’s coverage area. In addition, vehicular technologies and local area networks have also been evolving to become more reliable with higher capacity and lower latency. The technology MIMO (Multiple-Input Multiple-Output) is now not only a fact but a necessity in the new standards. New challenges are also emerging such as 6G and the concept of THz communications. It is expected that the algorithms and building blocks proposed by InSecTT are reusable for upcoming L0 technologies.

We recall here some of the important technologies and issues found in L0 and the potential of AI to counteract such issues. Wireless technologies experience different issues in different frequency bands. In general, higher frequencies achieve higher data rates at the expense of increasing path loss, which limits coverage thus increasing infrastructure requirements to provide urban footprint. Different transmission technologies also possess different qualities in face of impairments. While cellular communications are currently dominated by OFDM-based transmission technology, including the 5G new standards, a multitude of technologies are currently coexisting across different standards, including spread spectrum frequency hopping, direct sequence CDMA, ultra-wide band, etc. Each one of these choices has different virtues in the face of issues such as fading, shadowing, path loss, non-line of sight, etc. CDMA-based are more resistant to fading due to their diversity combining gains, but OFDM are attractive to deal with dense multipath interference. UWB technology has been found useful in localization applications in dense multipath situations such as in metallic environments. Joint sensing and transmission technologies also make use of the properties of wireless transmission standards, particularly using WiFi and/or the new MIMO features of 5G. The issue of jamming is closely correlated to the ability improvement brought by MIMO or other interference cancellation schemes. In general, the use of artificial intelligence for the improvement of the reception/transmission of wireless signal was tested in the project with different degrees of success. In the case of MIMO, an AI-MIMO transceiver was successfully designed and tested by simulation. The advantages seem very clear, surpassing some well know signal processing tools, but several disadvantages were also found. In wireless networks, the major disadvantage seems to be the rapid statistical changes experienced in wireless networks, and the need to select rapidly different data sets, or conversely to train models using a huge set of wireless measurements. These are open implementation issues that can be solved in the future.

5.2 Level 1

Level 1 (L1) is the technology used to interconnect all the intra-Bubble WSNs to their corresponding InSecTT BGW (in case the InSecTT Bubble hosts more than one WSN).L1 is an optional technology, but in some use cases it is an integral part of the legacy infrastructure that must be protected from issues due to the addition of new features . There are two main reasons why L1 is an optional feature in the HLA:

• There are some use-cases in which the InSecTT Bubble hosts a single intra-Bubble WSN. In these cases, the InSecTT BGW and the WGWs converge in one single entity: L1 disappears and only L0 and L2 are implemented; and

• Different use cases have different requirements to interconnect the WSNs.

There are several advantages of using a different L1 technology for different use cases. Some of them are listed below:

• It allows network designers to meet domain-specific or use-case-specific design criteria. This also has an impact on AI implementation by controlling the environment and coverage footprint, which in turn controls the data sets and reduces the non-stationary effects that can reduce the effectiveness of AI for wireless.

• It also improves scalability in the HLA, mainly because several WSNs can be hosted by one single InSecTT BGW. Thus, the number of InSecTT Nodes hosted per InSecTT BGW increases according to the supported WSNs hosted by L1 technology. AI solutions can further increase the scalability provided by L1.

• It provides a useful organization of resources in dense object deployments. It also allows centralization of intelligent services, and the share of learning weights or data sets among different networks inside the bubble.

• It allows for an efficient resource allocation by centralizing all the WSN management in one single location (logical): the InSecTT BGW. This means, for example, that adjacent WSANs can be allocated in different channels by the InSecTT BGW, thereby reducing interference inside the same InSecTT Bubble (intra-Bubble interference). AI algorithms for channel prediction can be used for resource allocation of adjacent WSNs inside the same Bubble

• The existence of L1 technology facilitates the integration of wireless InSecTT Bubble solutions with the existing wired technologies of each domain, which is a unique aspect of InSecTT. This aspect also improves the technology re-usability features of the HLA, mainly because some wireline technologies share common aspects across different industrial domains,

• L1 can provide wired/wireless infrastructure for internal users to obtain access to InSecTT Bubble services,

• L1 allows network designers to create a private internal network where high security and quality of service requirements can be enforced, and

• L1 can naturally hosts AI algorithms to be reused across different L0 technologies.

The decision of using L1 also conveys some additional efforts summarized as follows:

• L1 needs an additional (Radio Resource Management) layer to organize the different WSNs inside the Bubble.

• L1 needs to design gateways and scheduling policies that match the quality of service and dependability requirements between L0 and L1. Mainly in case of critical designs.

• The InSecTT Bubble becomes a complex set of heterogeneous WSNs and wireline transmission protocols that need special cross-layer optimization algorithms. Some of these can be based on AI.

Level 1 technology must also comply with several of the requirements and attributes of InSecTT for intra-Bubble communications. Some of these requirements are:

• L1 must provide reliable, transparent and secure access to the information of the InSecTT Nodes inside each Bubble.

• L1 must preserve the dependable, self-configurable and secure data transfer of the InSecTT Bubble.

• L1 must provide the InSecTT Bubble with a framework for the management, resource allocation, configuration, troubleshooting and maintenance of the intra-Bubble WSNs.

• L1 must provide conflict resolution or deterministic allocation of the data streams and traffic of all WSNs. Prediction algorithms based on AI, as well as fault detection can be implemented to improve performance.

• L1 provides an interface for internal users of the InSecTT Bubble to access the InSecTT Bubble Services.

Level 1 in InSecTT HLA is closely related to the existing infrastructure (wired) of each industrial use-case. Since L1 must preserve the dependability requirements inside the Bubble, middleware tools with message-oriented and application-oriented approaches are recommended. Service-oriented architecture for L1 provides the HLA with the flexibility to organize resources across different WSNs and model them as available services inside L1. Publish-subscribe middleware technologies fit perfectly the requirements of L1 high quality of service.

Regarding AI algorithms, L1 technology based on a real time technology offers interesting options to implement improved resource allocation based on AI between WSNs and use deterministic deadline calculation for services of different WSNs with controlled interference. L1 is also the side of the network enabled by EDGE Bubble Gateway implementations of AI algorithms. This means that L1 will be probably the recipient of most of the traffic generated by the new resource-hungry AI processing requirements running at the Edge of the network. The accurate estimation of resources needed by this type of AI is not yet clear, thus being an open issue on the evaluation of the impact of AI in L1.

Since L1 is related to the existing infrastructure in different use cases, there has been not much change with respect to the technologies described in SCOTT and DEWI. The domains of automotive, railway, and aeronautics continue with their bus standards but now they have included stronger cybersecurity recommendations focusing on the new types of threats. In the domain of building, healthcare and maritime, the use of conventional Ethernet-base infrastructure provides a higher degree of interoperability between building blocks.

5.3 Level 2

Level 2 (L2) is the layer in charge of the communication between InSecTT Bubbles and external user(s) or agent(s). The external agents can be other InSecTT Bubbles. L2 is thus responsible for the interoperability and cross-domain application development. Level 2 is the way an InSecTT Bubble exposes its information and services to the outer world, including external AI in the cloud. There are several features unique of Level 2 in comparison with the other two Levels of the HLA:

• L2 uses Internet-based (IoT) protocols to enable external users with access to the set of Bubble services from anywhere in L2.

• L2 is also responsible to provide federated access to a set of different InSecTT Bubbles and to data sets or information learned from the different Bubbles.

• L2 must support interoperability, cross-domain application development and technology (AI) re-usability.

• L2 must enforce security and protection to the data and operation of the InSecTT Bubble against external malicious attacks (AI-based)

• L2 must use international standards to enable interoperability with other external systems.

In order to achieve these goals, L2 has adopted a service-oriented architecture (SOA) with a middleware paradigm based on request-response. This paradigm is inherently non-real time. Therefore, L2 is envisioned as a layer where external users request access to a summarized version or non-real time information generated by the InSecTT Bubbles. The InSecTT functional model includes specific L2 services. The previous projects DEWI and SCOTT have not proposed a unique L2 communication technology. Instead, the approach was to provide generic guidelines to achieve the goals of Bubble-to-Bubble communication and interoperability goals according to the INTEROP standard model and their definition of interoperability. In this project there has been a narrowing of the protocols used for L2 communication. Sine the focus is on AI, the variety of protocols used declined with respect to the previous two projects. We saw an increase of the influence of the MQTT protocol versus other L2 technologies such as HTTP, COAP, etc. MQTT showed great flexibility for the variety of use cases and technological solutions based on AI.

5.4 Hardware Interfaces

The following interfaces between entities are allowed in the InSecTT architecture:

Node-Node. This can be the same as the L0 Node to WGW link. However, in some situations this technology can be implemented using another technology, using multiple interface devices. The impact of AI is not expected to be huge on this interface, except in some application such as platooning, where V2V technology is reliable enough to achieve ultra-low latency and real time communications.

Node-WGW. The main L0 wireless technology to provide pervasive coverage from the WGW to the nodes inside the Bubble. It can also be used by AI algorithms dealing with the physical layer.

WGW-BGW. The L1 intra-Bubble infrastructure communication that connects all WSNs inside the Bubble to the Bubble Gateway. This interface is used to transmit messages containing data from the nodes and sensor network management messages to/from the WGW. The protocols defined in this interface depend on the application requirements and on the WSAN architecture chosen to build up the network. The data information transmission from the nodes to the WGW might be scheduled periodically, triggered by events, or on request by the WGW. The scheduling might also occur in case AI algorithms need to update the training information.

Node-BGW. The L0 technology directly between the Nodes and the BGW, in case there is no L1 technology.

Node-EBGW. The L0 technology directly between the Nodes and the BGW, in case there is no L1 technology

Node-VBGW. The L0 technology directly between the Nodes and the BGW, in case there is no L1 technology and no Physical BGW. This interface can be used to connect directly nodes to AI algorithms in the cloud.

IU-BGW. The interface between the internal user and L1 technology of the BGW

IU-VBGW. The interface between the internal user and the Virtual Bubble GW

EU-CL. Interface between an external user and the cloud servers. This is the L2 technology.

BGW-CL. Interface between the Bubble Gateway and the cloud back-end servers.

6 Domain Model

InSecTT has adopted a modified domain model of the IoT-A reference architecture European project [3]. The domain model is displayed in Fig. 4, showing the main physical entities to be represented in the cyberspace: tags, actuators, nodes and the InSecTT Bubble, as well as their virtual representations and the link to the external users through a service-oriented implementation. It provides the virtualisation of objects to be represented in the cyberspace. It also defines the relationships between services, external entities, devices and virtual representations. This model has been modified in the project SCOTT to account for different trustworthiness, security and privacy metrics. The conclusion of our investigation in the project InSecTT is that the AI dimension has impact on this perspective, particularly if we use federated learning or another type of distributed learning processes. In addition, explainable and trusted AI distributed algorithms need a domain model approach to enable the addressing, organization, and discovery of distributed AI and learning resources in the cyberspace. In InSecTT, we envision a future cyberspace with multiple resources and components of AI algorithms with different levels of trust and different properties that need a mechanism to be organized, addressed, listed, discovered, and managed. Therefore, the domain model will be essential to characterize the new elements of the new and potentially distributed intelligence dimension.

Fig. 4

Domain model

This domain model allows objects to be mapped directly into a virtual entity that can be reached via Internet protocols and tools. This is the main concept behind the IoT: physical objects accessible by the cyberspace. However, the InSecTT project provides another level of abstraction: the InSecTT Bubble. The bubble can provide transparent access to the objects inside the Bubble or it can decide to provide limited access. Therefore, the entity that is directly mapped into the virtual space will be the Bubble rather than individual objects. It depends on the particular implementation if the Bubble provides transparent access to objects or entities inside the Bubble. This is an aspect that will be defined in each use case or implementation of the reference architecture. It Is not yet clear for the future if the Bubble will be able to provide intelligent services or these will be located in other edge or cloud entities. In this architecture we leave both options as feasible to cover future decisions.

Fig. 5

Functionality Model

7 Functionality Model

The functionality model in Fig. 5 is a combination of the ISO IoT/SNRA [6, 15], the ITU [4], IEEE [5] and the AIOTI functional models [7]. The layers will be implemented by the physical entities of the reference architecture. Each of the layers of the functionality model can communicate with other layers using software interfaces. Each SW interface is potentially a standard data format or protocol and it can be subject to vulnerabilities. The InSecTT RA provides the option to have security mechanisms for each layer, in addition to the conventional security network layer included in the service and virtualization layer. It also includes a security management vertical layer that coordinates all security/trustworthiness solutions across different layers. The four horizontal layers are device (DL), network (NL), service (SL), and the cloud and application layers (CAL). The DL includes functions near the hardware, such as energy harvesting, sensor-related and basic MAC-PHY functionalities. The NL maps information into the cyberspace of L2 level. The SL encapsulates the lower layers presenting them as services, including virtualization services. This layer includes a security layer that runs on top of the conventional networking OSI layer. Finally, the CAL layer invokes the services of the SL as applications.

The InSecTT functionality model includes specific service virtualization features and cross-layer management. In addition, it includes a detailed functional model decomposition with multiple trustworthiness metrics evaluation models to investigate how these different metrics evolve across layers and entities of the RA. This has led to L2 adaptation based on trustworthiness metrics (indicators) and online certificates between Bubbles. Our vision is that communicating Bubbles in the cyberspace will be able to exchange trustworthiness metrics, indicators or information with online certification entities or anchors and this exchanged information can be used to adapt security, communication, semantics and other features in the interaction between Bubbles and other entities. InSecTT aims to use AI to improve several of these inter-Bubble interactions. More details of the layers of the functional view of the reference architecture are the following:

7.1 SW Interfaces

These interfaces between adjacent layers are the direct extension of the interfaces proposed by the ISO SNRA standard in [6]. These interfaces were adopted and modified in the SCOTT project to address the different issues of security, privacy and trustworthiness of IoT.

Interface DL-NL: This interface between the device layer (DL) and the network layer (NL) is usually part of the protocol stack definition. The network layer involves the basic functionalities of the communication interface (MAC-PHY) to provide network connectivity via a higher-level protocol, format, and frame definition. The network layer encompasses the network and transport layers of the OSI model. It also covers network management, troubleshooting, sensor information processing, fusion, etc. Security schemes are also important to avoid misuse of the functions invoked by the network layer, particularly for the operating system of one of the physical entities of the reference model. This is a relevant interface for AI algorithms that request information from the DL and transport it to another entity.

Interface NL-SL: This interface is used for the service layer to invoke the functionalities of the lower layers, encapsulated by the network layer. The service layer of the IoT has many different variations, particularly due to the diversity of use cases and applications. This interface is particularly prone to attacks or other vulnerabilities. Code injection, man in the middle attack and denial of service attacks can exploit this interface. AI algorithms for anomaly detection can be used in this interface. AI algorithms running at the edge might exploit this interface to obtain information.

Interface SL-CAL: Interface that allows the upper layer applications to access the services enabled by the BGW and all the encapsulated technology building blocks or functionalities. The virtualization of AI functionalities is directly related to topics such as Federated learning.

Interface DL-CLM: This interface allows cross-layer algorithms to collect information from the device layer and optimize system performance. The information from the device layer varies according to the application: channel state, energy, power, user ID, etc. AI algorithms for improvement of wireless networks are expected to use heavily this interface, particularly in scenarios with non-stationary statistics.

Interface DL-SLM: This interface focuses on the multi-layer security with the device layer. Examples of this interface allow MAC-PHY algorithms to identify jammers or directions of eavesdroppers. Node identification using direction of arrival algorithms, or statistical signal processing are also possible. Redundancy of source and channel coding can also be used. AI for anomaly detection will exploit this interface.

Interface NL-CLM: In this interface, the network layer provides information to cross-layer optimization algorithms. Routes, addresses, traffic state, quality of service, etc. are some of the metrics and information that can be requested through this interface. AI algorithms for link/route selection are expected in this interface.

Interface NL-SLM: The network layer interacts with the security layer management via a set of specific protocols. Tunnelling, virtual links, security layers, etc. are examples of specific implementations of this interface.

Interface ECAL-CLM: This is an innovative interface analysed in InSecTT project. It defines the interactions between cloud computing platforms and cross-layer management. It is assumed that the cross-layer management and optimisation take place locally in the Bubble, whereas cloud computing takes place in the external L2 world. Therefore, this interface has close connection with modern approaches such as Edge or Fog computing.

Interface ECAL-SLM: The interface between cloud and security layer management.

Fig. 6

Information model

8 Information Model

The information model is crucial for the communication between different Bubbles. An information model deals on how the information is transported, encoded, formatted, encapsulated and how the resources are organized and managed, including aspects such as discovering, addressing, enumeration and scheduling. The information model also includes high level aspects such as semantics representation, transactions and business modelling. Figure 6 presents an example of an information model for the use case of wireless avionics. Typical technologies for format and encoding are the family of extensible markup languages (XML), TLV (Type-Length-Value) or CBOR (Concise Binary Digital Object). Advanced data exchange models can combine messaging and format encoding, for example JSON (Java Script Object Notation), the OWL (Ontology Web Language), Sensor ML (Mark up language), etc. For transport, solutions can be broadly divided in RESTful, which are request response , such as HTTP, MQTT, SOAP, and CoAP,etc. and publish/subscribe solutions that are more apt for real time applications. Multiple semantics solutions for IoT described in our previous paper for the DEWI architecture also fall in the information model here described. Resource description and discovery schemes with indexes or addresses is necessary in any information model (e.g., UDDI). This allows users of the information model to discover, invoke and use the available network resources through service oriented architectures.

Regarding AI solutions, there was no major modification of the protocols and transport/messaging solutions to enable the new layer of intelligence services. InSecTT proposed a unified database or repository of data sets generated for the different AI algorithms of the different sub-building blocks. The format used is mainly CSV, but there have been several exceptions to allow for different types of data. Several open issues were identified for future data set representation and encoding. In principle, the information collected from different parts of the network to provide the training of the learning models can provide a strain to some hardware and software interfaces, particularly those located at the edge of the network and in the lower layers. In addition, the work on verification and validation (V &V) of AI algorithms under impairments and security attacks highlights the issue of protecting the data sets and the learning infrastructure, leading to solutions for encryption, authentication, encoding, redundancy, etc. This means another increase of stress on the supporting infrastructure. In the trustworthiness studies, InSecTT also identified the need to protect the privacy of the data used for training the learning models, and perhaps extend the privacy protecting regulation to the storage of data sets, or even the information learned from the data sets (learned weights). This means ensuring the end user that privacy is protected in the full cycle of the learning and actuation process of future AI implementations.

9 AI Perspective of the Architecture

The work in InSecTT proposes an advance in the state of the art on how AI tools have an impact on IoT reference architectures. More specifically, our work has looked into the details of the different AI algorithms implemented in the different industrial domains and we have provided a recommendation on how AI can be adapted into modern IoT architecture or how to officially implement a new perspective of AI in the architecture (Fig. 7).

The AI algorithms can eventually form one or more perspectives that complement or that extend the views of the RA. The prime candidate was the addition of sublayers to the functionality model regarding different sub-functionalities that are common to typical AI algorithms. An example of modified functionality layer with specific AI of th project wsteps such as learning, feature extraction, class detection, model optimization, etc. is shown in Fig. 8.

Fig. 7

3D-model AI perspective of the RA

Fig. 8

2D-model AI perspective of the RA

A mapping of the requirements related to the different AI algorithms as conducted, producing a type of heating maps where the main AI-related functionalities reside in the functionality model of the project. An example is shown in Fig. 9.

The final AI perspective of the InSecTT RA is a 3D representation of the functional model of the RA (see Fig. 7). The extension consists of the functional decomposition of the learning mechanisms: data set collection, learning, training, storage, actuation, detection, observation, etc. In addition, we consider a second layer of the AI perspective that consists of the sub-building block representation of the project. This second layer of aggregation complements the first level and groups the types of AI algorithms , applications and puts them in perspective to be used or mapped to the use cases of the project.

Fig. 9

Mapping of functionalities of AI algorithms of BB2.1 AI for communications

10 Example Use Cases Alignment

10.1 Overview

We will show two examples of use cases and their preliminary alignment with the InSecTT RA. The full analysis is out of the scope of this paper. Therefore, we focus on the general overview of the two central models of the RA for two selected use cases. The first use case refers to a recent technology called wireless avionics intra-communications (WAICs). The second one is in the automotive domain targeting AI for wireless platoon intra-communications.

The term WAICs is used to describe any wireless sensor and/or actuator network operating on board an aircraft. While WAICs have been tested using multiple technologies and different frequency bands to verify potential interference to on-board equipment, this technology has been recently standardized by the ITU (International Telecommunications Unions) in the frequency bands of 4GHz (see [17,18,19,20]). WAICs is expected to be used mainly to replace or provide redundancy of wired infrastructure, such as control, sensing, and equipment management on board aircraft. In terms of cable infrastructure, gains can be expected for the reduction of aircraft design complexity. Reduced cable infrastructure also leads to weight losses, which in turn minimize fuel consumption, improve operational ranges and/or increase the size of the payload. In terms of configurability, wireless technology provides over-the-air (OTA) management and troubleshooting capabilities that facilitate network control and operation. Finally, wireless links can reach places of an aircraft difficult to cover with cables, thus facilitating design and reducing maintenance and troubleshooting costs for aircraft manufacturers.

Platoons are sets of cooperative autonomous or semi-autonomous vehicles with similar or identical routes that act as a single entity in terms of control and communication. The vehicles are usually arranged in linear convoys that communicate with each other control decisions that are usually made by one of the vehicles acting as leader or by a road side infrastructure with nearly real time traffic control information. The reliability of communication with low latency between the vehicular entities is critical to avoid any potential issue in the coordination between vehicles that could lead to safety issues. The emergence of 5G/6G technologies targeting ultra-low values of latency will enable the control of multiple autonomous or semi-autonomous vehicles in multiple platoons assisted by edge/cloud infrastructure.

10.2 Entity Model

The ITU recommendations define two types of WAICs network topologies depending on the location: internal or external to the cabin. The gateways are positioned in places to provide good coverage for the intended applications. The entities of a WAICs network can be rearranged as a Bubble of the InSecTT reference architecture. Sensors or groups of sensors can constitute an InSecTT Bubble node. Several Bubble Nodes can form a Wireless Sensor Network (WSN) which is assumed to be controlled by a WSN Gateway (WGW). One or more WSNs can be designed to operate in different parts of the aircraft, using different channels, different frequency bands or different hoping or spreading sequences. This reduces interference between WSNs. All the WSNs that belong to the same Bubble are assumed to be controlled by a unique InSecTT Bubble Gateway (BGW). The Bubble GW is therefore the central control entity of all Bubble Nodes and WSNs inside the aircraft information system. The WSNs are thus interlinked to each other and to the Bubble GW using the internal aeronautics bus network. The most used standard is ARINC 664 or the commercial version called AFDX (Avionics Full-Duplex Switched Ethernet). This technology is a modified version of the Ethernet standard based on the concept of virtual links that ensure real-time and deterministic deadline allocation. The concept of Bubble is especially fit for aeronautical applications, where L1 is the internal, real time aircraft network, L0 is the wireless links, and L2 is the cloud external connection of the aeronautical Bubble. We should emphasize that there are other ways of configuring the aeronautical infrastructure to have different deployments of the InSecTT Bubble. For example, different Bubbles can be operating in the same aircraft using an external L2 technology to achieve communication between Bubbles. The use of one Bubble per aircraft is illustrated in Fig. 10 for the aeronautical use case.

Fig. 10

Example of a WAICs network using the Bubble concept

In the automotive use case, each platoon can be considered as a Bubble, with the leader being the Bubble Gateway (see Fig. 11, top sub-figure). The Bubble Gateway uses a 5G link to connect to the Cloud. In addition, each node of the Bubble has also a link with the 5G BS/RSU. In this case, we can consider that the 5G RSU/BS is a direct connection with a virtual Bubble Gateway, as the 5G Base Station (BS) acts as relay and assistant of the main Bubble GW. This leads to an interesting feature of the Bubble and InSecTT architecture. The physical Bubble GW is not the unique access point to the Bubble Nodes from the external world. Nodes can have another link to the outer Bubble space using another direct cloud interface. This issue paved the way to the concept of virtual Bubble Gateway to control the connections to the Bubble using modern devices with multiple interfaces. This preserves the properties of the Bubble in a modern multiple interface environments.

The platoon-BS architecture can also be adapted in a different way to the InSecTT RA by considering that nodes can communicate with two WSN gateways over two different L0 technologies. The 5G link can be regarded as L1 technology, and the Bubble GW is represented by the 5G BS. This is also illustrated in Fig. 11 (the bottom sub-figure). This last option implies that the 5G BS or RSU are included in the Bubble, and therefore it can be inadequate for high mobility scenarios.

Fig. 11

Example of a Platoon network using the Bubble concept

10.3 Functionality model

In both use cases we have mapped all the requirements to the functionality model in Fig. 5. This information is useful to identify the type of functionality needed in each scenario of the use case and the different interfaces with other functionalities or building blocks. The functionality model of the two uses cases are shown in Figs. 12 and 13 for the WAICs and platoon use cases, respectively. The detailed functional decomposition is the basis for trustworthiness metrics evaluation. Each function of a use case is weighted by a vector of trustworthiness metric using different models. An overall composite metric can be calculated per entity or per Bubble. This methodology allows us to find potential issues, vulnerabilities or strengths of different building blocks.

Fig. 12

Functional model WAICs use case

Fig. 13

Functional model platoon use case

10.4 Interfaces

The mapping between the entity and functionality models provides the detailed information of software and hardware interfaces. Interfaces between entities are hardware interfaces, while interfaces between layers of the functionality model are software interfaces. An example of this bi-dimensional mapping for the aeronautics use case can be seen in Fig. 14. This bi-dimensional mapping provides a good overview of the communication protocols per layer and per entity and the type of software related to the encapsulation of each layer of the functionality model. The guidelines for trustworthy design of the InSecTT RA include the expertise in the design of each one of these interfaces to improve a number of metrics or solve different security/safety issues. This is done using empirical and/or numerical metric models.

Fig. 14

Mapping functional versus entity models of the aeronautics use case

10.5 General Project Overview for Architecture Alignment

The main aspect considered in the preliminary analysis of the use cases of the project is the identification of the Bubble and possible configurations. In transportation systems, it was observed that at least two different ways are distinguished regarding the definition of the Bubble. For example, in autonomous diving use cases, the Bubble can be defined on each vehicle. However, in coordinated transportation systems, the Bubble can include multiple nodes or entities. Even in some cases, the Bubble may or not include the edge gateway in the road side units or the fixed access point. This selection depends on the needs of each use case. A similar approach can be followed for other types of use cases. For example, in the healthcare domain, the Bubble can be defined on the basis of isolation of entities or patients. Body area networks can lead to define an individual Bubble for each patient, but in some cases it is better to define Bubble for a full patient room or ward. In manufacturing, the Bubble can also be defined using the isolation provided between Bubble gateways. We recall that each Bubble can have several wireless sensor networks, using L1 technology to organize and schedule a different WSNs with potentially different technology. This makes the Bubble concept very flexible to adapt to a variety of scenarios, even with dynamic decomposition of the Bubble. The concept of virtual gateway allows us to expand the concept of Bubble to long range direct cloud connections with 5G and 4G technologies. This adds an extra degree of flexibility with the definition of the Bubble that can be adapted to different scenarios in manufacturing, for example logistics, tracking, access control, and V2I solutions.