A conflicts’ classification for IoT-based services: a comparative survey

Overarching research question

From the authors’ point of view, to develop an IoT framework that guarantees user comfort with an acceptable level of system correctness and safety, conflicts that may occur should be well-defined and known. For this, the analysis of the literature was guided by the following research question:

How much coverage of conflict types is achieved by the current IoT verification and detection frameworks?

To answer this question, we need to determine if IoT apps conflict detection is still a relatively challenging task? Also, is it essential to develop a new IoT apps verification framework or not? These questions are compulsory identifying the current state-of-the-art of IoT-based end-users automation conflicts’ classifications and detection approaches:

• What are the existing IoT apps conflicts’ classifications?

• What are the existing IoT apps’ conflicts detection methods?

• What are the main characteristics of each conflict detection method?

Search process

To ensure that the survey is rigorous and unbiased, we conducted a review of relevant studies that address the research questions. Figure 2 shows the search process used to obtain relevant studies. The search process involves five phases of search and enhancement. The search process performed in well-known online databases, which are IEEEXplore (IEEE, 2021), ACM (ACM, 2020), Google Scholar (Scholar, 2020), Springer (Springer, 2021), and ScienceDirect (ScienceDirect, 2020).

In phase 1, the search string Eq. (1) below is created to retrieve relevant studies from aforesaid databases. We formulated this search string based on an analysis of the keywords from the relevant literature. Initially, using these search terms, we obtained plenty of potential studies in the databases. Totally, the search string produced 1536 results. (1)${\displaystyle \left(“IFTT{T}^{\prime \prime }OR“ECArule{s}^{\prime \prime }\right)AND“conflic{t}^{\prime \prime }AND\left(“detectio{n}^{\prime \prime }OR“classificatio{n}^{\prime \prime }\right)}$

In phase 2, a step-forward to minimize the results from phase 1, we filter results by refining the search string Eq. (1) by adding more keywords related to IoT systems conflicts as below in search string Eq. (2). As a result of refining the search terms, 223 studies were identified. (2)${\displaystyle \left(“IFTT{T}^{\prime \prime }OR“ECArule{s}^{\prime \prime }\right)AND“conflic{t}^{\prime \prime }AND\left(“detectio{n}^{\prime \prime }OR“classificatio{n}^{\prime \prime }\right)AND\left(“Io{T}^{\prime \prime }OR“buildingautomatio{n}^{\prime \prime }\right)AND\left(“correctnes{s}^{\prime \prime }OR“safet{y}^{\prime \prime }\right)}$

In phase 3, due to paper unavailability, redundancy, or irrelevance, we excluded those papers that satisfy these reasons. We obtained 150 studies.

In phase 4, we defined inclusion and exclusion criteria to enhance the filtering results from phase 3. Below, the inclusion and exclusion criteria used. We obtained 100 studies.

• Inc1: including the papers that provided conflict classification.

• Inc2: including the papers that described a conflict detection method.

• Exc1: excluding the papers that did not describe a conflict classification or provide a conflict detection method.

In phase 5, after using the filtering search string, inclusion and exclusion criteria, and excluding unavailable and duplicated papers, we ensure that the remaining papers are mostly related to the IoT apps conflict classifications and detection by screening both papers’ titles and abstracts. Finally, we obtained 63 studies. Figs. 3 and 4 show the distribution of reviewed papers over the defined period (between 2014 and 2020) and selected search databases, respectively.

Literature analysis of conflicts’ classification

A body of current researches focused on providing classifications of the conflicts in the context of IoT smart environment or building automation. In the following paragraphs, we reviewed relevant works on conflict classification.

For Ambient Intelligence (AmI) systems, Resendes, Carreira & Santos (2014) and Carreira, Resendes & Santos (2014) investigated and provided a conflict classification based on four dimensions, (i) source, (ii) interventions, (iii) time of detection, and (iv) solvability. Their classification provided multi-level categories for conflicts and supports the interactions either in user application, between the user application and space policy (system policy), or between different users’ applications. However, their work is limited in conflict classification and does not provide an exact or formal definition for the conflicts, or how they could be occurred. Also, all conflict categories are for one conflict type that is inconsistency conflict.

Resendes, Carreira & Santos (2014) and Homola et al. (2015) investigated the importance of conflict resolution for Knowledge Representation (KR) in AmI, where agents (i.e., user automation needs) required/consumed knowledge may cause conflicts in their interactions. Homola et al. (2015) mentioned and explained approaches that can help to solve these conflicts such as context modeling, multi-context systems, belief revision, ontology evolution, and debugging argumentation, preferences, and paraconsistent reasoning. However, the work focused on the conflict classification proposed in Resendes, Carreira & Santos (2014) and did not consider conflict resulting from violating system policies.

Homola & Patkos (2014) followed the previous two works in conflict classification and proposed a new conflict category caused by knowledge sharing between different AmI systems. They also referred to five conflict types of this category, which are (i) sensory input, (ii) context, (iii) domain and background knowledge, (iv) goal, and (v) action conflicts. Their work is ignoring conflicts against policy constraints.

The UTEA (User, Trigger, Environment entity, and Actuator) model proposed in Sun et al. (2014) provided a classification for IoT apps conflicts. Their classification contains five conflict types (i) shadow conflict, (ii) execution conflict, (iii) environment mutual conflict, (iv) direct dependence conflict, and (v) indirect dependence conflict. This classification is based on 11 rule relations. Although they provided how the conflict occurs, Sun et al. considered only the interaction between rules and the conflicts when users’ priorities are similar. Their rule relation schema depended on manual annotations of conflicts and no representation for environment and system requirements.

Based on Feature Interaction (FI), Magill & Blum (2016) provided five types of rule interaction and defined them as conflicts. These interactions are (i) shared trigger interaction, (ii) sequential action interaction, (iii) looping interaction, (iv) multiple action interaction, and (v) missed trigger interaction. Using Event Calculus (EC) with proposed detection algorithms, authors capable of detecting these conflicts. However, the work did not explain how these conflicts may appear in the run-time of automated service.

For WSAN-based smart building, Sun et al. (2016) provided a conflict classification and categorized them into two based (i) rule conflict on the device (redundancy and contradiction conflicts) and (ii) rule conflict on the environment (write-write and read-write conflicts). The proposed algorithms in their work missing the consideration of system policies and consequently forgetting its related violations.

IoTSAT framework is proposed in Mohsin et al. (2016) to detect the security risks in IoT devices. The framework is based on SMT solvers to convert each of the functional and network-level dependencies to predicate logic. For ensuring the behavioral model of IoT, some constraints are defined. The threats are classified into three types (i) context threats, (ii) trigger threats, and (iii) actuation threats.

While, HomeGuard system proposed in Chi et al. (2018) for ensuring smart home safety against threats resulting from interactions between multiple IoT apps. A categorization of the Cross-App Interference (CAI) threats has been proposed, and the detection of these threats was based on a symbolic detection module. The categorization includes three categories (i) action-interference threats (actuator race and goal conflicts), (ii) trigger-interference threats (covert triggering, self disabling, and loop triggering threats), and (iii) condition-interference threats (enabling-condition and disabling-condition threats). Although the authors cover a range of threats between IoT apps, they omit the representation of a system or environment constraints and the threats that may occur due to violating these constraints.

For security issues, the iRULER tool in Wang et al. (2019) is proposed to discover inter-rule vulnerabilities. These vulnerabilities are (i) condition bypass, (ii) condition block, (iii) action revert, (iv) action conflict, (v) action loop, and (vi) action duplicate. iRULER is based on natural language processing (NLP) methods to derive flows in trigger-action apps and verify the inter-rule interactions using Satisfiability Modulo Theories (SMT) (Barrett & Tinelli, 2018) based model checking. However, the tool not supporting complex rules (rule conditions are represented only using Boolean flags) and does not take into consideration the conflicts resulting from violating system policies.

An error categorization is explained in Palekar, Fernandes & Roesner (2019) for user programming errors in smart home behaviors. They mentioned errors like (i) lack of action reversal, (ii) feature interaction, (iii) feature chaining, (iv) event+event rules, (v) state+state rules, (vi) missing trigger, (vii) missing action, (viii) secrecy violations, and (ix) integrity violations. Their work mentioned the missing of some trigger-action platforms in handling these errors. However, the work missing to mention the level of conflicts, they only focused on checking these conflicts during the user authoring process.

Using TAP rules, Brackenbury et al. (2019) explained using testing the bugs related to the rules. They categorize bugs into three categories, (i) control flow, (ii) timing, and (iii) inaccurate user expectations. Although the work provided more conflict types, they did not make allowances for the bugs that may result from policy violations and composite service violations against policies. Shah et al. (2019) proposed a schema to detect rule conflicts, which include execution, independent, shadow, and rule incompleteness conflicts. But, considered only conflicts in actions of the rules (e.g., contradiction or false impact actions) and no representation for environment or system requirements.

A conflict taxonomy and detection model are proposed in Alharithi (2019). Conflicts are considered for multiple user-defined policies’ interactions. The taxonomy categorizes the conflicts into two main categories, (i) direct conflicts (e.g., opposite conflict, overwrite conflict, and environmental conflict) and (ii) indirect conflicts (e.g., chain conflict, feedback conflict, and environmental conflict). Static analysis is used to detect the interaction between IFTTT rules. Although the taxonomy provided a range of policy conflicts, it did not provide methods to resolve the detected conflicts. Also, it did not take into consideration the conflicts that may result due to violating the system policies.

The work presented in Huang, Bouguettaya & Mistry (2020) investigated the rule interactions in single user’s rules by proposing an ontology to represent different contexts of IoT applications. Using this ontology, the framework categorized the conflicts into three categories (i) environment related conflicts (i.e., opposite environment conflict, additive environment conflict, and transitive environment conflict), (ii) action related conflict (i.e., contradiction conflict), and (ii) quality related conflict (i.e., contradiction conflict only for Integer devices). However, detecting conflicts is based on knowledge-based IoT-services (conflict annotations) which written by a domain expert. Also, based on the setting of time threshold, which requires techniques to determine the suitable ones. Moreover, the same IoT service property is used for two different conflicts, which may confuse the detecting process (e.g., brightness is used for quality conflict and additive environment conflict).

In Chaki, Bouguettaya & Mistry (2020) and Chaki & Bouguettaya (2020) a hybrid framework to detect conflicts is proposed. The framework has a knowledge-driven approach represented in an ontology to model and describe the conflicts in both functional (i.e., On/Off of a device) and non-functional (e.g., Temperature value) properties of IoT services. Also, it has a data-driven approach represented using IoT service usage history. However, conflict detection is based on peoples’ service usage history, which not suitable for real-time (dynamic) IoT service requests. Policy violations are neglected.

Trimananda et al. (2020) provided a study of pairwise IoT apps interactions to determine app conflicts. They categorize the conflicts into three groups, (i) conflicts resulting from accessing the same device with incompatible values, (ii) conflicts resulting from physical interactions as app chain, and (iii) conflicts resulting from modifying the same global variable. To detect these conflicts, the IoTCheck tool is implemented based on the Java Pathfinder (JPF) model checking infrastructure (Visser et al., 2003). A drawback of IoTCheck is that, the IoTCheck’s performance due to the use of JPF and Groovy language (Groovy, 2020). Moreover, IoTCheck focused only on three types of conflicts ignoring conflicts between multiple app interactions and system policy violations.

The IoTCOM approach is proposed in Alhanahnah, Stevens & Bagheri (2020). IoTCOM is based on the static analysis of behavioral models of IoT apps and formal methods to detect the security and safety violations against some predefined IoT safety and security properties. IoTCOM classifies the potential multi-IoT app coordination threats into seven classes, (i) action-trigger, (ii) action-condition (match), (iii) action-condition (no match), (iv) self coordination, (v) action-action (conflict), (vi) action-action (repeat), and vii) exclusive event coordination. Although IoTCOM investigates the coordination between IoT apps, it is omitting conflicts resulting from properties violation and co-exists of IoT apps that violate these properties. Also, IoTCOM did not provide resolution methods for the detected threats.

Literature analysis of conflict detection

Different methods and approaches are developed for ensuring the interactions between automation services and system policies in IoT systems by detecting various conflicts that maybe happened in these interactions. The following is a brief explanation of current IoT app conflict detection methods.

Rule and constraint formalization

The rule and the constraint forms for representing user’ automation service or system policy used in this work are as follows:

Simple trigger A rule structure or policy constraint that specifies a Boolean expression over one or two devices.

Arithmetic operation A rule structure for specifying a Boolean expression that involving an arithmetic operation in its condition part.

Admissible range A rule condition part or a policy constraint that identifies a specific range of valid values for a device.

Device grouping A policy constraint structure used to specify conjunction or disjunction over a set of devices.

Direct actuation A rule structure used to specify conjunction over a set of devices that affect system state directly without specifying a condition part.

Translating these rules or constraints requires caring about computer-spoken logic. One of the logic formalisms that may be used to formalize real-life IoT applications is First-order logic (FOL). FOL is used to express IoT applications as an arrangement of action effects on IoT resources.

Among SMT-based languages that formulates the inputs to SMT-based model checkers (e.g., Z3 (De Moura & Bjørner, 2008), MathSAT5 (Cimatti et al., 2013), Yices (Dutertre & De Moura, 2006), and Boolector (Brummayer & Biere, 2009)) is the standard SMT-Lib v2 language (Barrett, Stump & Tinelli, 2010). Both services’ rules and policies’ constraints are translated to assertions in the form C =  > A, where C and A are FOL formulae over one or more theories. These assertion in this form means if-this-then-that, or conditional expression that changes the system state as specified in A when the system has a situation state satisfying C. The translation using Barrett, Stump & Tinelli (2010) will take this general form,

where variable represents the device name, sort represents Boolean or Integer types for devices, and assertion represents the transformation of the rule forms (mentioned in Section ‘Introduction’) as specified by the user.

For instance, the automation service of a lecturer who wants to adjust the indoor environment temperature by letting fresh air entering the lecture hall when the number of students is more than 60. Additionally, suppose a faculty admin who wants to save energy in the lecture hall, saying that, if no one is in the lecture hall, then the air-conditioner should always be off. These examples can be converted to SMT-Lib v2, respectively as follows,

Conflict notations and types

Tuttlies, Schiele & Becker (2007) specified the conflict concerning end-user service or system policy as “...a context change that leads to a state of the environment which is considered inadmissible by the application or user”. In our proposed conflicts’ classification, as shown in Fig. 5, we identified two main conflict categories. Firstly, local conflicts are those conflicts that occur between intra-rules or intra-constraints of the same automation service or policy authored by the same user or the same admin, respectively. The reasons for this type of conflict are the missing of programming erudite of end-users and less knowledge about devices’ interaction relationships. Secondly, global conflicts are those conflicts that may occur in inter-interactions between different automation services or between different policies. Overlapping in spatio-temporal attributes and violating system policies are the main reasons for these types of conflicts.

These two main categories (local and dynamic conflicts) are related to a level-based category, which indicates where the conflict may occur. There are two levels, Service Level Conflicts (SLCs) and Policy Level Conflicts (PLCs). SLCs are the conflicts that may happen in service rules, either local or global. On the other hand, PLCs are the conflicts that may happen in policy constraints, either locally or globally.

For defining conflicts in a low level of a classification hierarchy, Table 1 provides the notations used for describing these conflicts in a formal specification. Also, we started by defining the concept of Rule Satisfiability Measure (RSM). RSM allows us to assess and filter the rules. RSM is the state of the SMT-based checker (i.e., SAT or UNSAT) when checking conjunctions of rule parts (i.e., conditions and actions). In respect of simplifying the conflicts definition, we will use Venn diagram to represent the relation between the rule parts. There are two cases for the diagram. The former case is when the Venn diagram has no superimposition, that represents the “UNSAT” state determined by the solver. The latter is when the Venn diagram has a superimposition, that represents the “SAT” state determined by the solver.

One or more of the following conflict situations may occur between the two rules under the assumption which they shared the same location and have time overlapping. These conflicts should be taken into consideration to ensure overall system correctness, security, and safety issues, as violating any of them may lead to danger or harm situations.

Rule Dependency Conflict (RDC) For two or more rules, this conflict occurs when the actions resulting from satisfying the conditions of one rule leads to trigger the second rule, where its actions lead to the triggering of the first rule, creating an infinite cycle of these rule interactions.

This conflict is mentioned in Ibrhim et al. (2020) and also known as Confluence Property in Corradini et al. (2015) and Looping Interaction in Magill & Blum (2016). Figure 6 shows a Venn diagram for this conflict. Formally, this conflict can be described as follows: (3)${\displaystyle \stackrel{\text{RDC}}{\perp }:=\left\{\begin{array}{c}\exists R^{ij}and{R}^{ik}\in \text{the same service i where}j\ne k,\hfill \\ \exists d1\in \left\{D^{R_c^{ij}},D^{R_a^{ik}}\right\},\exists d2\in \left\{D^{R_a^{ij}},D^{R_c^{ik}}\right\},and\hfill \\ \exists v\in V^{R_c^{ij}}:\left(R_c^{ij}\cap \neg R_a^{ik}\right)\mapsto UNSATand\hfill \\ \left(R_a^{ij}\cap \neg R_c^{ik}\right)\mapsto UNSAT\hfill \end{array}\right.}$

Consider the above example, we say that R¹¹ $\stackrel{\text{RDC}}{\perp }$ R¹² according to the definition provided in Eq. (3). In other words, when the rule R¹¹ is triggered by a system situation and its actions affects the environment, the second rule R¹² will be activated, which in turn leads to satisfying the conditions of R¹¹, and so on.

Rule Redundancy Conflict (RRC) For any two rules, this conflict may occur when the system has at least one valid situation which satisfies the conditions of the rules and the actions of one rule is a subset of the actions of the second rule.

This conflict is mentioned in Ibrhim et al. (2020) and also known as Shadow Conflict in Le Guilly et al. (2016). Figure 7 shows the Venn diagram for the conflict. Formally, this conflict can be described as follows: (4)${\displaystyle \stackrel{\text{RRC}}{\perp }:=\left\{\begin{array}{c}\exists R^{ij}and{R}^{ik}\in \text{the same service i where}j\ne k,\hfill \\ \exists d1\in \left\{D^{R_c^{ij}},D^{R_c^{ik}}\right\},\exists d2\in \left\{D^{R_a^{ij}},D^{R_a^{ik}}\right\},and\hfill \\ \exists v\in V^{R_c^{ij}}:\left(R_c^{ij}\cap \neg R_c^{ik}\right)\mapsto UNSATand\hfill \\ \left(R_a^{ij}\cap \neg R_a^{ik}\right)\mapsto UNSAT\hfill \end{array}\right.}$

Giving the above example, we say that R¹² $\stackrel{\text{RRC}}{\perp }$ R¹¹ (i.e., R¹² is redundant based on R¹¹) according to the definition provided in Eq. (4). In other words, it is not possible to assign values to the variables (Temperature and Occupancy) to satisfy (Temperature >  = 25∩Occupancy = True)∩¬(Occupancy = True). Also, there is no assignment to the variables (Fan and Window) that satisfied this conjunction (Fan = True∩Window = True)∩¬(Fan = True).

Value Inconsistency Conflict (VIC) For any two rules, this conflict may occur when the system has at least one valid situation that leads to the triggering of these rules and their actions change the state of the shared devices in a contradicting way. A service rule and a policy constraint may have this conflict as well.

This conflict is mentioned in Ibrhim et al. (2020) also known as Contradiction Conflict in Sun et al. (2016), Execution Conflict in Sun et al. (2014) and referred to as Termination Property in Corradini et al. (2015). Figure 8 shows the Venn diagram for the conflict. Formally, this conflict can be described as follows: (5)${\displaystyle \stackrel{\text{VIC}}{\perp }:=\left\{\begin{array}{c}\exists R^{ij}and{R}^{ik}\in \text{the same service i where}j\ne k,\hfill \\ \exists d1\in \left\{D^{R_c^{ij}},D^{R_c^{ik}}\right\},\exists d2\in \left\{D^{R_a^{ij}},D^{R_a^{ik}}\right\},and\hfill \\ \exists v\in V^{R_c^{ij}}:\left(R_c^{ij}\cap \neg R_c^{ik}\right)\mapsto UNSATand\hfill \\ \left(R_a^{ij}\cap R_a^{ik}\right)\mapsto UNSAT\hfill \end{array}\right.}$

Giving the above example, we say that R¹¹ $\stackrel{\text{VIC}}{\perp }$ R¹² according to the definition provided in Eq. (5). In other words, every time R¹¹ is triggered, R¹² is triggered as well, but the actions of the two rules cannot be simultaneously satisfied, as there is no valid assignment that satisfies (Temperature >  = 25∩Occupancy = True)∩¬(Occupancy = True), and there is no valid assignment that satisfies the rules’ actions simultaneously (Fan = True)∩(Fan = False). (6)${\displaystyle \stackrel{\text{VIC}}{\perp }:=\left\{\begin{array}{c}\exists C^{mn}and{R}^{ij},\hfill \\ \exists d\in \left\{D^{C^{mn}},D^{R_a^{ij}}\right\},and\hfill \\ \forall v\in V^{C^{mn}}:\left(C^{mn}\cap R_a^{ij}\right)\mapsto UNSAT\hfill \end{array}\right.}$

When VIC occurs between an automation service and a system policy constraint, as shown in Fig. 9, we say that R¹¹ $\stackrel{\text{VIC}}{\perp }$ C¹¹ according to the second description of $\stackrel{\text{VIC}}{\perp }$ provided in Eq. (6). For example, consider the following service rule and policy constraint. There is no satisfying assignment for (ACThermostat > 22)∩(AirConditioner = True∩ACThermostat = 18).

Condition Inconsistency Conflict (CIC) For two rules, we say that there is a CIC conflict/warning when rules’ conditions are contradicting and the actions of one rule are considered a subset of the other rule’s actions.

This conflict is mentioned in Ibrhim et al. (2020). Figure 10 shows the Venn diagram for the conflict. Formally, this conflict can be described as follows: (7)${\displaystyle \stackrel{\text{CIC}}{\perp }:=\left\{\begin{array}{c}\exists R^{ij}and{R}^{ik}\in \text{the same service i where}j\ne k,\hfill \\ \exists d1\in \left\{D^{R_c^{ij}},D^{R_c^{ik}}\right\},\exists d2\in \left\{D^{R_a^{ij}},D^{R_a^{ik}}\right\},and\hfill \\ \forall v\in V:\left(R_c^{ij}\cap R_c^{ik}\right)\mapsto UNSATand\hfill \\ \left(R_a^{ij}\cap \neg R_a^{ik}\right)\mapsto UNSAT\hfill \end{array}\right.}$

For clarity, the situations where this conflict may occur is not always considered as conflict but could be considered as a warning or potential conflict, where the end-user can be notified that she writes something error. According to the end user’s intentions or preferences, she can report this as a conflict or warning.

In the above example, we say that R¹¹ $\stackrel{\text{CIC}}{\perp }$ C¹² according to the definition provided in Eq. (7). In other words, the action of R¹¹ supersedes the action of R¹², but the two rules cannot be simultaneously triggered. For the above rules, there is no valid assignment to satisfy neither (Temperature >  = 30)∩(Temperature < 30), but for (AirConditioner = True)∩(AirConditioner = True) there is a valid assignment. In this example, the state of AirConditioner is always ON, which will increase the energy consumption, therefore the end-users considers it as a conflict.

On the other hand, CIC can be handled as a warning. Consider the following two rules, while there is no valid assignment to satisfy neither (UseratHome = True)∩(UseratHome = False), but for (SecurityCamera = True)∩(SecurityCamera = True) there is a valid assignment. In this example, the preference of the end-user may need is the Security Camera to be always running in either he is at home or not, therefore the end-user may notify about this state “Does it legal for him or not”.

Race Condition Conflict (RCC) When the system has at least one valid situation whereby two different rules’ conditions are satisfied (or triggered together after a while) concurrently, and their actions need to update the system state of the shared devices in different ways, letting the system be in a non-specified state. A service rule and a policy constraint may have this conflict as well.

This conflict is mentioned in Ibrhim et al. (2020) as Non-Specified Conflict, called Race Condition in Celik, Tan & McDaniel (2019), and discussed in Nacci et al. (2018) for rules that have temporal patterns in their conditions. Figure 11 shows the Venn diagram for the conflict. Formally, this conflict can be described as follows: (8)${\displaystyle \stackrel{\text{RCC}}{\perp }:=\left\{\begin{array}{c}\exists R^{ij}and{R}^{ik}\in \text{the same service i where}j\ne k,\hfill \\ \forall d1\in D^{R_c^{ij}}d1⁄\in D^{R_c^{ik}},\exists d2\in \left\{D^{R_a^{ij}},D^{R_a^{ik}}\right\},and\hfill \\ \exists v1\in V:\left(R_c^{ij}\cap R_c^{ik}\right)\mapsto SATand\hfill \\ \left(R_a^{ij}\cap R_a^{ik}\right)\mapsto UNSAT\hfill \\ \exists v2\in V:\left(R_c^{ij}\cap \neg R_c^{ik}\right)\mapsto SATand\hfill \\ \left(R_a^{ij}\cap R_a^{ik}\right)\mapsto UNSAT\hfill \end{array}\right.}$

In the above example, we say that R¹¹ $\stackrel{\text{RCC}}{\perp }$ C¹² according to the definition provided in Eq. (8). In other words, the rules actions are contradicting but there is a possibility of simultaneously triggering both rules. There is valid assignment that satisfies (Occupancy = True)∩¬(Temperature > 30) and a valid assignment that satisfies (Occupancy = True)∩(Temperature > 30), but for the actions in both cases have no valid assignment that satisfies (AirConditioner = True)∩(AirConditioner = False).

On the other hand, when RCC conflict occurs with a policy constraint, consider for example the below service rule and policy constraint. Here, we could say that an RCC conflict will occur after a while (e.g., after 5 min) or the rule has a chronological pattern to be executed, and the rule’s actions violating the policy constraint which try to make the location more suitable in emergencies.

Useless Rule Conflict (URC) When a rule’s conditions are violating all the admissible values determined by a policy constraint (i.e., the semantic rule for a device), we say that the rule is useless.

This conflict is mentioned in Ibrhim et al. (2020), called Unused Rules in Vannucchi et al. (2017), and known as Policy Violation in Liang et al. (2016a). Figure 12 shows the Venn diagram for the conflict. Formally, this conflict can be described as follows: (9)${\displaystyle \stackrel{\text{URC}}{\perp }:=\left\{\begin{array}{c}\exists C^{mn}and{R}^{ij},\hfill \\ \exists d1\in \left\{D^{C^{mn}},D^{R_c^{ij}}\right\},and\hfill \\ \forall v\in V^{C^{mn}}:\left(C^{mn}\cap R_c^{ij}\right)\mapsto UNSAT\hfill \end{array}\right.}$

Taken separately, a useless rule is considered syntactically valid according to the user preferences. However, when combined with policy constraints, it has no semantic and has no chance of running because its condition is not achievable given the policy constraints.

With respect to the given example, we say that R¹¹ $\stackrel{\text{URC}}{\perp }$ C¹¹ according to the definition provided in Eq. (9). In other words, R¹¹ should never be triggered because its condition should never occur. There is no valid assignment to satisfy (CO2 <  = 1000)∩(CO2 > 1000). Here, the policy constraint is defined as the admissible values for the smoke level in a location of interest, and because the user’s intentions breakdown this range of safety, his rule is classified as conflict.

Range Incomplete Conflict (RIC) For a service rule and a policy constraint when the rule’s conditions satisfy some values of the inadmissible range specified by the constraint.

This conflict is mentioned in Ibrhim et al. (2020) and known as Incorrect Rules in Vannucchi et al. (2017). Figure 13 shows the Venn diagram for the conflict. Formally, this conflict can be described as follows: (10)${\displaystyle \stackrel{\text{RIC}}{\perp }:=\left\{\begin{array}{c}\exists C^{mn}and{R}^{ij},\hfill \\ \exists d1\in \left\{D^{C_a^{mn}},D^{R_c^{ij}}\right\},\exists d2\in \left\{D^{C_c^{mn}},D^{R_a^{ij}}\right\},and\hfill \\ \exists v1\in V^{R_c^{ij}}:\left(C_a^{mn}\cap R_c^{ij}\right)\mapsto SATand\hfill \\ \left(C_c^{mn}\cap \neg R_a^{ij}\right)\mapsto UNSAT\hfill \\ \exists v2\in V^{R_c^{ij}}:\left(C_a^{mn}\cap \neg R_c^{ij}\right)\mapsto SATand\hfill \\ \left(C_c^{mn}\cap \neg R_a^{ij}\right)\mapsto UNSAT\hfill \end{array}\right.}$

With respect to the given example, we say that R¹¹ $\stackrel{\text{RIC}}{\perp }$ C¹¹ according to the definition provided in Eq. (10). In other words, there is a satisfying assignment for (Temperature > 25)∩(Temperature > 28), and also for (Temperature > 25)∩¬(Temperature > 28).

Joint-behavior Services Conflict (JBsC) When there is at least one valid system situation that triggers two rule conditions belonging to two different users and their joint actions violate a policy constraint.

A case of this conflict is defined in Celik, Tan & McDaniel (2019) under some assumptions. Figure 14 shows the Venn diagram for the conflict. Formally, this conflict can be described as follows: (11)${\displaystyle \stackrel{\text{JBsC}}{\perp }:=\left\{\begin{array}{c}\exists C^{mn},R^{ij},and{R}^{kl},\hfill \\ \forall d1\in D^{R_c^{ij}},d1⁄\in D^{R_c^{kl}},\forall d2\in D^{R_a^{ij}},d2⁄\in D^{R_a^{kl}},and\hfill \\ \exists v1\in V:\left(R_c^{ij}\cap R_c^{kl}\right)\mapsto SAT\hfill \\ \left(C_c^{mn}\cap \left(R_a^{ij}\cap R_a^{kl}\right)\right)\mapsto UNSAT\hfill \end{array}\right.}$

As stated in the above example, we say that R¹¹ and R²¹ $\stackrel{\text{JBsC}}{\perp }$ C¹¹ according to the definition provided in Eq. (11). In other words, there is no satisfying assignment for ¬(Window = True∩AirConditioner = True)∩(Window = True∩AirConditioner = True).

Device-influence Conflict (DIC) For two or more service rules when there is at least one valid system situation triggers the rules and there exists a shared environment entity (e.g., temperature, humidity, light) between them, where their actions affecting this entity in contradicting ways (i.e., affecting the performance of the actions’ devices of the other rule).

This conflict is discussed in Shah et al. (2019) and called Opposite-environment-conflict in Huang, Bouguettaya & Mistry (2020). Consider the following situation example in Huang, Bouguettaya & Mistry (2020), suppose a rule that lets the window opened in hot summer while there exists another rule that opens AC for cooling the same location. In this example, opening the window will influence the environment entity “temperature”, which in turn dramatically affects the AC performance. This conflict may be considered as a subset of RCC with policy, where if we suppose there is a policy constraint that says,“ window must be closed when AC is running” to ensure that the system is working in a safe state, this situation can be detected as RCC conflicts.

Integrity Violation (IV) For a service rule, when rule’s conditions may be triggered by a third party app or another unauthorized user (e.g., intruder) rule, and its actions directly affect the user’ environment.

This violation is discussed in Celik, Tan & McDaniel (2019). Integrity situations could be occurred due to the deliberate effect of sabotage by using counterfeit components. For example, consider the below service rule. If we suppose that an intruder can deliberately affect the temperature sensor attached outside the building to increase the temperature value, he can affect the user’s indoor environment by letting the air-conditioner turn on.

Confidentiality Violation (CV) For a user service rule when rule’s conditions are satisfied/triggered by the user or system situation and its actions make the information disclosed to a third party app without rule owner consent. This violation is discussed in Babun et al. (2019).

For example, consider the above service rule. The rule will post a financial report about a meeting on Facebook when the meeting is ended. Here, the financial reports are considered a piece of private information that must not be shared publicly.

Privacy Violation (PV) For a user service rule, this violation occurs when the rule’s conditions are satisfied by a system state, and its actions breakdown the privacy obligations of either the rule owner or others. This violation is discussed in (Celik et al., 2018; Bastys, Balliu & Sabelfeld, 2018; Tawalbeh et al., 2020).

For example, consider the above service rule. The rule will turn on the security camera and send pictures about strangers trying to enter the office, while the user is out of his office and there is a motion near to the office. There are two cases for this rule’s actions: one case, if we suppose that these pictures are sent to the rule owner (e.g., his phone) securely, this rule will not consider a violation, since the data is now secure. The other case, if no security on the sending process this rule will violate the privacy of others (e.g., pictures of others may be sniffed by intruders). Babun et al. (2019) suggested when the end-users have a tool by which they can express their privacy preferences, makes the system more secure.

Insights gained from qualitative comparison

Grouping the relevant works according to the proposed conflicts’ classification allows us to obtain limitations in the current IoT methods and frameworks of detecting interactions conflicts and insights that will be useful in future IoT automation frameworks as follows:

• In Table 2, the Conflict Coverage column is used to represent the percentage between the total number of conflicts in the proposed classification and the number of conflicts covered by the method or tool. Using this percentage, we can determine the capability of the method or tool. For example, approaches proposed in (Hadj et al., 2016; Melissaris, Shaw & Martonosi, 2019; Li, Zhang & Shen, 2019; Chen et al., 2019) cover fewer number of conflicts, which affect in the overall system correctness and user safety. On the other hand, methods such as (Mohsin et al., 2016; Celik, Tan & McDaniel, 2019; Ibrhim et al., 2020) although they need more enhancement, they cover a set of mentioned conflict types in the proposed classification.

• A notable gap in previous works is represented in the sparse focusing on the conflicts detection and not covering different conflict types. Figure 15 shows a classification of conflicts’ detection by year according to the reviewed papers across the defined period of time. From the figure we could determine the most conflict types that take more researchers attentions such as VIC, RCC, and RDC. On the other side, conflicts such as CIC, IV, CV, PV, RIC, and JBsC have a little attention in the reviewed studies, this is due to different reasons. For instance, in Vannucchi et al. (2017), although it uses the same symbolic verification model checker as in our work proposed in this paper, it fails to detect VIC, RCC, and JBsC conflicts. The reasons for this are, the work in Vannucchi et al. (2017) using different ways to detect the conflict, where it includes the invariants to detect the conflicts, and it depends on a single IoT app with its invariants. For instance, RRC in their work is detected only using invariants. Also, IoTGuard in Celik, Tan & McDaniel (2019) used another symbolic verification model checker to detect conflicts between multiple IoT apps. However, it fails to detect the JBsC conflict because the unified dynamic model generated by their work required the IoT apps to have a chain of events. According to our work, the JBsC conflict may occur between multiple IoT apps without having this event chain. Similar, the interactions across applications influence discussed in Chen et al. (2019) require apps to share an environment entity (temperature) to detect the influence. So, it fails to detect the JBsC conflict when the app does not share devices or environment entities. Approaches proposed in (Shah et al., 2019; Huang, Bouguettaya & Mistry, 2020) are depending on manual annotations for detecting the conflicts that suffer from rigidity and not suitable for the dynamic and high complexity nature of users intentions. Corradini et al. (2015), Despite having the meaning of constraints over devices, IRON did not consider the conflicts that violate these constraints. (Li, Zhang & Shen, 2019), Like our work, the authors of this paper use SMT solver in conflict detection. In our work, we analyze the relationships between IoT apps rules which provide more insights about conflicts. Also, the work in Li, Zhang & Shen (2019) is missing the representation of system requirements as constraints which are missing in their work.

• The RVF framework proposed in Ibrhim et al. (2020) covers a good set of conflicts as indicated in Table 2. RVF framework provides an incremented and iteratively manner in detecting the intra-automation service and inter-automation services conflicts. Firstly, RVF begins to collect the IoT app’s meta-data (e.g., rules, location, execution period, etc.) and converts its rules into an intermediate representation, SMT-Lib v2 language, to be used within SMT solver. After that, it starts checking the IoT app’s rules against themselves to detect local conflicts. When such conflicts do not exist, it forwards these rules to the next checking step that is responsible for detecting global conflicts. The global checking within RVF is determined by searching for the overlapping IoT apps in both location and time meta-data. The advantage of using this incremented and iteratively manner is that it adds an acceptable of ensuring that the IoT app will never be executed until all conflicts are detected. For the sake of detecting different levels and types of conflicts, RVF depends on rule relationship analysis using SMT based solver. However, RVF fails to detect DIC, IV, CV, and PV conflicts because the rule representation used in it does not include the representation of devices’ effects on each other.

• Although the state-of-the-art for IoT apps’ interactions conflicts detection provide different frameworks and methods, whereas some issues still exist and need to be covered in the future development of IoT verification systems. Among the shortage in the current verification and detection methods are as follows: The works that proposed parser-based methods such as (Wang et al., 2019; Chen et al., 2019) are built under the assumption that the user inputs are always correct, which does not happen in reality. Also, facing the NLP classification errors. The proposed method in Xiao et al. (2019) utilizing different tools to able to analyze the rule structures. In addition to this, these methods suffer from analyzing rules such as “IF living room temperature is hot THEN cool down the room temperature”. Such rules that express the user preferences using words instead of Boolean or Integer valued parameters need the using of the string-supported model checker as (Liang et al., 2016b; Abdulla et al., 2015) which supporting the combination of string constraints and linear integer arithmetic. On the other hand, the methods as (Magill & Blum, 2016; Sun et al., 2014) either depend on manual annotations of conflicts without checking the validity of these annotations using model checkers or did not provide the definitions of other conflicts. Also, these methods are missing of representing the environment entities that could be affected by different devices; for example, illumination could be affected by a rule that opens a window or another rule that open lights. Adding to this, using single logic for rules interpretations (Ibrhim et al., 2020) and others is missing of representing the description of some conflicts like Integrity, Confidentiality, and Privacy. SMT-based methods are missing of representing temporal behaviors rules (i.e., Time-based rules), where rules have some chronological patterns represented by the temporal operators (e.g., FUTURE, PAST, UNTIL, AFTER, BEFORE), instead of representing time as a monotonically increasing variable, where time is considered as a device like a temperature sensor that can send its value when required. Omitting the representation of the temporal operators adds a drawback in the rules’ relationships analysis to detect more conflicts. For the sake of covering these issues, we recommend using a hybrid approach that combines model checking with a variety of languages and semantic technologies in developing future IoT-based apps verification frameworks to cover all levels and types of conflicts to guarantee and maximize the safety, security, and correctness of IoT systems.

• Like Shehata, Eberlein & Fapojuwo (2007), the work distinguishes between two types of IoT apps, which are automation service and system policy, as indicated in Table 2, PLCs are ignored in state-of-the-art conflict detection approaches, maybe due to they suppose that the constraints of the policy do not need to be checked because of its domain expert’s (administrator, a person who has the authority to write policies) responsibilities. But, in the proposed conflicts’ classification, both policies, and automation services are checked against conflicts. Suppose, for example, a location may have more than one administrator, so policy’ constraints must check against themselves and other policies.

• Levels of checking process in previous approaches and tools have the limitation of not supporting different automation services checking level. Figure 16 shows that the conflicts resulting from the interactions between different IoT apps are the main focus in the reviewed papers. As seen in Table 2, Conflict Classification, the previous works in IoT apps conflicts’ classifications focused mainly on IoT apps rules conflicts either the rules belong to a single app (Sun et al., 2014; Wang et al., 2019; Shah et al., 2019) or multiple apps (Chi et al., 2018; Chaki, Bouguettaya & Mistry, 2020; Trimananda et al., 2020). Little attentions come for violating system policies, these attentions are elucidated in value inconsistency conflict. According to the proposed conflicts’ classification which suggests performing the checking and detecting of interactions conflicts in different levels, as shown in Fig. 17. For instance, for the SLCs, there are two levels of checking, Firstly, in (1) the rules authored by the non-technical user are checked against themselves to detect local conflicts. Secondly, in the case of no local conflicts, the rules are checked to detect global conflicts (2). This level includes three checking steps, which are (2-a) to check rules against the system policies in the same location, (2-b) to check rules against the shared spatial–temporal services for other users, and (2-c) to check each services pair owned by different users against the joint-behavior conflict.

• The proposed conflicts’ classification intended use is within smart buildings, smart campus, or any smart consumer of IoT resources. Also, it is based on a general condition-action paradigm with some rules and constraints structures. So, for completing the picture and take more and more advantages from the classification, a standard representation for both automation service rules and system policies which include different IoT platforms (e.g., SmartThings, IFTTT, Zapier, OpenHAB, etc.) is required. The main required feature in this standard representation is the capability of expressing the end-users heterogeneity and complex preferences. With this standard representation, IoT systems developers can make more IoT apps’ interactions analysis and take correct decisions for both design time and run time errors and conflicts during the development step of such systems.

• Our survey opens a new research direction in the area of developing custom or domain-specific compilers for the IoT systems verification context. In this context, almost all components (e.g., infrastructures, involved users, applied technologies, services, etc.) within it are characterized by the dynamic nature, which requires the development of compilers that is capable of not only detecting the end-users programming errors but also has the ability to mitigate and resolve conflicts resulting from interacting IoT apps in different levels (i.e., during IoT app design time and within its run time). At last, we suggest using/adding our conflicts’ classification in the future formal verification methods or even compilers related to IoT systems, as a part that is responsible for ensuring the correctness and safety of end-users programmed IoT applications.