# CRAFTER: causality-based self-adaptation for autonomous IoT systems

Houssam Hajj, Ajay Kattepur, Denis Conan, Georgios Bouloukakis

► To cite this version:

Houssam Hajj, Ajay Kattepur, Denis Conan, Georgios Bouloukakis. CRAFTER: causality-based self-adaptation for autonomous IoT systems. 21st International Conference on Software Engineering for Adaptive and Self-Managing Systems (SEAMS 2026), Apr 2026, Rio de Janeiro (BRAZIL), Brazil. 10.1145/3788550.3794868. hal-05502288

HAL Id: hal-05502288

https://hal.science/hal-05502288v1

Submitted on 10 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

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

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# CRAFTER: Causality-based Self-Adaptation for Autonomous IoT Systems

Houssam Hajj Hassan

houssam.hajj_hassan@telecom-sudparis.eu
Télécom SudParis, Institut Polytechnique de Paris
France

Denis Conan

denis.conan@telecom-sudparis.eu
Télécom SudParis, Institut Polytechnique de Paris
France

Ajay Kattepur

ajay.kattepur@ericsson.com
Ericsson Research Artificial Intelligence
India

Georgios Bouloukakis

gbouloukakis@upatras.gr
Department of Electrical and Computer Engineering,
University of Patras
Greece
Télécom SudParis, Institut Polytechnique de Paris
France

## Abstract

This paper presents CRAFTER, an automated framework for designing and deploying self-adaptive IoT systems using Causal Reinforcement Learning (CRL). As IoT devices increasingly populate pervasive computing spaces, smart environments are enabled with advanced monitoring and interactive services. The dynamic nature of these environments, such as fluctuating workloads and evolving application demands, poses significant challenges in maintaining consistent Quality of Service (QoS) levels of IoT applications. While existing self-adaptation techniques offer adaptive capabilities, they are often designed to deal with specific application domains, hindering the design of self-adaptive solutions that can be re-used across multiple IoT verticals. In addition, there is a lack of automated pipelines that act on identifying key performance drivers to take effective adaptation decisions. CRAFTER addresses these issues by using *Causality* as a formal framework for performance analysis of IoT systems. CRAFTER generates causal graphs to uncover dependencies among system components and guide adaptation decisions based on cause-effect relationships. Then, adaptation agents can leverage this knowledge to take more effective adaptation decisions in dynamic situations. Our experimental evaluation demonstrates how CRAFTER enables deriving causal graphs spanning diverse IoT use cases. Furthermore, we showcase how CRAFTER improves self-adaptation performance by 25% compared to state-of-the-art Reinforcement Learning-based approaches.

## CCS Concepts

* Computer systems organization → *Sensor networks*; *Reconfigurable computing*; * Computing methodologies → Reinforcement learning*; *Causal reasoning and diagnostics*; *Intelligent agents*.

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

This work is licensed under a Creative Commons Attribution 4.0 International License.
SEAMS '26, *Rio de Janeiro, Brazil*

© 2026 Copyright held by the owner/author(s).
ACM ISBN 979-8-4007-2445-9/2026/04
https://doi.org/10.1145/3788550.3794868

## Keywords

Self-adaptive systems, IoT, Causal discovery, Reinforcement Learning

## ACM Reference Format:

Houssam Hajj Hassan, Ajay Kattepur, Denis Conan, and Georgios Bouloukakis. 2026. CRAFTER: Causality-based Self-Adaptation for Autonomous IoT Systems. In *21st International Conference on Software Engineering for Adaptive and Self-Managing Systems (SEAMS '26), April 13–14, 2026, Rio de Janeiro, Brazil*. ACM, New York, NY, USA, 13 pages. https://doi.org/10.1145/3788550.3794868

## 1 Introduction

In today's pervasive computing environments, Internet of Things (IoT) devices enable smarter spaces that offer enhanced monitoring and interactive services. Such IoT services and applications have become mainstream within multiple systems, such as smart homes, smart agriculture, or smart building automation. With the increasing integration of IoT sensors within consumer devices, a new generation of devices has emerged: virtual, augmented and mixed reality (XR). Software and inter-networking of these XR devices, along with advances in Edge computing and novel networking technologies (6G) have led to the emergence of *Metaverse* applications [49].

The Metaverse provides a realistic way to reflect real-world environments that include famous landmarks (Eiffel tower, Statue of Liberty) or places that are familiar to individuals (home, school) through Digital Twin (DT) replicas. For this purpose, Metaverse applications rely on IoT devices to capture real-time data from physical spaces, which is then synchronized with virtual environments to create immersive and interactive experiences. The integration of these applications with physical environments relies on advanced IoT platforms consisting of devices that sense physical phenomena and generate data. This data is then processed, filtered, or aggregated before being used by applications [46]. Given this complexity, the performance of IoT applications largely depends on the ability of IoT systems to meet stringent Quality of Service (QoS) requirements, such as low latency, high availability, and accuracy.
However, modern smart spaces are inherently dynamic and unpredictable. Changes in the number of IoT devices, network conditions, and available computational resources create a continuously evolving environment. For example, during major public events such as concerts or sports games in a large-scale smart city infrastructure, the influx of thousands of visitors can cause a significant surge in demand for IoT-enabled services such as real-time traffic management, public safety surveillance, and smart parking systems. This sudden spike in data traffic and sensor activity can result in network congestion and resource bottlenecks at Edge servers. To ensure that IoT systems can effectively adapt to changes while maintaining strict QoS requirements, it is essential to leverage self-adaptation techniques within these systems. Self-adaptive solutions monitor system performance and respond to changes, adjusting configurations in real-time to avoid performance degradation. Several existing approaches [1, 3, 22, 31, 33, 46, 56] have explored self-adaptive mechanisms for IoT systems, focusing on monitoring QoS metrics like network congestion and resource utilization. However, these solutions often fall short by neglecting the broader context in which IoT systems operate. They typically rely on reactive measures, failing to predict and prevent issues before they lead to QoS violations [1]. In addition, the majority of these works do not offer formal approaches for investigating the causes of QoS violations; adaptation decisions are often solely based on changes in QoS metrics [1, 22, 31, 56]. Nevertheless, context information provides valuable insights into *when* and *how* to take adaptation decisions. More importantly, adaptation logic in prior work is typically tailored to specific application domains, limiting reuse and requiring domain expertise.

This paper introduces CRAFTER, a causality-based self-adaptation solution for autonomous IoT systems. The core contribution of CRAFTER lies in its application-independent approach for causal graph generation, enabling the identification of context and performance variables that influence system behavior. This enables creating a semi-automated pipeline that allows IoT system developers to follow the same approach for designing self-adaptation solutions approaches across diverse environments, whether in smart cities, homes, or industrial settings. In addition, the causal graph generation process requires minimal domain expertise, reducing human intervention in the self-adaptation pipeline.

To enable the design of such an automated pipeline, CRAFTER first relies on Causality [35] as a theoretical framework for the analysis of IoT systems' performance. This enables defining a formal methodology for identifying causal relationships among the different variables in a smart space. CRAFTER then integrates Causal models with decision-making approaches such as Reinforcement Learning (RL) [44] to take informed adaptation decisions that account for both QoS and contextual factors affecting performance. CRAFTER enhances the reliability of modern autonomous IoT systems through the following key contributions:

- A semi-automated approach for designing self-adaptive IoT systems across heterogeneous smart environments.

- A formal methodology for performance analysis using Causal Models.

- An automated Causal RL (CRL) pipeline to take informed adaptation decisions in dynamic environments.

<figure><img src="image_3.png" /><figcaption>Figure 1: Smart museum scenario</figcaption></figure>

- An open-source prototype implementation showing CRAFTER's effectiveness in self-adaptive IoT systems.

The remainder of the paper is organized as follows. Section 2 presents an overview of CRAFTER starting from a motivating use case to highlight the need for autonomous adaptation in IoT environments. Section 3 formally presents the CRAFTER IoT system model. We detail our solution in Section 4, and provide an experimental evaluation of CRAFTER in Section 5. In Section 6, we provide an overview of related work. Section 7 goes over the limitations of CRAFTER, and Section 8 concludes the paper with future directions.

## 2 The CRAFTER Approach

We first highlight the challenges in maintaining QoS requirements of applications in dynamic environments in Section 2.1 through a motivating use case. We then illustrate in Section 2.2 the challenges designing generic self-adaptation solutions across different IoT domains. Finally, we provide an overview of how CRAFTER addresses these challenges in Section 2.3.

### 2.1 Le Louvre Scenario

To illustrate the complexity and challenges involved in designing self-adaptive IoT systems, we consider a representative example: the Louvre Museum in Paris. This scenario exemplifies the operation of a large-scale, dynamic IoT environment where diverse devices and applications are deployed to serve multiple stakeholders, each with distinct QoS requirements. In addition, this scenario demonstrates the challenges associated with low-latency requirements and how CRAFTER addresses such challenges.

Le Louvre is divided into three sectors (Richelieu, Sully, and Denon), and each sector comprises several exhibition rooms that contain sculptures, artifacts, and paintings spanning various civilizations and cultural movements. Le Louvre administrators wish that everyone, including people not physically present in Paris, is able to explore works of art displayed in the museum and participate in interactive events. For this purpose, a DT replica of Le Louvre is created and deployed in the Metaverse, where remote visitors (*meta-occupants*) are able to visit Le Louvre virtually. The DT replica (*Le Louvre sub-metaverse*) captures *static* properties of Le Louvre including the organization of sectors, and placements of works of art. Additionally, to provide a realistic and immersive experience, Le Louvre sub-metaverse should accurately reflect the *dynamic* conditions of Le Louvre in real-time. For this purpose, IoT devices are used to provide: (i) data from light sensors for a realistic lighting conditions, (ii) noise data for a realistic acoustic experience,
(iii) visitors' movements to reflect crowd conditions in exhibition rooms, and (iv) location of artifacts (e.g., temporary exhibitions).

As shown in Figure 1, to provide such monitoring and inter-active capabilities, IoT devices are deployed to monitor artifacts (motion sensors, RFID tags), visitors (cameras), and ambient conditions (temperature/humidity sensors, smoke detectors). Device data may additionally be processed by *Virtual Sensors* before being consumed by applications [46]. For example, video frames may be analyzed and aggregated with motion and WiFi data to provide more accurate estimations of the occupancy in each exhibition room. Finally, applications receive data to provide services for different stakeholders. For instance, Le Louvre security personnel may use a dashboard that shows monitoring information in different sectors of the museum, and visitors may use a dedicated application for checking waiting times in different exhibition rooms.

## 2.2 Challenges in Designing Portable and Generic Self-adaptation Solutions

The Louvre scenario illustrates the complexity of deploying self-adaptive IoT applications in dynamic, multi-stakeholder environments. While many approaches for deploying self-adaptive systems exist in the literature, they are often designed in an ad hoc, domain-specific manner, making them difficult to generalize or reuse across different application domains (e.g., smart museums, factories, or cities) [51]. We identify two key limitations in existing approaches for designing self-adaptive IoT systems:

1. Designing effective self-adaptation logic today still requires significant domain expertise [52, 55]. Developers must identify – either manually or with the help of a domain expert – which context and performance variables are most relevant, understand their relationships, and encode specific adaptation strategies. This process is often manual, time-consuming, and difficult to replicate across different domains.

2. Existing self-adaptive systems lack a systematic and reusable approach for identifying what to adapt and when [19, 51]. Most solutions rely on reactive, rule-based mechanisms or machine learning models trained on domain-specific datasets. These approaches often fail to generalize or provide explainability.

Given these challenges, there is a clear need for self-adaptation frameworks that are not only capable of responding to dynamic environments, but that also facilitate re-usability and that are generalizable across domains. CRAFTER addresses this gap through Causal Reinforcement Learning techniques to automate the design of adaptation logic and enable its reuse across deployments. We provide next an overview of CRAFTER's high-level architecture.

## 2.3 CRAFTER Overview

CRAFTER offers causality-based self-adaptive capabilities for modern IoT systems to enhance their autonomy, reliability, and ensure that QoS levels of applications are maintained, even in dynamic environments. This is achieved by identifying causal relationships among variables that affect the performance of the IoT system. This knowledge drives more efficient decision-making at runtime.

To achieve this, Figure 2 shows how CRAFTER is exploited in two phases: (1) at *design-time* for its deployment in smart environments;

<figure><img src="image_4.png" /><figcaption>Figure 2: CRAFTER's high-level architecture</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Figure 3: CRAFTER's integration within the MAPE-K loop</figcaption></figure>

and (2) at *runtime* for enabling autonomous and efficient decision-making of adaptation agent. Figure 3 shows CRAFTER's integration within the MAPE-K adaptation loop [25].

*Design-time phase.* CRAFTER can be deployed in any IoT environment at design-time to extract causal relationships within the IoT system. For this purpose, an *IoT metrics dataset* is required: this can be realistic historical data collected through prior monitoring of the smart environment, and/or synthetic datasets generated with DT approaches or ML-based dataset generation techniques [21, 48]. For a more comprehensive understanding of the system behavior, it is important that the dataset is also enriched with context information, such as date/time of day, location of devices, number of occupants, and other contextual information that is relevant to the smart environment. Such context information allows the generation of richer causal graphs, and subsequently enables adaptation agents to take better quality adaptation actions. However, note that this is not mandatory and we do not require any additional processing or labeling of the dataset. CRAFTER accepts as input regular datasets that can be collected from monitoring platforms deployed in smart spaces (in csv format, which requires minimal processing). Then, *Causal Models* are generated through *Causal Discovery* [54]; these represent the dependencies among the different features (e.g., resource consumption, number of visitors) captured in the dataset (more details are provided in Section 4.1). To obtain more accurate causal graphs, domain knowledge may be incorporated through expert elicitation, and/or IoT representations of smart spaces, such as Ontologies [4, 5, 40]. The obtained causal model serves a dual purpose. First, the graph is used by the *Performance Explainer* to explain the behavior of the IoT system to domain experts by showing causal relationships that can enhance business decisions or enable better tuning of configuration parameters for
improved QoS of applications. Second, the causal graph enables efficient self-adaptation in dynamic situations by identifying the leading causes of performance degradation, including both QoS metrics (e.g., resource consumption) and context information (number of occupants, day and time, etc.). These are then used by the *States Modeller* to model the most important states to be observed by the *Adaptation Agent*.

**Runtime phase.** At runtime, the deployed IoT system and its applications become autonomous, guided by a generated causal graph that enables precise and effective adaptation actions. Unlike traditional RL models that may react to changes only when QoS metrics change, the causal graph allows the *Adaptation Agent* to identify and act on key factors that lead to such degradation. By observing states defined by the causal relationships, the *Adaptation Agent* can take preemptive and more efficient actions through the *Action Selector*, addressing potential issues before they manifest as performance problems. For instance, in Le Louvre scenario, a higher number of occupants leads to a higher workload on processing nodes. When this relationship is learned, the *Adaptation Agent* can monitor the number of occupants as a leading indicator of potential QoS degradation. Instead of waiting for processing nodes to become overloaded, which could lead to higher latency or data loss, CRAFTER enables early adaptation by reconfiguring resources as the number of occupants increases. This automated approach reduces the likelihood of QoS degradation, ensuring that applications' QoS levels are maintained in changing conditions. The causal graph also helps in resolving hidden dependencies that might not be immediately apparent, allowing the system to adjust in ways that would otherwise be overlooked by purely reactive methods. For instance, if an increase in noise level is found to be an indicator of a high number of occupants, the system can proactively increase available resources to avoid performance degradation.

CRAFTER's integration within the MAPE-K loop. Figure 3 shows how CRAFTER components fit within the different phases of the MAPE-K loop [25]. The Monitor (M) phase includes the collection of the IoT metrics dataset through IoT monitoring platforms. This dataset is then used in the Analyze (A) phase by causal discovery algorithms to generate the causal graphs. The IoT metrics dataset and the generated causal graph constitute the Knowledge Base (KB – K), and are continuously updated to account for changes. The Planning (P) phase involves the RL agent taking adaptation actions in response to changing conditions of the environments, and the Execute (E) phase applies the adaptation actions to the Managed System (i.e., the IoT environment).

# 3 Modelling Dynamic IoT Environments

This section presents a formal description of target IoT systems for which CRAFTER is designed, followed by a formal definition of the self-adaptive QoS problem in the IoT.

## 3.1 IoT System Formal Model

We rely on the publish/subscribe architecture [17] to model data exchange between the components of the IoT system. For this purpose, a dedicated message broker is deployed for receiving, filtering, and forwarding messages based on topic-based subscription filters.

We consider that a smart space is divided into various locations $\mathcal{L}$, where each location $l_i \in \mathcal{L}$ contains a set of deployed IoT devices $\mathcal{D}(l_i)$. A device $d_j$ provides one (or more) observation $o_j$ capturing a physical property that is specific to its location. For example, a smoke detector provides an observation related to “smoke” in “exhibition hall 1”. $d_j$ publishes data to one or more topics $T_{d_j}$; we compose topics by coupling the observation $o_j$ with the location $l_i$ where the device is deployed. Hence, a temperature sensor that is deployed in “exhibition hall 3” publishes data to the topic hall3/temperature. Devices either generate data periodically (e.g., temperature sensors), or in an event-driven manner (e.g., a motion sensor) following a probability distribution (e.g., normal distribution). The data generation rate of each device is defined as $\lambda_{d_j}$. Therefore, the total traffic generated by all devices in a location is the sum of the individual rates, denoted as $\lambda_{l_i} = \sum_j \lambda_{D(l_i)}$. Note that this traffic can be collected and processed from CRAFTER components to create an IoT metrics dataset $\mathbf{D}$.

Devices in the same location connect to a shared network switch $\mathcal{X}_i$ that has specific QoS characteristics such as bandwidth $w_i$, link delay $\Delta_i$ and loss rate $\omega_i$. To enhance sensing capabilities, a set of virtual sensors VS is deployed to process data from IoT devices and produce high-level observations. For example, motion and camera data may be combined to create a new “room occupancy” observation. For this purpose, a set of dedicated Edge nodes $E$ are available for hosting virtual sensors. Each edge node $e_i \in E$ offers resources related to processing power, memory, and disk space; we denote these characteristics by the tuple $\rho(e_i) = (e_i.proc, e_i.mem, e_i.disk)$. Each virtual sensor $vs_j \in VS$ subscribes to a set of topics $T_{vs_j}^{sub}$ to receive and process relevant data, and publish new observations to $T_{vs_j}^{pub}$. The processing time of a virtual sensor $\tau_{vs_j}$ depends on the rate at which it receives data, the processing algorithm/technique used, and the available resources of the Edge node where $vs_j$ is deployed. To offer monitoring capabilities and interactive services to the smart space administrators and occupants, a set of applications $A$ are deployed. Each application $a_i \in A$ subscribes to a set of topics $T_{a_i}$ to receive data of interest from devices and virtual sensors. Since applications may be used by different stakeholders, an application defines a set of requirements $a_i.qos$ representing QoS metrics that need to be satisfied. For instance, a security dashboard application specifies that the tail latency $\delta_{tail}$ should be less than 2 seconds, and the minimum throughput $\Theta_{min}$ greater than 4 Mbps. As described in Section 2.1, a DT replica of the smart space may also be available for meta-occupants to virtually join the space. We denote such applications by $a_i^{\text{meta}} \in A^{\text{meta}}$.

## 3.2 The Self-Adaptive QoS Management Problem

To ensure correct application behavior, space administrators typically configure their systems to sustain the required QoS levels. However, as smart spaces are dynamic environments, multiple changes usually occur that affect the QoS requirements of applications. These can be changes in $\lambda_{l_i}$, the utilization of Edge resources $U(e_i)$, or changing QoS requirements $a_i.qos$ and thus, self-adaptive solutions should be deployed to adapt to these changes. Hence, for an application $a_i$ with QoS requirements $a_i.qos = (\delta_{max}, \Theta_{min}, \omega_{max})$,
<table><caption>**Table 1: Parameters notations in CRAFTER's IoT model.**</caption><thead><tr><th>Notation</th><th>Description</th><th>Notation</th><th>Description</th></tr></thead><tbody><tr><td>$I_i \in \mathcal{L}$</td><td>locations</td><td>$e_i \in E$</td><td>Edge nodes</td></tr><tr><td>$d_j \in \mathcal{D}(I_i)$</td><td>devices in $I_i$</td><td>$\rho(e_i)$</td><td>Edge Resources</td></tr><tr><td>$o_j$</td><td>observations from $d_j$</td><td>$\text{vs}_j \in \text{VS}$</td><td>virtual sensors</td></tr><tr><td>$T_{d_j}$</td><td>$d_j$'s topics</td><td>$T_{\text{vs}_j}^{\text{sub}}, T_{\text{vs}_j}^{\text{pub}}$</td><td>$\text{vs}_j$'s topics</td></tr><tr><td>$\lambda_{d_j}$</td><td>$d_j$'s publication rate</td><td>$\tau_{\text{vs}_j}$</td><td>$\text{vs}_j$'s processing delay</td></tr><tr><td>$\lambda_{I_i}$</td><td>data traffic per $I_i$</td><td>$a_i \in A$</td><td>applications</td></tr><tr><td>$w_i$</td><td>bandwidth</td><td>$T_{a_i}$</td><td>$a_i$'s topics</td></tr><tr><td>$\Delta_i$</td><td>link delay</td><td>$(\delta, \Theta, \omega)$</td><td>latency, throughput, loss rate</td></tr><tr><td>$\omega_i$</td><td>loss rate</td><td>$(\mu_{\text{qos}}, \mu_{\text{context}})$</td><td>system, context properties</td></tr></tbody></table>

the following conditions must be satisfied at any time $t$:

$$ \delta \le \delta_{\max}; \quad \Theta \ge \Theta_{\min}; \quad \omega \le \omega_{\max} \quad \forall t \quad (1) $$

Typically, to detect performance issues, a set of metrics are continuously monitored to provide insights into the performance of the system [1]. In addition to the QoS requirements of applications, this set contains (i) network characteristics ($w_i$, $\Delta_i$, $\omega_i$, ...); (ii) resource usage of Edge nodes $U(e_i)$; (iii) number of devices $|D|$ and applications $|A|$. We refer to this set of monitored QoS metrics by $\mu_{qos}$ [1]. Usually, when changes in $\mu_{qos}$ cross a threshold, adaptation actions are executed manually or through an automated process [1]. However, when such changes are detected, this often implies that QoS violations already occurred. This happens because $\mu_{qos}$ are chosen arbitrarily or through experts' domain knowledge.

To solve these issues, CRAFTER relies on a formal methodology for identifying key variables driving the performance of the IoT system and affecting the QoS requirements of applications. In particular, CRAFTER leverages Causal Discovery for identifying, alongside $\mu_{qos}$, context variables (denoted by $\mu_{context}$) that contribute to fluctuations of the IoT system performance. Such variables may include day, time, weather, location, number of occupants in location, noise levels, and other context information found to affect the system performance. Monitoring $\mu_{context}$ in addition to $\mu_{qos}$ contributes to the early detection of QoS violations. The identified variables empower the decision-making process of the Adaptation Agent that is able to take more efficient adaptation actions. The next section provides further details about this process.

# 4 Enabling Causality-based Adaptation

CRAFTER leverages the causality framework [35] as a formal theoretical methodology for identifying cause-and-effect relationships in IoT systems through observational data, including context information. More specifically, based on an IoT metrics dataset D, causal models are generated to identify $\mu_{qos}$ and $\mu_{context}$. These are then used as drivers for informed decision-making.

## 4.1 Identifying Causal Relationships in IoT Systems

Causality relies on a formal description of the interactions between observed variables in the form of a *causal graph*. Unlike black-box techniques, where predictions about an outcome are made with a pure data-driven approach, such graphical representation is effective when it comes to *explainability* [6, 35, 54]. For this purpose, CRAFTER generates a causal graph to: (i) help domain

experts understand the behavior of their IoT systems, (ii) identify key metrics influencing the performance of the system, and (iii) take more effective adaptation actions in response to changes.

**DEFINITION 1.** (Causal graph). A causal graph G (also called Causal Graphical Model) is the graphical representation that depicts the cause-effect relationships among variables in a given system. $G = (V, E)$ is structured as a Directed Acyclic Graph (DAG), where $V = \{\mu_{qos} \cup \mu_{context}\}$ are variables in the system and $E \subseteq V \times V$ show causal effects (increase/decrease in latency, etc.). G represents a joint probability distribution P over a set of random variables $X = (X_1, X_2, ..., X_d)$ where P is Markovian with respect to G.

Through causal graphs, CRAFTER is able to recognize the causes of QoS violations. This happens by identifying direct and indirect causes of QoS changes:

**DEFINITION 2.** (Direct and indirect cause) For each directed edge $(X, Y) \in E$, X is a direct cause of Y and Y is a direct effect of X. Recursively, every cause of X that is not a direct cause of Y, is an indirect cause of Y.

<figure><img src="image_6.png" /><figcaption>**Figure 4: Causal Graphical Model**</figcaption></figure>

Consider Figure 4 with a sample causal graph that represents possible causal relationships in an IoT system. The graph shows that the computing resources and data traffic are a direct cause of latency. In addition, since there is a direct path from day of the week to latency, we define day of the week as an indirect cause of latency. We can further quantify the effects of causes on variables by building on the language of *Structural Causal Models* to describe the collection of mechanisms underpinning a phenomenon.

**DEFINITION 3.** (Structural Causal Model (SCM)). A structural causal model $M$ is defined by a 4-tuple $\langle V, U, \mathcal{F}, P(U)\rangle$:

- $V$ is a set of endogenous variables i.e., observable variables within the system that are determined by variables in the model. In IoT systems, these are the variables included in the set $\{\mu_{qos} \cup \mu_{context}\}$.

- $U$ is a set of exogenous variables, i.e., unobservable variables where $V \cap U = \emptyset$. As shown in Figure 4, even though visitor's behavior (e.g., preferences regarding exhibition halls) directly affects latency, CRAFTER would not observe this variable since it can neither be controlled nor monitored by the system. Such variables cannot be found in $\{\mu_{qos} \cup \mu_{context}\}$.

- $\mathcal{F}$ is a set of functions $f_i$, ..., $f_n$, where each $f_i \in \mathcal{F}$ is defined as $f_i : (V \cap U)^p \to V$, with $p$ the ariety of $f_i$ so that $f$ determines completely the value of $V_i$. $f_i$ enables quantifying the effect of changing a variable in G on its child. For instance, a 2x increase in network traffic may result in a 1.5x increase in latency, i.e., $f(\text{latency}) = 1.5 \times \text{network traffic}$.
- $P(U)$ is the joint probability distribution over the exogenous variables $P(U) = \prod_i P(U_i)$.

In most application domains, the causal graph may only be partially known by experts. To better understand a system behavior, CRAFTER recovers the complete causal graph.

**DEFINITION 4.** (The causal discovery problem). The causal discovery problem consists in recovering the true graph $G^*$ from a given dataset $D$.

This requires CRAFTER to find $V = \{\mu_{qos} \cup \mu_{context}\}$ by relying on a causal discovery algorithm.

**DEFINITION 5.** (Causal Discovery Algorithm). A causal discovery algorithm is said to solve the causal discovery problem iff. it converges to the true graph $G^*$ in the limit of the sample size of the dataset $D$.

Such algorithms aim to identify the underlying DAG representing the causal influences in a system. Popular examples include the Peter and Clark (PC) [43], Greedy Equivalence Search (GES) [11], and the Fast Causal Inference (FCI) [43] algorithms. Note that causal discovery algorithms are typically non-deterministic, and therefore it is necessary to validate the generated causal graph with domain experts to validate their correctness. The dataset quality and richness affects the graph quality, and therefore it is better to include as many relevant variables as possible when collecting the dataset.

In some systems, a cause-effect pair is known to exist (or to not exist) a priori, e.g. through domain expert's elicitation. With CRAFTER, domain experts can explicitly represent such pairs via a knowledge base used by the causal discovery algorithm to inform and constrain the structure of the causal graph. This can be achieved either manually by domain experts, or by using existing Ontologies that represent the IoT system.

**DEFINITION 6.** (Knowledge base). A knowledge base $\mathcal{K}$ is defined as an ordered pair $(\mathbf{R}, \mathbf{F})$ where $\mathbf{R}$ is the set of required directed edges, while $\mathbf{F}$ is the set of forbidden directed edges.

## 4.2 CRL-based Adaptation

CRAFTER relies on Reinforcement Learning [44] as a decision-making approach for taking adaptation actions for satisfying the QoS requirements of applications in IoT environments. However, unlike traditional approaches where states and actions are chosen regardless of causal relationships, CRAFTER enhances decision-making abilities by using the insights gained from causal graphs. The generated causal graph is used to define the set of states and actions that the CRAFTER adaptation agent can act upon. This process can be achieved either manually, or by using automated approaches to convert nodes in the causal graph to states and actions. We provide next a formal definition of the RL problem this paper deals with.

Reinforcement Learning requires an agent to interact with an environment over time to learn the best action(s) to take under specific situations, to optimize an objective function (e.g., minimizing latency). At each time step $t$, the agent receives a state $s_t$ in a state space $\mathcal{S}$ and selects an action $\alpha_t$ from an actions space $\mathcal{A}$, following a policy $\pi(\alpha_t | s_t)$. The policy represents the agent's behavior, i.e., a mapping from $s_t$ to $\alpha_t$. When an action is taken, the agent receives

a scalar reward $r_t$ according to a reward function $\mathcal{R}(s, \alpha)$, and transitions to the next state $s_{t+1}$ following a state transition probability $P(s_{t+1} | s_t, \alpha_t)$. For instance, an agent may decide to allocate more bandwidth to network switches in high-traffic areas (action $\alpha_t$) to reduce data exchange latency (state $s_t$). The reward $r_t$ can be based on how effectively the bandwidth allocation reduces latency while maintaining overall network efficiency. After this action, the system transitions to the next state $s_{t+1}$, where new metrics such as updated latency and network load are observed. The state transitions and rewards are stochastic and are assumed to have the Markov property. In an episodic problem, this process continues until the agent reaches a terminal state and then it restarts. This can be a state where QoS requirements of all IoT application are satisfied. The return $R_t = \sum_{k=0}^{\inf} Y^k r_{t+k}$ is the discounted, accumulated reward with the discount factor $\gamma \in (0, 1]$. The agent aims to maximize the expectation of such long term return from each state, which leads to learning the optimal policy $\pi^*$ to follow.

In existing approaches, the state space $\mathcal{S}$ is usually modelled based on $\mu_{qos}$, which may include network link congestion, data traffic, and resource consumption [1]. However, CRAFTER identifies additional relevant variables (including $\mu_{context}$) that affect system performance through Causal Discovery, as discussed in Section 4.1. Hence, based on the obtained causal model, CRAFTER defines the RL problem as follows:

- The set of states $\mathcal{S}$ is defined using $\mu_{context}$ (e.g., location, number of occupants, day and time).

- The set of actions $\mathcal{A}$ includes the available actions that can be taken for adaptation (e.g., bandwidth/resource allocation).

- To satisfy the QoS requirements of applications, CRAFTER defines a reward function $\mathcal{R}$ to minimize the deviation between the QoS requirements and the observed performance of the system.

$$ \mathcal{R} = - \left( \sum_{a_i \in \mathcal{A}} \phi_i \frac{\delta_{a_i} - \delta_{qos}}{\delta_{qos}} + c_{1.\omega} + c_{2.\rho}(e_i) \right) \quad (2) $$

where $\phi_i$ represents the “priority” of the application (i.e., how important the application is), and $\frac{\delta_{a_i} - \delta_{qos}}{\delta_{qos}}$ represents the deviation between the latency defined by the application’s QoS requirements and the actual latency perceived by the application. To avoid over-allocation of resources, we add penalty terms ($c_1$ and $c_2$) to the bandwidth and resources allocated in the system.

Two main approaches exist for solving RL problems. Value-based methods — such as Q-learning/Deep Q-learning — focus on learning an optimal value function by mapping states and actions to rewards [44]. However, these methods are more suited for environments where states and actions can be modelled as discrete values. In more complex environments with a continuous action space (e.g., controlling resource allocation in complex IoT systems), such methods may struggle to find the best policy [44]. For this purpose, CRAFTER relies on policy-based methods, such as Proximal Policy Optimization (PPO) [41], to directly learn the optimal policy $\pi^*$ without having to learn a value function.

## 5 Experimental Evaluation

This section presents the evaluation of CRAFTER using a realistic smart museum scenario. For this purpose, we first implement the CRAFTER prototype for simulating IoT data exchange in smart
<figure><img src="image_7.png" /><figcaption>Figure 5: The CRAFTER prototype implementation</figcaption></figure>

<table><caption>Table 2: Device and visitor allocation per location</caption><thead><tr><td>Location</td><td># devices</td><td>% visitors</td></tr></thead><tbody><tr><td>B</td><td>25</td><td>35</td></tr><tr><td>C</td><td>11</td><td>5</td></tr><tr><td>D</td><td>17</td><td>5</td></tr><tr><td>E</td><td>18</td><td>15</td></tr><tr><td>G</td><td>16</td><td>15</td></tr><tr><td>S</td><td>15</td><td>10</td></tr><tr><td>V</td><td>10</td><td>15</td></tr></tbody></table>

spaces (Section 5.1). This enables modeling spaces and defining the deployed devices, virtual sensors, and applications. In addition, the prototype supports controlling the networking infrastructure, resource allocation parameters, and number of occupants in each location of the smart space. Then, we model several exhibition halls in the Louvre by relying on the analysis done in [53], which monitors visitors' movement patterns throughout various locations. Using the developed prototype and models, we emulate IoT data exchange and generate an IoT metrics dataset containing response times per data flow (Section 5.2). CRAFTER then extracts causal relationships between the different variables in the smart museum scenario (Section 5.3). To showcase CRAFTER's decision-making capabilities, we feed the smart museum causal graph to CRAFTER's Adaptation Agent for taking adaptation decisions to keep the response time of applications under the QoS requirements that they define (Section 5.4). Finally, we compare our solution against state-of-the-art approaches (Section 5.5). The prototype developed, the models and datasets used for the following experiments, along with the solution and results are publicly available on https://github.com/satrai-lab/crafter/.

## 5.1 CRAFTER Prototype Implementation

For evaluating CRAFTER, we implement a Java-based prototype for emulating IoT data exchange in smart spaces. As shown in Figure 5, we model properties of smart spaces, devices, virtual sensors, and applications and their QoS requirements in JSON format. We consider that a space is divided into multiple physical locations that may have different characteristics. These include the area of the space, the number of occupants in the space, and the type and number of IoT devices deployed. Then, we model devices' properties: their type (e.g., temperature sensor, motion sensor), the observation(s) they provide (e.g., temperature, humidity, number of occupants), and the distribution and rate at which they generate data. Virtual sensors define observations that they receive and process using simple rule-based algorithms or more complex ML-based approaches. Finally, applications deployed in the space specify observations to be received from devices and virtual sensors, which

<figure><img src="image_8.png" /><figcaption>Figure 6: Causal graph for the smart museum scenario</figcaption></figure>

are then translated to topic subscriptions. They also define QoS requirements related to latency, throughput, energy consumption, and other metrics that have to be satisfied. Communication between the different components of the IoT system takes place through a publish/subscribe architecture. For this purpose, we use the MQTT Paho Library [34] for implementing MQTT clients (devices, virtual sensors, and applications), and EMQX 5.6.1 [15] as a message broker for handling topic-based data exchange. To emulate the networking infrastructure, we rely on Containernet [37], a fork of the Mininet network emulator that supports using Docker containers as network hosts. Each location is packaged and deployed as a Docker container (i.e., network host) connected to its dedicated switch; this allows controlling the characteristics of each location's network link separately. In addition, Edge and Cloud resources are emulated to host virtual sensors and heavyweight computing tasks.

## 5.2 Experimental Setup

To evaluate our approach, we rely on the analysis done in [53] to model 7 exhibition halls in the Louvre, containing popular paintings and artifacts such as Da Vinci's *Mona Lisa* and Canova's *Psyche and Cupid*, and to distribute visitors across locations. We consider that each exhibition hall contains IoT devices deployed for monitoring various space properties; in total, 112 devices are deployed across the smart space. Table 2 shows the allocation of the number of devices and visitors per location, and Table 3 shows the properties of the virtual sensors and applications deployed. We consider that each visitor carries a mobile device that connects to the Louvre infrastructure for receiving visitor guiding information, and periodically sends its location information to help Louvre administrators' analyze visitor's movements and the most visited artifacts. Two Edge nodes are available to host 4 types of virtual sensors. Finally, we consider 5 representative application types that are deployed in the museum, and that define latency QoS requirements to be met. As described in Section 2.1, the Louvre sub-metaverse application enables remote visitors to visit the Louvre in real-time via VR equipment.

## 5.3 Extracting Causal Models

As described in Section 2.3, at design-time, CRAFTER extracts causal relationships in the IoT system. Recall from Section 4.1 that generating causal models involves collecting an IoT metrics dataset D. For this purpose, we use the CRAFTER prototype to emulate IoT data exchange in the Louvre setup presented in Section 5.2. To generate the dataset D, we emulate data exchange in the Louvre for each day of the week (excluding Tuesday, when the Louvre is
<table><caption>Table 3: Properties of virtual sensors and applications</caption><thead><tr><th>Virtual Sensor</th><th>Received data</th><th>Processing technique</th><th>Application</th><th>Received data</th><th>QoS requirements</th></tr></thead><tbody><tr><td>Occupancy Prediction</td><td>Camera feed, visitor's location</td><td>CNN for people detection, aggregation with visitors' locations</td><td>Metaverse</td><td>Lighting, noise, visitors' locations</td><td>20 ms</td></tr><tr><td>Queue Management</td><td>Visitor's location</td><td>Estimation of waiting times using linear regression</td><td>Smart lighting</td><td>Lighting</td><td>100 ms</td></tr><tr><td>Security Analysis</td><td>Camera feeds, motion, door sensors</td><td>Aggregation of data for security threat detection</td><td>Visitor guiding</td><td>Occupancy, queueing times</td><td>400 ms</td></tr><tr><td>Predictive Maintenance</td><td>Temperature, humidity, air quality, proximity</td><td>Estimation of maintenance date using linear regression</td><td>Artifact maintenance</td><td>Maintenance date</td><td>2 s</td></tr><tr><td></td><td></td><td></td><td>Security</td><td>Security alert</td><td>1s</td></tr></tbody></table>

closed) and for two time periods each day: the morning period (AM) and evening period (PM). We vary the number of visitors based on the day and time period, with the weekend days (Friday, Saturday, Sunday) being the most crowded of the week [53]. For each day and time period, we vary the bandwidth value from each location from 20 Mbps to 500 Mbps, and vary the percentage of resources allocated to virtual sensors from 10% of total resources to 100%. In total, we generate a dataset that captures 1560 different possible configurations of the system. For each configuration, we record the response time for individual messages received by each application, as well as the resource consumption per Edge node.

Once the dataset is generated, we use CRAFTER to extract causal models. We use the Causal-Learn Python library [61] for generating the causal graph in DOT format from the IoT dataset D. For this purpose, we rely on the Peter-Clark (PC) [26, 43] algorithm using Kernel-based Conditional Independence [58] for testing for independent variables. PC is known for its ability to easily identify conditional independencies, and offers scalability and flexibility in handling various kinds of data. PC starts with a complete graph where each node represents a variable in V, and each edge represents a causal relationship. The algorithm then iteratively tests for conditional independencies and removes edges between nodes that are conditionally independent given any subset of the other nodes. Rules such as orientation based on V-structures and propagation of direction [43] are then applied to orient edges following the existing independencies between variables and the provided knowledge base. The generated causal graph for the smart museum setup is shown in Figure 6. We can see that bandwidth allocation, resource allocation, and resource consumption are a direct cause of response time. Naturally, changing these parameters usually results in better/worse response time values for messages. However, we can also observe the context variables that have direct and indirect effects on the response time experienced by applications. For instance, the day and time are direct causes of response time, since they are also causes of fluctuations of the number of visitors. Location, on the other hand, is an indirect cause of response time, since visitors' distribution across exhibition halls in the museum varies based on the popularity of artifacts and paintings. Hence, when more visitors are present in a hall, data traffic will increase in that location, leading to more congested network links, and a need for more computing power for virtual sensors to process the generated data in a timely manner. We define $\mu_{context} = \{\text{day of the week, time of the day, number of visitors}\}$, and $\mu_{qos} = \{\text{bandwidth, resource allocation, resource consumption}\}$.

<figure><img src="image_9.png" /><figcaption>Figure 7: Reward per training episode</figcaption></figure>

The causal graph enables more formal explanation of the performance of IoT systems, without the need for assumptions and trial-and-error testing. In more complex deployments, such causal models are not trivial to retrieve only through expert elicitation, hence the need for causal discovery approaches.

To highlight CRAFTER's ability to generate causal graphs across different IoT domains with minimal domain expertise, we evaluate CRAFTER on three different real-world datasets spanning different IoT use cases. These include: (i) an Autonomous Moving Robot (AMR) scenario with network throughput and latency requirements, (ii) a smart factory scenario involving a copper production manufacturing plant with energy consumption requirements, and (iii) an anomaly detection scenario in a production cell with latency and throughput requirements. Our evaluation shows that CRAFTER manages to generate relevant causal graphs for three use cases, illustrating how the same self-adaptation can be applied to different IoT domains. The generated causal graphs and more information regarding the evaluation scenarios can be found on: https://github.com/satrai-lab/crafter/.

## 5.4 Learning Self-adaptation with Causal RL

CRAFTER's Adaptation Agent is guided by the causal graphs generated in Section 5.3 for taking efficient adaptation actions. We train two CRAFTER Adaptation Agents using the obtained causal graph: a first agent (called CRAFTER-Context Only) that observes states based only on the $\mu_{context}$ identified by the causal model. The second agent (called CRAFTER-Mixed) observes both $\mu_{context}$ and $\mu_{qos}$. The possible actions to be taken include allocating a specific
<figure><img src="image_10.png" /><figcaption>Figure 8: Distribution of evaluation rewards</figcaption></figure>

bandwidth to network links for the different locations, and allocating computing resources to Edge nodes where virtual sensors are deployed. Training the RL agents involves interacting with the IoT environment to learn the optimal policy. When an agent selects an action to be performed, the CRAFTER prototype is simulated under the configuration chosen by the agent, and the reward function value and the next state values are returned to the agent through a feedback loop. We use the Stable-Baseline3 library [39] to design the RL agents, and Gymnasium [45] for creating the training environment. We train the agents using the PPO algorithm [41] to optimize the reward function defined in Equation 2, which aims to reduce each application's response time deviation w.r.t. its QoS requirements, while avoiding over-allocation of network and computing resources. The agents are trained for 70 episodes using a learning rate of 0.0003 and a clip range of 0.2.

## 5.5 CRAFTER Against Existing Approaches

We evaluate CRAFTER against (i) state-of-the-art RL-based approaches commonly used for adaptation in IoT systems [10, 30, 46], (ii) approaches that use genetic algorithms for adaptation [27], and (iii) rule-based approaches [22, 31].

We first evaluate the training performance of RL agents. In addition to CRAFTER-Context Only and CRAFTER-Mixed, we train an RL agent to take adaptation decisions based solely on $\mu_{qos}$ (called SOTA-RL). SOTA-RL is trained in the same environment as CRAFTER agents, using the same hyperparameters and for the same number of episodes. For all three agents, the training algorithm, the action space and reward function (Eq. 2) are the same. Figure 7 shows the reward value per training episode for each of the agents. CRAFTER-Context Only achieves a 22% improvement in training compared to SOTA-RL. This is due to the incorporation of key context variables in the observed states identified through the causal models. By exploiting valuable cause-effect relationships, RL agents are able to make better and more informed adaptation decisions. The improvement is even more pronounced when we combine $\mu_{qos}$ and $\mu_{context}$: the CRAFTER-Mixed approach achieves up to 30% improvement in training over SOTA-RL, albeit with a lower training stability than CRAFTER-Context Only. We next evaluate the three models over 100 episodes, and record the mean and standard deviation of

the obtained rewards for each episode. Figure 8 shows the distribution of rewards during the evaluation episodes. CRAFTER-Context Only once again achieves a better performance than SOTA-RL, with a 25% better mean reward value. The standard deviation of reward distribution is also smaller for CRAFTER-Context Only (2.21) than for the SOTA-RL approach (2.33).

Next, we evaluate the adaptation capabilities of CRAFTER using the setup presented in Section 5.2. To compare with genetic programming approaches, we use the NSGA-II algorithm [13] implemented with the DEAP [12] Python library, with a population size of 50, 70 generations, a mutation probability of 0.2 and a crossover probability of 0.5. To compare with rule-based approaches, we train a Decision Tree implemented with Scikit-learn [36]. For each application type, we plot the average response time per day and time period under the following conditions: (i) without adaptation, i.e., the same configuration (bandwidth and resource allocation) is used throughout the whole week, (ii) with adaptation using the state-of-the-art approaches, (iii) using the CRAFTER-Context Only and CRAFTER-Mixed adaptation approaches.

Figure 9 shows the average response time per application. As expected, without any adaptation solution, the QoS requirements of most applications are violated when the properties of the smart environment change. For example, as the number of visitors and devices increases in the museum starting from Thursday afternoon, the response time of applications increases significantly for all applications. The Decision Tree approach provides better results than static configurations, but its rule-based structure limits its ability to cope with more dynamic and complex fluctuations in traffic and resource demand. This results in high response times during peak conditions (with a response time of up to 47 ms for Metaverse applications). This shows that simply using rule-based approaches for adaptation purposes is not enough for satisfying the QoS requirements of applications in highly dynamic IoT environments. The Genetic Algorithm, on the other hand, enables more effective adaptation actions as the number of visitors and the workload vary. For example, it manages to keep the latency of visitor guiding applications (478 ms) under the QoS requirements of 500 ms. However, it struggles to maintain the required QoS consistently for other applications, especially under a high workload. On weekend days, the latency for Metaverse applications reaches up to 49 ms during peak visiting hours. While the Genetic Algorithm can adapt to some degree, it fails to keep response times under strict thresholds for more demanding applications. In response to changes, CRAFTER-Context Only manages to keep the response time for all applications under their defined QoS requirements, even when the number of visitors reaches a peak, on Saturday and Sunday, as shown in Figure 9. Even for Metaverse applications that require an ultra-low latency of less than 20 ms, CRAFTER effectively adapts to the changing properties of the IoT system. The CRAFTER-Mixed approach also manages to offer appropriate adaptation in dynamic situations, keeping the response time of Metaverse under 20 ms as well. On the other hand, the SOTA-RL approach fails to keep the response time of messages under 20 ms, resulting in a response time of over 35 ms (75% higher than the QoS requirements of Metaverse applications), especially during the busiest periods. The same trend is observed for other applications, where CRAFTER-Context Only succeeds in keeping
<figure><img src="image_11.png" /><figcaption>Figure 9: Average response time per application</figcaption></figure>

response time values of applications under the specified requirements. By exploiting relevant context information that have an effect of the performance of the system, CRAFTER can effectively adapt to changes in dynamic environments.

## 6 Related Work

This section provides an overview of literature related to self-adaptive IoT systems and causal discovery.

**Self-adaptive IoT.** Significant research has been carried out on self-adaptive systems recently. Application layer approaches such as [31], [16] focus on dynamically adapting sensor deployment and data source assignment using quality evaluation and opportunistic sensing to meet application requirements and system changes. Disstream [56] introduces dynamic workload balancing for low-latency, high-throughput live video analytics. However, it only focuses on task distribution for video streaming application. [3] proposes a goal-driven architecture for adapting to sudden device unavailability and changing deployment topologies, while [2] employs a machine learning for user activity recognition for the deployment of goal-driven IoT systems. [22, 23] leverage AI planning for adaptive data flow configuration in IoT environments based on QoS requirements and dynamic application changes. Middleware approaches such as Sora [29] introduce a Scatter-Concurrency-Goodput method that focuses on adapting soft resources to critical microservices, while [32] offers a framework for adaptation of cloud computing continuum configurations in dynamic mobile settings. Similarly, [8] provides a framework for ensuring autonomous AIoT operation

in complex deployments spanning the computing continuum. RL-based methods have become prominently used for self-adaptive IoT systems [10]. For instance, the authors of [33] present an architecture using LSTM networks for forecasting data traffic and RL for adaptation to enhance energy efficiency in IoT systems. REAM [46] provides a publish/subscribe middleware for resource monitoring based on application priority and employs RL agents for monitoring and adaptation actions. [30] uses Deep RL for load-balancing computing tasks in IoT Edge systems while taking into account the communication requirements of applications. [60] introduces safety-aware adaptive RL for autonomous mobile assistive robots, where the agent must adapt actions at runtime while respecting safety constraints and environmental changes. The approach is designed for real-world robotic agents operating in dynamic environments typical of self-adaptive systems. While this approaches emphasizes runtime safety constraints and robotics adaptation, CRAFTER targets IoT systems and couples RL with design-time causal models to reduce exploration overhead and identify causal drivers of performance issues. [59] proposes a meta-reinforcement learning approach for self-adaptive systems that can quickly adapt policies across multiple possible environment dynamics. It learns a meta-policy across models so that when the real environment appears, the system can adapt faster. On the other hand, CRAFTER uses causal discovery and RL in a unified framework to try and anticipate root causes of performance issues, and not just quickly re-learn policies, but understand what drives adaptation needs. [42] uses online learning and monitoring techniques in an IoT context
to achieve antifragility — systems that can improve performance under stress through continuous learning. [14] proposes a proactive approach for the self-adaptation of non-linear cyber-physical systems based on Adaptive Model Predictive Control (AMPC), and is designed primarily for autonomous moving robots.

While the above approaches support self-adaptation when system performance is degraded, adaptation actions are reactive (i.e., after the QoS violations are detected). They also fail to identify the causes of QoS violations. CRAFTER supports proactive adaptation by understanding the variables that impact IoT system performance.

**Causal discovery.** Causality has been traditionally used in various fields, such as genomics, social sciences, economics, among others [54]. However, with the growing need for explainable systems, causality-based approaches are being more widely used in networking and AI-based approaches. For example, [47] proposes wireless traffic prediction using Granger Causal Discovery and a GNN-based model to explore spatio-temporal causal relationships between network variables. [20] introduces CaFANet that uses causal analysis and attention mechanisms for network equipment fault prediction. [9] explores Knowledge Representation in causal discovery, in enhancing constrained devices and IoT systems. However, their approach is only suited for small scenarios and not clearly applicable for complex dynamic systems. [28] used Partial Information Decomposition to differentiate information types in Causal Discovery for wireless IoT, but does not account for dynamic environments that require runtime adaptation. [38] presents a comprehensive evaluation of causal inference-based Root Cause Analysis (RCA) methods for microservice systems using metrics data. The authors assess various causal discovery algorithms and RCA techniques on a combination of synthetic and real-world microservice system datasets, highlighting that no single method performs optimally across all scenarios and that current synthetic datasets may not accurately reflect real-world system behavior. [50] proposes a metric-level RCA approach that utilizes multi-modal data from traces, logs, and metrics to achieve a more comprehensive system understanding and localize root causes. The authors employ methods such as ranking abnormal services based on multi-modal data and building causal graphs of abnormal metrics with a reward mechanism to identify metric-level root causes efficiently and accurately. The application of causal discovery for IoT remains largely limited to anomaly detection and intrusion detection [7, 18, 28, 57, 61], while its use in self-adaptive systems (i.e., systems that use the discovered causal structure to adapt themselves) remains sparse [24].

Existing approaches leverage Causality at the network-layer as well as in small-scale static IoT systems. To the best of our knowledge, this is the first work that leverages Causal RL through an automated pipeline to analyze the key causes of QoS violations in dynamic IoT systems and take tailored adaptation actions.

## 7 Limitations

While CRAFTER demonstrates promising results for causality-based self-adaptation in autonomous IoT systems, several limitations must be acknowledged:

**Dependence on dataset quality.** CRAFTER relies on IoT performance metrics datasets to perform causal discovery at design-time.

As with all data-driven approaches, the quality, diversity, and representativeness of the collected IoT metrics dataset directly affect the accuracy of the generated causal graph. If important variables are missing, poorly measured, or insufficiently varied, the resulting causal model may be incomplete or biased. Although CRAFTER can incorporate domain knowledge through expert elicitation or ontologies, fully mitigating data sparsity and hidden confounders remains challenging in complex real-world deployments.

**Scalability of causal discovery algorithms.** Although the PC-based causal discovery used in CRAFTER scales reasonably for the evaluated scenarios, causal discovery algorithms are known to face scalability issues as the number of variables and the dataset size increase. Large datasets collected from large-scale smart environments with thousands of devices, metrics, and contextual variables may require dimensionality reduction, hierarchical causal modeling, or incremental causal discovery techniques, which are not yet integrated into CRAFTER.

**Stability of RL-based adaptation.** CRAFTER employs Reinforcement Learning for runtime adaptation, which introduces training overhead and potential instability during learning phases. Although causal graphs contribute to reducing the state space and improve convergence, online retraining or frequent environment changes may still incur adaptation delays or transient QoS degradation. Furthermore, the current implementation does not explicitly enforce safety constraints during exploration, which may be required in critical IoT deployments.

**Simulation-based evaluations.** Our experimental evaluation relies primarily on emulated environments and realistic datasets. While this allows controlled experimentation and reproducibility, real-world deployments may exhibit additional sources of noise, failures, and non-stationarity that are difficult to fully emulate. As a result, a sim-to-real gap may exist when deploying CRAFTER in production IoT systems, particularly for safety-critical or latency-sensitive applications.

## 8 Conclusion and Future Work

This paper presents CRAFTER to enable causal-based self-adaptation for autonomous IoT systems. We propose a formal approach based on Causal Discovery for identifying the causes of performance degradation in IoT systems. This results in causal models that are used for modelling states for an Adaptation Agent that is trained to take adaptation decisions in dynamic environments. The experimental results show that CRAFTER achieves a performance improvement of 25% over state-of-the-art RL approaches used for self-adaptation.

Our future work includes adding a Model Agnostic Meta-Learning (MAML) component for predicting future states of the system, in terms of context and QoS. We shall also investigate causal inference techniques for quantifying causal effects among the different variables. Finally, we will evaluate CRAFTER in real-life deployments.

## Acknowledgments

This work has received funding from the European Union's Horizon Europe research and innovation actions under grant agreements No. 101135775 (PANDORA) and No. 101168560 (CoEvolution).
## References

[1] Iván Alfonso, Kelly García, Harold Castro, and Jordi Cabot. 2021. Self-adaptive architectures in IoT systems: a systematic literature review. *Journal of Internet Services and Applications* 12, 1 (2021), 14.

[2] Fahed Alkhabbas, Sadi Alawadi, Romina Spalazzese, and Paul Davidsson. 2020. Activity recognition and user preference learning for automated configuration of IoT environments. In *Proceedings of the 10th International Conference on the Internet of Things*. 1–8.

[3] Fahed Alkhabbas, Ilir Murturi, Romina Spalazzese, Paul Davidsson, and Schahram Dustdar. 2020. A goal-driven approach for deploying self-adaptive IoT systems. In *2020 IEEE International Conference on Software Architecture (ICSA)*. IEEE, 146–156.

[4] Smart Appliances. 2017. SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping. *RTS/SmartM2M-103264v2, Rev 2, 1* (2017).

[5] Bharathan Balaji, Arka Bhattacharya, Gabriel Fierro, Jingkun Gao, Joshua Gluck, Dezhi Hong, Aslak Johansen, Jason Koh, Joern Ploennigs, Yuvraj Agarwal, et al. 2016. Brick: Towards a unified metadata schema for buildings. In *Proceedings of the 3rd ACM International Conference on Systems for Energy-Efficient Built Environments*. 41–50.

[6] Elias Barenboim, Juan D Correa, Duligur Ibeling, and Thomas Icard. 2022. On Pearl's hierarchy and the foundations of causal inference. In *Probabilistic and causal inference: the works of judea pearl*. 507–556.

[7] Srividya Bhaskara and Santosh Singh Rathore. 2023. Causal effect analysis-based intrusion detection system for IoT applications. *International Journal of Information Security* 22, 4 (2023), 931–946.

[8] Georgios Bouloukakis, Ajay Kattepur, Dusan Jakovetic, Alexandros Iosifidis, Konstantinos Tserpes, and Maria Pateraki. 2025. Unlocking AIoT Efficiency in the Computing Continuum—the PANDORA framework. In *Proceedings of the 15th International Conference on the Internet of Things*. 201–209.

[9] Phillip G Bradford, Himadri N Saha, and Marcus Tanque. 2021. Knowledge Representation for Causal Calculi on Internet of Things. In *Artificial Intelligence to Solve Pervasive Internet of Things Issues*. Elsevier, 125–145.

[10] Wuhui Chen, Xiaoyu Qiu, Ting Cai, Hong-Ning Dai, Zibin Zheng, and Yan Zhang. 2021. Deep reinforcement learning for Internet of Things: A comprehensive survey. *IEEE Communications Surveys & Tutorials* 23, 3 (2021), 1659–1692.

[11] David Maxwell Chickerling. 2002. Optimal structure identification with greedy search. *Journal of machine learning research* 3, Nov (2002), 507–554.

[12] François-Michel De Rainville, Félix-Antoine Fortin, Marc-André Gardner, Marc Parizeau, and Christian Gagné. 2012. Deap: A python framework for evolutionary algorithms. In *Proceedings of the 14th annual conference companion on Genetic and evolutionary computation*. 85–92.

[13] Kalyanmoy Deb, Amit Pratap, Sameer Agarwal, and TAMT Meyarivan. 2002. A fast and elitist multiobjective genetic algorithm: NSGA-II. *IEEE transactions on evolutionary computation* 6, 2 (2002), 182–197.

[14] Farid Edrisi, Diego Perez-Palacin, Mauro Caporuscio, and Raffaela Mirandola. 2025. Approaching Proactive Self-Adaptation in Nonlinear Cyber-Physical Systems. In *2025 IEEE/ACM 20th Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS)*. IEEE, 25–31.

[15] EMQX [n. d.]. https://www.emqx.io.

[16] Elif Eryilmaz, Frank Trollmann, and Sahin Albayrak. 2019. Quality-aware service selection approach for adaptive context recognition in IoT. In *Proceedings of the 9th International Conference on the Internet of Things*. 1–8.

[17] Patrick Th Eugster, Pascal A Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. 2003. The many faces of publish/subscribe. *ACM computing surveys (CSUR)* 35, 2 (2003), 114–131.

[18] Ibrahim Gad. 2025. TOCA-IoT: Threshold optimization and causal analysis for IoT network anomaly detection based on explainable random forest. *Algorithms* 18, 2 (2025), 117.

[19] Omid Gheibi, Danny Weyns, and Federico Quin. 2021. Applying machine learning in self-adaptive systems: A systematic literature review. *ACM Transactions on Autonomous and Adaptive Systems (TAAS)* 15, 3 (2021), 1–37.

[20] Zhenwen Gui, Shuaishuai He, Yao Lin, Xin Nan, Xiaoyan Yin, and Chase Q Wu. 2023. Cafanet: causal-factors-aware attention networks for equipment fault prediction in the internet of things. *sensors* 23, 16 (2023), 7040.

[21] Houssam Hajj Hassan, Georgios Bouloukakis, Ajay Kattepur, Denis Conan, and Djamel Belaïd. 2023. EDICT: simulation of edge interactions across IoT-enhanced environments. In *2023 19th International Conference on Distributed Computing in Smart Systems and the Internet of Things (DCOSS-IoT)*. IEEE, 161–165.

[22] Houssam Hajj Hassan, Georgios Bouloukakis, Ajay Kattepur, Denis Conan, and Djamel Belaïd. 2023. PlanIoT: A framework for adaptive data flow management in IoT-enhanced spaces. In *2023 IEEE/ACM 18th Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS)*. IEEE, 157–168.

[23] Houssam Hajj Hassan, Georgios Bouloukakis, Luca Scalzotto, Nirmine Khaled, Denis Conan, Ajay Kattepur, and Djamel Belaïd. 2024. A Message Broker Architecture for Adaptive Data Exchange in the IoT. In *2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C)*. IEEE, 151–158.

[24] Raj Kashikar. 2025. Causally-Aware Safe Reinforcement Learning for Long Horizon Partially Observable Environments in IoT Systems. In *Proceedings of the 25th 5th International Conference on Internet of Things and Machine Learning*. 97–102.

[25] Jeffrey O Kephart and David M Chess. 2003. The vision of autonomic computing. *Computer* 36, 1 (2003), 41–50.

[26] Thuc Duy Le, Tao Hoang, Jiuyong Li, Lin Liu, Huawen Liu, and Shu Hu. 2016. A fast PC algorithm for high dimensional causal discovery with multi-core PCs. *IEEE/ACM transactions on computational biology and bioinformatics* 16, 5 (2016), 1483–1495.

[27] Jia Li et al. 2022. Learning Self-adaptations for IoT Networks: A Genetic Programming Approach. In *Proceedings of the 17th Symposium on Software Engineering for Adaptive and Self-Managing Systems*. Association for Computing Machinery, New York, NY, USA, 13–24.

[28] Jessica E Liang. 2024. Partial information decomposition for causal discovery with application to internet of things. *IEEE Internet of Things Journal* 11, 13 (2024), 24289–24299.

[29] Jianshu Liu, Qingyang Wang, Shungeng Zhang, Liting Hu, and Dilma Da Silva. 2023. Sora: A latency sensitive approach for microservice soft resource adaptation. In *Proceedings of the 24th International Middleware Conference*. 43–56.

[30] Qingzhi Liu, Tiancong Xia, Long Cheng, Merijn Van Eijk, Tanir Ozcelebi, and Ying Mao. 2022. Deep Reinforcement Learning for Load-Balancing Aware Network Control in IoT Edge Systems. *IEEE Transactions on Parallel and Distributed Systems* 33, 6 (2022), 1491–1502. doi:10.1109/TPDS.2021.3116863

[31] Majid Lotfian Delouee, Boris Koldehofe, and Viktoriya Degeler. 2023. Aqua-cep: Adaptive quality-aware complex event processing in the internet of things. In *Proceedings of the 17th ACM International Conference on Distributed and Event-Based Systems*. 13–24.

[32] Matteo Mendula, Paolo Bellavista, Marco Levorato, and Sharon Ladron de Guevara Contreras. 2024. Fucifer: a context adaptive middleware for real-world object detection exploiting local, edge, and split computing in the cloud continuum. In *2024 IEEE International Conference on Pervasive Computing and Communications (PerCom)*. IEEE, 47–56.

[33] Henry Muccini and Karthik Vaidhyathanathan. 2020. Leveraging machine learning techniques for architECTing self-adaptive iOT systems. In *2020 IEEE International Conference on Smart Computing (SMARTCOMP)*. IEEE, 65–72.

[34] Paho MQTT Java Client [n. d.]. https://eclipse.dev/paho/index.php.

[35] Judea Pearl, Madelyn Glymour, and Nicholas P Jewell. 2016. Causal inference in statistics: A primer. John Wiley & Sons.

[36] Fabian Pedregosa, Gaël Varoaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, Peter Prettenhofer, Ron Weiss, Vincent Dubourg, et al. 2011. Scikit-learn: Machine learning in Python. *the Journal of Machine Learning research* 12 (2011), 2825–2830.

[37] Manuel Peuster, Holger Karl, and Steven Van Rossem. 2016. MEDICINE: Rapid prototyping of production-ready network services in multi-PoP environments. In *2016 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN)*. IEEE, 148–153.

[38] Luan Pham, Huong Ha, and Hongyu Zhang. 2024. Root Cause Analysis for Microservices based on Causal Inference: How Far Are We?. In *2024 39th IEEE/ACM International Conference on Automated Software Engineering (ASE)*. IEEE, 706–718.

[39] Antonin Raffin, Ashley Hill, Adam Gleave, Anssi Kanervisto, Maximilian Ernestus, and Noah Dormann. 2021. Stable-baselines3: Reliable reinforcement learning implementations. *Journal of machine learning research* 22, 268 (2021), 1–8.

[40] Mads Holten Rasmussen, Maxime Lefrançois, Georg Ferdinand Schneider, and Pieter Pauwels. 2020. BOT: The building topology ontology of the W3C linked building data group. *Semantic Web* 12, 1 (2020), 143–161.

[41] John and others Schulman. 2017. Proximal Policy Optimization Algorithms. *arXiv preprint arXiv:1707.06347* (2017).

[42] Vincenzo Scotti, Diego Perez-Palacin, Valerio Brauzi, Vincenzo Grassi, and Raffaela Mirandola. 2025. Antifragility via Online Learning and Monitoring: an IoT Case Study. (2025).

[43] Peter Spirtes, Clark N Glymour, and Richard Scheines. 2001. Causation, Prediction, and Search. MIT press.

[44] Richard S Sutton. 2018. Reinforcement Learning: An Introduction. *A Bradford Book* (2018).

[45] Mark Towers, Jordan K. Terry, Ariel Kwiatkowski, John U. Balis, Gianluca de Cola, Tristan Deleu, Manuel Goulão, Andreas Kallinteris, Arjun KG, Markus Krimmel, Rodrigo Perez-Vicente, Andrea Pierré, Sander Schulhoff, Jun Jet Tai, Andrew Tan Jin Shen, and Omar G. Younis. 2023. Gymnasium.

[46] Praveen Venkateswaran, Kyle E Benson, Chia-Ying Hsieh, Cheng-Hsin Hsu, Sharad Mehrotra, and Nalini Venkatasubramanian. 2021. REAM: A Framework for Resource Efficient Adaptive Monitoring of Community Spaces. *Pervasive and Mobile Computing* 76 (2021), 101459.

[47] Dan Wang, Yingjie Liu, and Bin Song. 2024. A credible traffic prediction method based on self-supervised causal discovery. *Science China Information Sciences* 67, 5 (2024), 152303.

[48] Tianshi Wang, Jinyang Li, Ruijie Wang, Denizhan Kara, Shengzhong Liu, Davis Wertheimer, Antoni Viros i Martin, Raghu Ganti, Mudhakar Srivatsa, and Tarek Abdelzaher. 2023. Sudokusens: Enhancing deep learning robustness for iot sensing applications using a generative approach. In *Proceedings of the 21st ACM*
Conference on Embedded Networked Sensor Systems. 15–27.

[49] Xiaojie Wang, Qi Guo, Zhaolong Ning, Lei Guo, Guoyin Wang, Xinbo Gao, and Yan Zhang. 2024. Integration of sensing, communication, and computing for metaverse: A survey. *Comput. Surveys* 56, 10 (2024), 1–38.

[50] Yidan Wang, Zhouruixing Zhu, Qiaui Fu, Yuchi Ma, and Pinjia He. 2024. MRCA: Metric-level Root Cause Analysis for Microservices via Multi-Modal Data. In *Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering*. 1057–1068.

[51] Danny Weyns, Ilias Gerostathopoulos, Nadeem Abbas, Jesper Andersson, Stefan Biffl, Premek Brada, Tomas Bures, Amleto Di Salle, Matthias Galster, Patricia Lago, et al. 2023. Self-adaptation in industry: A survey. *ACM Transactions on Autonomous and Adaptive Systems* 18, 2 (2023), 1–44.

[52] Danny Weyns, Omid Gheibi, Federico Quin, and Jeroen Van Der Donckt. 2022. Deep learning for effective and efficient reduction of large adaptation spaces in self-adaptive systems. *ACM Transactions on Autonomous and Adaptive Systems (TAAS)* 17, 1-2 (2022), 1–42.

[53] Yuji Yoshimura, Anne Krebs, and Carlo Ratti. 2017. Noninvasive Bluetooth monitoring of visitors' length of stay at the louvre. *IEEE Pervasive Computing* 16, 2 (2017), 26–34.

[54] Alessio Zanga, Elif Ozkirimli, and Fabio Stella. 2022. A survey on causal discovery: theory and practice. *International Journal of Approximate Reasoning* 151 (2022), 101–129.

[55] Edith Zavala, Xavier Franch, Jordi Marco, Alessia Knauss, and Daniela Damian. 2018. SACRE: Supporting contextual requirements' adaptation in modern self-adaptive systems in the presence of uncertainty at runtime. *Expert Systems with Applications* 98 (2018), 166–188.

[56] Xiao Zeng, Biyi Fang, Haichen Shen, and Mi Zhang. 2020. Distream: scaling live video analytics with workload-adaptive distributed edge intelligence. In *Proceedings of the 18th Conference on Embedded Networked Sensor Systems*. 409–421.

[57] ZengRi Zeng, BaoKang Zha, Xuhui Liu, and Xiaoheng Deng. 2025. Causal Interpretability Methods for IoT Anomaly Traffic Detection. *IEEE Internet of Things Journal* (2025).

[58] Kun Zhang, Jonas Peters, Dominik Janzing, and Bernhard Schölkopf. 2012. Kernel-based conditional independence test and application in causal discovery. *arXiv preprint arXiv:1202.3775* (2012).

[59] Mingyue Zhang, Jialong Li, Haiyan Zhao, Kenji Tei, Shinichi Honiden, and Zhi Jin. 2021. A Meta Reinforcement Learning-based Approach for Self-Adaptive System. In *2021 IEEE International Conference on Autonomic Computing and Self-Organizing Systems (ACSOS)*. 1–10. doi:10.1109/ACSOS52086.2021.00024

[60] Qi Zhang, Ioannis Stefanakos, Javier Cámara, and Radu Calinescu. 2024. Safety-Aware Adaptive Reinforcement Learning for Mobile Assistive-Care Robots. In *2024 IEEE International Conference on Autonomic Computing and Self-Organizing Systems Companion (ACSOS-C)*. IEEE, 115–120.

[61] Yujia Zheng, Biwei Huang, Wei Chen, Joseph Ramsey, Mingming Gong, Ruichu Cai, Shohei Shimizu, Peter Spirtes, and Kun Zhang. 2024. Causal-learn: Causal discovery in python. *Journal of Machine Learning Research* 25, 60 (2024), 1–8.