A home network system (HNS) consists of multiple networked appliances connected to the local area network at home. Each networked appliance has control APIs, with which users or software agents can control the appliance via the network. Each appliance is generally equipped with a network adapter, a processor and a storage.

A HNS typically involves a home server, which manages all the appliances deployed. It also plays a role of gateway to the external network. More importantly, various value-added services are installed in the home server. When a service is requested, the home server executes APIs of the appliances according to the logic specified in the service. As seen in Section 1, a service can orchestrate different appliances at the same time. In our research group, we are building an actual HNS (CS27-HNS) using legacy home appliances [5].

Introducing sensors to the HNS can make the services autonomous and context-aware. Since the sensors can capture events and contexts, we use them as triggers of the service. In this paper, we write sensor-driven service to represent any HNS service triggered by a sensor. For example, let us take Automatic Light Control Service (ALC) in Section 1. The condition “the brightness is lower than 200 lx” can be evaluated by a light sensor. Thus, ALC can be implemented as a program which invokes API Light.on() when the reading of the light sensor becomes less than 200.

The sensor-driven services are smart and convenient in the sense that they do not require human operations. However, if many services are deployed in the same environment, they often cause unexpected service chains, as seen in Section 1. Since the number of potential service chains grows combinatorially in the number of services, we need a systematic method to detect and resolve the service chains.

In our previous work [3,4], we proposed an object-oriented modeling method to formalize and detect feature interactions in the HNS. In this method, we modeled every appliance (or an environment) as an object with properties and methods. The properties characterize the internal state of the appliance (or the environment), while the methods correspond to the API. Also, we defined every service as a sequence m₁(); m₂(); …; m_n() of the appliance methods. Then, we defined that a feature interaction between services s₁ and s₂ occurs if a method m() of s₁ and another method m′() of s₂ conflict, either locally on an appliance object (called, appliance interaction) or indirectly via an environment object (called, environment interaction). However, this method assumed that every service is triggered manually by the user. Thus, the sensor-driven services and the incidental service chains were beyond the scope.

In order to capture the nature of the sensor-driven services, we here introduce the ECA (event, condition, action) rules [6] for the service description. A sensor-driven service S is defined by S = (E_S, C_S, A_S) where

E_S is an event that triggers S, which is defined by a condition over a single environment property.

This model newly involves the event and condition, compared to the one in the previous work.

Figure 1 shows service descriptions of seven sensor-driven services, including the 4 services seen in Section 1 and 3 more described below.

In Figure 1, env denotes a prefix of an environment property. Each event (or condition) is supposed to be detected (or evaluated, respectively) by appropriate sensors in the HNS. In each action, A.m() denotes a method m() of an appliance A. Let us take the description of ALC. The event of ALC is env.brightness < 200, specifying that the service is triggered when the brightness is less that 200 lx. The condition env.absence == false means that the service should be enabled only when somebody is in the room. If ALC is executed, the light is turned on with brightness level 10 as specified in the action Light.setBrightness(10).

To detect the service chains, we have to know how much effect is given to the environment as a result of a service. Such effect is produced by appliance methods executed as an action of the service. For example, Light.on() increases env.brightness, and Air-Conditioner.cooling() decreases env.temperature. Therefore, we propose an environment effect model for each appliance, to define explicitly how the appliance gives the environmental effects.

As shown in Section 2.3, every appliance can be regarded as an object with internal states. Therefore, we model every appliance as an FSM (finite state machine) specifying the effects within transitions. Let d be an appliance. The environment effect model of d is defined by an FSM EM_d = (S_d, M_d, T_d, s₀, e_d), where

S_d is a set of states of d.

Tables 1 shows the environment effect models of an air-conditioner, a TV and a light, respectively. Each table describes an FSM in a table form, where a row represent a state, a column represents a method. Each entry represents a state transition, containing the effects to the environment and the next state (labeled by next). In the effects, =, += and −= respectively represent substitution, addition and subtraction operators. For example, Table 1(b) represents that the TV has two states OFF and ON. If method on() is executed within OFF, the state moves to ON. At this time, as the environment effects, the electricity is increased by 500 Wm, and the brightness is increased by 200 lx.

A service chain occurs when the result of one service triggers another service, successively. We try to formalize this mechanism using the proposed service description and the environment effect model. Let S_A = (E_SA, C_SA, A_SA) and S_B = (E_SB, C_SB, A_SB) be two services. A service chain from S_A to S_B, denoted by S_A ⇒ S_B, occurs when the environment effects produced in A_SA create an environment (state) where E_SB is satisfied. A chain S_A ⇒ S_B may cause another chain S_B ⇒ S_C, creating S_A ⇒ S_B ⇒ S_C. Also, if S_B triggers S_A again, then a loop S_A ⇒ S_B ⇒ S_A ⇒ S_B ⇒ … may be produced.

Note that the occurrence of S_A ⇒ S_B is conditional. That is, it depends on the current states of the appliances and the environment. For example, for ALC⇒ESAC in Section 1, if no other appliance is working before the execution of ALC, ESAC may not start. Therefore, it is important to identify the pre-condition of the service chain, explaining when the chain occurs. We denote [cond]S_A ⇒ S_B to represent that a chain S_A ⇒ S_B occurs when a pre-condition cond holds.

Service Chain may cause feature interactions. However, all service chains do not lead to harmful feature interactions. In the chain scenarios described in section D, scenario C1 is considered as harmful one. In the scenario C1, service chain DVD-T-ALC prevents a user from watching a movie in a theater-like atmosphere contained in the requirement of DVD-T. On the other hand, in the chain scenario C2, ESAC makes preset temperature of the air-conditioner lower than a user's requirement in ARH. Although this scenario is also considered as a feature interaction, a user may accept the change of room temperature for 1 degree. Moreover, energy saving, which is one of the requirements in ESAC, is satisfied in the scenario.

The service chain causes various feature interactions which can be serious or acceptable. Then, we propose a method to evaluate the severity of feature interactions.

Now we present an algorithm that can automatically detect the service chains among sensor driven services, using the proposed service description and the environment effect model. Specifically, for a given pair of services S_A = (E_SA, C_SA, A_SA) and S_B = (E_SB, C_SB, A_SB), the algorithm checks if S_A ⇒ S_B occurs. Moreover, if the chain occurs, the algorithm derives a concrete pre-condition cond such that [cond]S_A ⇒ S_B holds. Intuitively, the algorithm checks if the environment effects produced by A_SA may create a situation where E_SB is satisfied, as discussed in Section 3.3. It consists of the following nine steps.

Let v_i be the value of the environment effect e_p(t_i). The semantics of Σ in Step 5 is defined by one of the following S1, S2 or S3, depending on the environment property p interested.

We briefly summarize the purpose of each step of the algorithm. Step 1 finds the key property p by which the service chain S_A ⇒ S_B may occur. Step 2 extracts appliance methods that potentially give an effect to p. Step 3 identifies all state transitions related to the methods within the environment effect models. Step 4 derives all possible combinations of the transitions affecting p. Step 5 calculates the total impact to p produced by each of the combinations. Step 6 examines if the total impact can trigger E_SB or not. Step 7 derives the pre-condition of the service chain. Finally, Step 8 validates if the pre-condition does not contradicts to the enabling condition of S_A.

In our service chain detection method, the conditions under which the potential conflicts may arise are derived from static structures of service models. Since our method does not need to utilize an exhaustive search such as model checking, the state explosion problem does not occur if service complexity increases.

Using the proposed algorithm, we demonstrate to detect the service chain C1 (DVD-T⇒ALC) in Section 1. In this example, we use the service description in Figure 1, and the environment effect model of the appliances in Table 1.

As described in Section 3.4, every service chain does not lead to harmful feature interactions. Then, we define the degree of severity of a service chain, in order to evaluate whether the service chain is harmful. Intuitively, we consider that the service chain is serious, when the state after a service execution differs from the state after a service chain significantly We define a set es = (v₁, v₂, …, v_n) of arbitrary value of environment properties p₁, p₂, …, p_n as an environmental state. When an environmental state es[S_A] at the time of S_A being executed independently and other environmental state of es[S_A ⇒ S_B] at the time of a service chain es[S_A ⇒ S_B] being executed are compared, we estimate that the gap between both environmental states is large.

It is also dependent on the requirement(prior expectation) which a user expects to be satisfied by a service whether the service chain is serious or not. The prior expectation is expressed as a state of appliances and environment properties contained in the main purpose of a service. Table 2 shows examples of prior expectation in each service. In the table, the prior expectation in ARH is related to “indoor temperature”. Similarly, the prior expectation in ESAC is related to “electricity”. Therefore, when evaluating the degree of severity of a service chain, it is necessary to narrow down a state es in the view point of the prior expectation.

We define a projection es = (v₁, v₂, …, v_n) to I = {p_i1, …, p_ik}(a set of environmental properties) as proj_I(es) = (v_i1, …, v_ik). Let I_A be a set of environment properties related to the prior expectation in S_A. Moreover, let es[S_A] be a state at the time of S_A being executed independently, and es[S_A ⇒ S_B] be a state at the time of S_A ⇒ S_B being executed. Here, proj_IA(es[S_A]) can be considered as a prior expectation expected by a user to S_A. Similarly, proj_IA(es[S_A ⇒ S_B]) is regarded as an actual state at the time of S_A ⇒ S_B being executed.

We estimate whether a service chain causes serious feature interaction or not, depending on whether the difference between proj_IA(es[S_A]) which is expected by a user to S_A and proj_IA(es[S_A]) is below a threshold value τ. Here, τ is a given value experientially by a user or the service creator.

We evaluated the degree of severity about the service chain in Section 1. Here, we focused on three properties, such as temperature, brightness and electricity in HNS. Moreover, the threshold of deviation tau is 2 (°C), 500 (lx), and 500 (W), respectively.

Figure 2 shows the architecture of our service chain/feature interaction detection system. Our system consists of a state transition machine service, a service chain detection service, a severity evaluation service and an offline service chain/feature interaction detection controller. The chain detection controller detects service chains and feature interactions by invoking the service chain detection service and the severity evaluation service. Henceforth, the details of each component are explained.

The total lines of code of our program are about 4,300, and the programming language used for development is Java. We use the actual HNS(CS27-HNS) developed by our research group for sensor-driven services. All the services included in the service chain/feature interaction detection system were deployed under the following environments.

We performed the service chain/feature interaction detection for the 7 services in Figure 1. Our system required about 16 seconds for detecting the service chains and the feature interactions.

In a day of winter, as nobody remains the room, ESIA turns off all the appliances. This situation makes the temperature decrease, and ARH is triggered in due course. The service chain violates the goal of energy-saving of ESIA.

This service chain is similar to ESIA⇒ARH. As a user presses the button of LH, all the appliances are shut down. This makes the temperature decrease and has ARH triggered. This service chain is against the user's requirement that all the appliances should be off while leaving home.

As the temperature decreases, ARH is triggered to heat the room using the air-conditioner. This makes room warm enough to trigger ARC to cool the room, which violates the goal of ARH. The algorithm derives a pre-condition that the air-conditioner is OFF or working with the temperature setting 25 °C or less.

If a user presses the button of LH in the night, all the appliances are shut down, and the room becomes dark. Then, ALC is triggered and the light is turned on again. The chain violates the user's requirement that all the appliances should be off while leaving home. The algorithm derives a pre-condition that [200 ≤ env.brightness < 200 + 100* Light.bLevel, the light is ON, and TV is OFF].

For given sensor-driven services, the proposed method can detect all potential service chains and feature interactions automatically. It also derives concrete pre-conditions for every service chain detected. Therefore, the proposed method can make service developers aware of unexpected service chains in advance. Furthermore, we could calculate the degree of severity of each service chain and judge the undesirable feature interactions resulting from the service chain.

In this sense, the proposed method is useful especially for the offline validation at the design stage of the services.

On the other hand, the detected harmful service chain needs to be resolved. However, this paper does not show the concrete resolution method for such service chains. It is necessary to define the suitable resolution method according to the degree of severity of the service chain. A service developer and a user are to determine the magnitude of the deviation experientially. More systematic determination method for the deviation is our future subject.

It is significant problem to determine adequate value of the τ. The value of τ is a criterion which indicates the degree of the severity of detected feature interactions. Accordingly, wrong value of τ does not capture the user's desire. On the other hand, since the value of τ depends on user's requirement, desire, or environment where sensor-driven services are deployed, it is significantly difficult to decide the value statically in advance. Currently, a method to configure the value of τ and resolve feature interactions are both left for our future research. In our next research, we consider about a method to use the value small enough as an initial value of τ. In the approach, feature interactions are detected based on the initial value of τ, and a user decides and conveys whether each feature interaction is acceptable or not. The recursive feedback process between the user and our system make the value of τ configured gradually.

Kolberg et al. [7] presented a classification of feature interactions in smart home, where our service chains can be categorized as the sequential action interaction (SAI). However, the concrete detection method of the service chains was not described. Wilson et al. [8] took the environment effects of the appliances for detecting feature interactions. However, since the amount of the effects was not explicitly considered, it would be difficult to derive detailed pre-conditions of the service chains. The ECA rules have been often used for detecting policy conflicts [6,9,10]. These methods basically focused on action conflicts only, and the service chains were not explicitly considered. In [11], we proposed a service-oriented framework that facilitates development of individual sensor-driven services. However, this method did not cover interactions among multiple services.

In distributed system, many techniques for detecting policy conflict based on policies such as Authorization Policy and Obligation policy have been proposed. Lupu et al. [12] have classified policy conflicts occurring in distributed systems and proposed conflict resolution method according to the classification. Dunlop et al. [13] have proposed dynamic and scalable policy conflict detection method. In the method, conflict DB stores the combination of the policies which may cause conflicts.

In the viewpoint of conflict detection, these researches differ from our proposed method detecting conflicts based on the service chain using the HNS component model. On the other hand, it is significant to apply the dynamic and scalable conflict detection method to our detection technique.

Charalambides et al. [14] have proposed conflict analysis using Event Calculus in the domain of QoS management. In the analysis method, they used abductive reasoning to detect the potential conflicts. Furthermore, they have identified a number of potential conflicts, and have classified them. In the classification, the redundancy conflict and the mutual exclusion conflict can be considered as some kinds of feature interactions in HNS [4] However, in this paper, we proposed FI detection method based on the service chain which differs from conventional FIs such as redundancy and mutual exclusion.

Shankar et al. [15] have proposed a method to detect conflicts and cycles in policies based on their rule framework “Event-Condition-Precondition-Action-Postcondition” in pervasive systems. Their conflict detection method using the rule framework ECPAP resembles our proposed method. However, since they assume that the framework is used in general-purpose pervasive systems, the subjects peculiar to the sensor-driven services in HNS have not necessarily been solved. We have proposed our framework which takes multiple different kinds of environment properties into account. Furthermore, our framework provides the concrete conditions under which each potential conflict may arise and estimation of severity of the conflicts quantitatively.