Date: 11/02/2025
The EUCloudEdgeIoT (EU-CEI) initiative defines a reference architecture for the continuum to be promoted as a standard. EU-CEI has identified eight categories, the Building Blocks (BBs) of a computing continuum infrastructure, representing the technical processes to operate applications along the continuum. Its motivations and goals are compatible with the MYRTUS technologies and objectives and during the first year of the the project, we made the effort to frame the MYRTUS technologies in the context of the EU-CEI reference architecture.
The goal of this activity is, on one hand to make a first step towards the standardization of the MYRTUS technologies. On the other hand, MYRTUS aims at feeding/contributing to EU-CEI by providing 1) concrete implementation examples on real test cases for all the BBs, and 2) an additional BB.
Table I shows a summary of the framing effort. The infrastructure and its management are strongly interleaved and there cannot be a complete distinction between EU-CEI BBs pertaining just to the MYRTUS technical pillar 1 or to the MYRTUS technical pillar 2.
For example, in terms of resource management and orchestration, specific support at the infrastructure level will be provided by Kubernetes, while at the Cognitive Engine level, in combination with the AI BB, decisions for orchestrating the tasks over resources will be made.
The EU-CEI reference architecture does not address the problem of turning applications into executable implementations. This is non-trivial for architectures that rely on heterogeneous families of CPUs and it becomes progressively more challenging as HW accelerators are introduced in the architecture. As the MYRTUS-compliant continuum infrastructures comprise heterogeneous and reconfigurable computing components the need for a DPE, MYRTUS technical pillar 3, emerged as a fundamental BB to enable the use of the continuum architecture.
| EU-CEI BUILDING BLOCKS | MYRTUS IMPLEMENTATION |
|---|---|
| Security and Privacy – Mechanisms for secure data and transactions between different components. Trust and Reputation – Models for allowing users of a continuum platform to generate trust in providers or increase their reputation (mainly in federated models). | Built-in infrastructure mechanisms, design and runtime strategies are envisioned, including: 1) authorization and authentication mechanisms of users/resources, 2) support for data integrity and availability, based on trustable, accessible, and coherent data exchange, 3) implementation of secure communication schemes, and 4) support for system integrity leveraging design time threat analysis and exploiting trust-related KPIs to implement trust and reputation schemes at runtime. |
| Data management – It includes collection, storage, computation, and actions performed over data. | Functionalities, storage, and processing capabilities are layer-/component-dependent. The envisioned resources heterogeneity allows capturing a wide variety of requirements challenging the DPE. |
| Resource management – It entails management of physical infrastructures and individual devices. Orchestration – Distributions of workloads, data or resources for executing a given action. | Kubernetes is used as a low-level orchestrator; while, the MIRTO Cognitive Engine covers the high-level orchestrator role, handling scalability without compromising QoS and heterogeneity. Aligned with EU-CEI vision, MIRTO optimization goals include latency reduction, throughput increase, and improved reliability without sacrificing security, privacy and trust. In addition, MIRTO aims also to reduce energy consumption. |
| Network – Connectivity considerations, including private networks and activities such as network slicing. | MYRTUS, by construction, aims to define a multi-layer infrastructure set-up. To foster seamless WL balance at runtime, MYRTUS computing components will embed identical interfaces and support the same protocols. Moreover, optimal network resource management to balance, where possible, load and latency is one of the drivers for runtime optimization. |
| Monitoring and Observability – It is intended at infrastructure level, including telemetry, and service/ application level. | In line with EU-CEI monitors classification, we foresee: 1) Application monitoring (status of the application to identify underperformance issues not related to network/devices), 2) Telemetry monitoring (connectivity status and information loss), and 3) Infrastructure and Resource monitoring (status of the components). Observability will be achieved by the MIRTO Cognitive Engine leveraging a distributed KB to make smart decisions. |
| Artificial Intelligence (AI) – It is expected to be embedded in most of the activities performed. | MIRTO Cognitive Engine implements a plethora of different intelligence strategies to master WLs and resources orchestration at runtime. |
This is an extract of the MYRTUS paper accepted at DATE 2025.
Check the preprint of the MYRTUS contribution on Zenodo.
