Impact Conflict Detection of IoT Services in Multi-resident Smart Homes

An IoT service ($S$) is associated with a set of functional and non-functional properties. An IoT service event ($SE$) illustrates a resident’s previous service usage in conjunction with time and location. IoT service event sequences ($SES$) record all the history of service events, and preferences ($Pref$) can be estimated from these previous events. An IoT service request ($SR$) captures a resident’s current service usage requirement. Multiple residents’ requirements are stored in service request sequences ($SRS$). Impact ($I$) may occur on the ambient environment properties due to the different service requests from residents. Consequently, an impact conflict ($IC$) may happen if a change in ambient properties exceeds any user’s preference range. Given this information, the paper aims to identify a function $F(S,SRS,SES)$, where $IC\approx F(S,SRS,SES)$. It is represented as:

where $\{S,Q\}$ is the impacted service and its associated attribute, $U$ is the user who experiences the conflict, $P$ is the likelihood of the conflict, and $T$ and $L$ represent the time and location, respectively, of the probable impact conflict.

In this module, we quantify the impact from the users’ service requests. The proposed impact model is designed considering four ambient environment properties such as temperature, illumination/brightness, sound, and humidity. Two completely different services may interfere with each other via these environment properties due to their simultaneous execution. The impact may occur based on the change of an environmental variable; either it can be a progressive change or an instantaneous change. Given two service requests ($SR_{i}$, $SR_{j}$), if the following conditions are satisfied, only then the impact is computed.

• •

  $L_{S_{i}}$ $\simeq$ $L_{S_{j}}$, meaning, two services ($S_{i}$, $S_{j}$) are executed at the same location.

• •

  $(SRT_{si},SRT_{ei})\cap(SRT_{sj},SRT_{ej}))\neq\emptyset$, denoting that two service requests ($SR_{i}$, $SR_{j}$) are invoked at the same time, and there is a temporal overlap.

• •

  $U_{S_{i}}\neq U_{S_{j}}$ and $S_{i}\neq S_{j}$ , meaning these two requests are invoked on two different services by two different users.

• •

  $\exists Q_{k}\in S.Q:S_{i}.Q_{k}\simeq S_{j}.Q_{k}$; there exists at least one property which is similar between $S_{i}.Q$ and $S_{j}.Q$ (e.g., temperature linked with AC and window).

At first, we find the overlapping segment ($OS$) (i.e., intersection) between two service requests. Starting time ($OST$) of $OS$ would be the maximum of the two start times in $SR_{i}$ and $SR_{j}$. Ending time ($OET$) of $OS$ would be the minimum of the two end times in $SR_{i}$ and $SR_{j}$ (e.g., for two requests, if two ranges are 8 pm to 10 pm and 9 pm to 11 pm, the $OS$ is 9 pm to 10 pm). We use Signal Temporal Logic (STL) based runtime verification technique to measure the degree of impact. STL is a formalism used to specify real-time properties of discrete (e.g., instantaneous change) and continuous (e.g., progressive change) signals (e.g., illumination, temperature). We refer readers to [16] for the formal definition of STL semantics. We find that most smart home service requirements can be specified using STL formula in the form of $\square_{(a,b)}(x:=\lambda)$ where $x$ is a signal about environment property and $\lambda$ is a setpoint (i.e., threshold). For instance, considering motivation scenario 1, STL formula for resident R1’s service requirement, $SR_{1}$: $\square_{(8:00,9:00)}(temperature:=20\degree C)$. We now describe how to compute the degree of impact in which a signal, either continuous or discrete, about an environment property violates a service requirement. A notion of robustness value for violating STL formulas is formally defined in [16]. The robustness value of a signal $x$ violating $(a,b)(x:=\lambda)$ at time $\tau$ is defined as:

Intuitively, the robustness value indicates extremum points of the signal. The robustness value is useful for telling the worst-case performance, but it does not show the average or overall performance. For impact assessment, we are interested to know both. We use the following example to describe why measuring the robustness value only is not enough for finding the severity of impact. Recall our motivation scenario 1. The impact may occur between 8:30 pm and 9:00 pm. We compute impact considering R1’s requirement $SR_{1}$: $\square_{(8:00,9:00)}(temperature:=20\degree C)$. In this case, the temperature is between 20°C and 25°C for 30 minutes. Therefore, the robustness value ($h1$) is 5 (Fig. 3(a)). Assume that, in another case, the outside temperature is 40°C, and the AC has a higher capacity to cool. In this context, the temperature fluctuates between 20°C and 30°C for 10 minutes. The robustness value ($h2$) is 10 (Fig. 3(d)). If only robustness is considered for impact assessment, then the second case will have a higher impact. Thus, they will have a higher conflict likelihood. However, this is not always true since the impact duration is very short. Although the first case has lower robustness, it may have a higher likelihood of conflict as the impact duration is long.

To address this limitation, we present a concept of signal deviation to measure the degree of impact. At first, we calculate the percentage of time when a requirement is violated. To start with, we define Equations 4 and 5 to calculate the positive part and the negative part of a function f(x), respectively.

We compute the percentage of time given a signal $\square_{(a,b)}(x:=\lambda)$ as:

We then use Equation 7 to compute the integral of signal deviations accumulated in a period when the requirement $\square_{(a,b)}(x:=\lambda)$ is violated.

In this module, we estimate users’ preferences for a service based on previous usage records. Impact module outputs the degree of impact, the name of the impacted services, and their overlapping time period where an impact may occur. We use overlapping impacted time periods to extract residents’ service usage patterns from their previous history. Then, it calculates the preference range of frequently used services. We scan the previous history to find out all the overlapping service events (algorithm 1). The input of this algorithm is the previous service usage dataset ($DB$) and the overlapping segment ($OS$) when an impact may occur. All the previous events that have overlapped with the given overlapping segment are the output of this algorithm. Each location has IoT services, and we mine out the frequent service interactions based on location. We can determine if a person uses specific services more frequently by evaluating their service interactions over a long period. A distance-based clustering algorithm, DBSCAN, is employed, resulting in clusters containing services that the resident has used many times during this overlapping period [18]. For example, an impact related to a light service occurs in the living room between 20:00 and 20:30. This component searches all the service events that previously occurred, either partially or fully, between 20:00 and 20:30 in the living room and stores them in a list ($OSE$). This list contains the overlapping service events and their timestamps.

In order to estimate preferences from this list, we then plot all the data points in a two-dimensional plane. Note that, in this paper, we only deal with numerical data associated with IoT services such as temperature, illumination, and sound. X-axis represents each service attribute’s values (e.g., AC temperature, light illumination), and Y-axis represents frequency. We extract the range from the X-axis, where most data points are located. We get the optimal preference range (a.k.a. preference band) based on a dynamic programming approach from the plotted values. The width of the preference band can be of different sizes. For example, Fig.4 depicts four residents’ preferred AC temperature range. Each color denotes each resident’s preferred temperature distribution. The blue curve represents a very strict (i.e., very narrow range of AC temperature) nature of a resident. In contrast, the yellow curve represents another resident’s very flexible (i.e., very wide range of AC temperature) nature. This depicts the residents’ actual preferences in terms of range.

We use the preference range generated from the preference estimation module and the impact weight generated from the impact assessment module to estimate the conflict likelihood. IoT Service Impact Conflict occurs when two services cannot satisfy the preferences of one or multiple users at the same location and time duration. If there is no impact (i.e., the value of impact weight is 0), we assume there is no impact conflict. For example, one resident prefers to have dim light while watching movies in a theatre-like environment. Another resident enters the same room at the same time and opens the window blind to enjoy the outside beauty (assuming the window is glass-made). If it is night and no light enters, there is no impact of opening the blind; thus, there is no conflict. If the value of the impact score is greater than 0, we only then check the preference range of the residents and the change in the ambient environment.

At first, we follow a preferential proximity approach to find the likelihood of having a conflict. Suppose we have two ranges of ambient temperature. One range denotes the resident’s preferred temperature captured from the preference estimation module. Assume one resident’s preference is between 19°C and 21°C, represented as [a_s, b_s] where a_s = 19 and b_s = 21. Another range denotes fluctuated ambient temperatures captured from the impact assessment module. Assume it is between 20°C and 23°C and is represented as [a_e, b_e] where a_e = 20 and b_e = 23. Preferential proximity is computed as follows:

Here, the value of $(1-Pref_{prox})$ determines the likelihood of conflicts. For the example mentioned above, the value of $Pref_{prox}$ is 0.25. Therefore, the likelihood of conflict is (1-0.25) = 0.75. If the value of $Pref_{prox}$ becomes 1, then the preferred range and fluctuated range match completely, and no conflict will occur. However, if the value is 0, then there is no range overlapping, and there will be a high likelihood of conflicts occurring. The more the preferential proximity value leans towards 0, the more possibility of having a conflict. Then, we use the temporal proximity strategy to find out the weight of the potential conflict time over impacted time. For instance, the impact overlapping segment is [8:30 pm - 9:20 pm], and the potential conflict time is [8:45 pm - 9:00 pm] (see motivation scenario 1). The temporal proximity technique for evaluating the distance between time-interval data is adopted from [19]. For each impact overlapping segment, $OS_{i}$, we use a function $f_{i}$ with respect to $t$ to map the temporal aspect of $OS_{i}$. Segment start time and end time are represented with $OST_{i}$ and $OET_{i}$, respectively. $f_{i}$ is formalized in Equation (9).

We generate a set of functions ${f_{1},f_{2},...f_{n}}$ corresponding to the overlapping segments ($OS$) and potential conflict time. Equation (10) calculates the temporal proximity ($temp_{prox}$) for all the overlapping events.

Here, $t_{1}$ and $t_{2n}$ are the first and last time information of overlapped events from $OS$, and $n$ is the number of instances. Consider the following two events of potential impact conflict. One impacted segment is between 20:00 and 21:00; a potential conflict time is between 20:45 and 21:45. Here, potential conflict time denotes a time-period when the fluctuated signal may exceed any user’s preference range. Using Equation 10, the temporal proximity of these two intervals can be calculated as ((20:45-20:00)+(21:00-20:45)*2+(21:45-21:00))/((21:45-20:00)*2)
=0.57. Consider another impacted segment is between 18:00 and 19:00. An potential conflict time is between 18:10 and 19:10. The temporal proximity of these two events can be calculated as ((18:10-18:00)+(19:00-18:10)*2+(19:00-19:10))/((19:10-18:00)*2)=0.86. Thus the latter case has more weight while calculating the likelihood of a conflict. Therefore, for each pair of overlapping service requests, conflict likelihood ($CL$) is computed, including impact weight ($I$), preferential proximity ($Pref_{prox}$), and temporal proximity (($temp_{prox}$)) as:

We use a dataset collected from the Center for Advanced Studies in Adaptive Systems (CASAS) to evaluate the proposed conflict detection framework [20]. There exist a few multi-resident activity datasets. Nevertheless, these datasets do not capture conflicting situations for service usage. Thus they are not helpful enough for our experiment. These publicly available datasets reflect the compromises of the residents interacting with services. As a result, they do not have any IoT service conflicts. Records of a single resident interacting with IoT services, on the other hand, reveal an individual’s true preferences. Consequently, we combine individual inhabitants’ service interaction records (labels HH102, HH104, HH105, and HH106 are used from the CASAS dataset) to mimic a multi-resident smart home environment. These labels were chosen because they feature actions from the same time period (between June 15, 2011, and August 14, 2011). Table I contains descriptions of dataset attributes.

The service interactions from various users overlap in terms of time in the merged dataset. The dataset is annotated with different activity labels and has the layout of the home. However, it lacks interaction records related to windows and blinds. Therefore, we create events such as opening and/or closing window and blind services to mimic the realistic environment. Each room has a thermostat, and we assume that the set temperature is the preferred temperature for a user. We then estimate how much time it will take to cool/hot inside temperature if the window is opened using this formula, “Time taken to cool/hot (in hours) = (volume of the room * density of air * change in temperature * specific heat of air)/ (latent heat of fusion * ton capacity of AC * 1000 / 24). For simplicity, we keep most of the variables constant. The dataset has “Watch_TV” activity label and indoor light level. However, the sound volume and outdoor illumination information are missing. Hence, we augment the dataset by randomly generating these values based on a uniform distribution. After that, whenever two users simultaneously use two services that set the state of an environment property in contradictory ways, a conflict observation is created. We assume that a conflict involving more than two parties can be broken down into numerous pairwise conflicts. We discretize numerical contexts to produce potential context scenarios, and then we tally the occurrences of each scenario in the data; this result reflects how frequently a user has encountered a certain context. If a conflict observation is made at each occurrence, the number of conflicts is increased. Each individual user and service pair’s count is kept individually. Thus, the number of conflicts experienced by that pair of users for that environment property divided by the number of times that context scenario occurred is used to calculate the ground-truth likelihood for two users to have conflicts for a service under a possible scenario. We first evaluate our approach based on accuracy, precision, and recall metrics. Then, we represent the performance across the studies using the mean absolute error (MAE). We can contrast the likelihood based on the ground truth with the likelihood predicted by the method. For instance, to calculate the anticipated likelihood for each sample while evaluating our methodology, we look up the likelihood in the conflict scenario that includes this sample. For a set of samples, the number of samples, the $MAE=\frac{1}{N}\sum|ol-el|$ where $ol$ is ground-truth likelihood and $el$ is the estimated likelihood of the proposed approach.

At first, we measure our proposed framework’s accuracy, precision, and recall score. The first set of experiments is conducted without considering residents’ preferences (fig. 5(a)). This set only considers impact as a binary decision (i.e., if there is an impact, there is a conflict). It is visible from the figure that the accuracy score is very low when preference is not considered. Because this approach detects a scenario as a conflict even when the temperature difference is only 1°C as 1°is considered as an impact here. It counts many non-conflicting situations as conflicts, thus increasing false positive numbers. This reduces the approach’s overall accuracy. However, this approach performs better while detecting non-conflicting situations. This is why the precision and recall scores regarding no-conflict are high. Then, we conduct the second set of experiments considering preference scores. This approach detects both conflicting and non-conflicting situations more accurately based on precision, recall, and f1-score (fig. 5(b)). This approach considers preference as a range. Therefore, when an impact occurs, it checks the residents’ interaction history and mines out the preference range. If the impact value falls within the preference range, then it does not detect the situation as a conflict. If the impact value falls beyond the preference range, only then is it accounted as conflict. Our proposed approach achieves a high accuracy score of about 90%. Precision, recall, and f1-scores are also high.

We conduct the third set of experiments to evaluate the conflict likelihood value based on MAE. The proposed approach performs well regarding temperature and illumination variables (Table II). The reason is our impact model can successfully capture the gradual change and instantaneous change with time granularity. It also captures users’ preference ranges, taking into account different contextual factors. However, our model does not perform well in detecting sound impact conflict. Because the proposed preference estimation model cannot extract residents’ preferences when no service request data is available. For example, a resident prefers to have less sound as they want to study. Here, the study is an activity, and there is no sound data associated with service requests. Finally, we adjust the temporal and preferential proximity values to observe the detection accuracy variation. Fig. 6 demonstrates that increasing temporal and decreasing preferential proximity capture conflicts more accurately. When the temporal threshold is small, and the preferential threshold is big, there are lots of overlapping events that are pruned. However, increasing the temporal and decreasing the preferential threshold denotes more capturing ability of conflicts.

Conflict detection and resolution are key in software engineering, especially during requirement engineering, which involves defining a system’s needs and limitations. Differences between managing conflicts in software engineering versus smart home IoT environments highlight the unique challenges in each domain:

• •

  Nature of conflicts: Software engineering conflicts often emerge from stakeholders’ differing needs during the requirements phase, usually due to misinterpretations or inconsistent priorities [21, 22]. In smart homes, conflicts arise from interactions among multiple devices, services, and users, leading to issues like resource contention or privacy concerns [23, 24].

• •

  System complexity: Smart homes involve complex, interconnected physical systems influenced by dynamic factors, necessitating consideration of physical constraints and safety [23]. Conversely, software engineering conflicts focus more on aligning stakeholder expectations without the immediate impact of real-time physical interactions [21, 22].

• •

  Stakeholders: While software engineering conflicts mainly involve human stakeholders (i.e., developers, managers, customers), smart home conflicts also include interactions between IoT devices and services, requiring a more comprehensive approach to conflict management [24].

“Conflict is a natural disagreement between different attitudes, beliefs, values, or needs” [25]. A home in Australia, on average, has 17 connected devices (i.e., services)¹¹1https://tinyurl.com/vg3lh6w. In addition, 2.6 residents usually live per household²²2https://tinyurl.com/y6jzjwf4. Therefore, there is a high chance of conflict in multi-occupant homes. The concepts of conflict and conflict detection are surveyed in the relevant literature. We identify three criteria to categorize conflicts: (i) source, (ii) intervenience, and (iii) solvability. Conflicts may occur depending on different types of sources [26]. A conflict may occur when many users utilize a resource such as a TV defined as a resource-level conflict [27]. A conflict may occur when several applications try to use a resource simultaneously. For example, application-level conflicts involve building management applications and a human trying to control a light bulb inside a room [28]. A conflict may emerge between space and the user when a user disputes space policies. For instance, a user’s smartphone may ring inside a library with a silence policy [8]. A conflict may also occur when diverse user inclinations in a similar setting are known as profile-level conflict [29]. For instance, one user likes to enjoy a TV program with the room light at half limit, and another user wants to peruse with the lights at the full limit. Time is another crucial factor for conflict detection [30].

Intervenience is a key criterion that may cause conflicts [31]. Conflict is usually common in multi-resident smart homes, yet a conflict may occur in a single-resident home. For instance, a conflict may occur based on contradictory intentions such as comfort and saving energy simultaneously. An object-oriented approach is proposed in [32] to detect conflict in a single-occupant smart home. The model is further improved in [12] by considering environmental requirements and impacts. The proposed effect model is qualitative (i.e., either an effect exists or it does not exist at all), which is the limitation of their work. Solvability is another key criterion for conflict categorization [33]. Usually, a conflict is detected during its occurrence (i.e., run-time) [34]. However, sometimes a system cannot detect conflict during its run-time and later realizes that it happened because of delayed sensor information [35].

None of the above research considers impact conflict detection of IoT services, and existing conflict detection approaches cannot be applied directly. Current frameworks recognize the relationship between actions (e.g., opening a window blind) and their environmental effects (e.g., changes in illumination) but fail to measure the actual impact. Moreover, understanding conflicts within these systems requires knowing the preferences of the people who use them, necessitating to estimate their preferences. These estimated preferences are then fed into the impact conflict detection module to assess a conflict situation. To the best of our knowledge, this work is the first attempt to quantify the impact, estimate preferences, and then develop a conflict detection approach that can capture impact conflicts with their associated likelihood values.