IIHM Lénaïc Terrier

CCBL: a Language for Better Supporting Context Centered Programming in the Smart Home

Keywords: • Computer systems organization → Human-centered computing → Human computer interaction (HCI) → Ubiquitous and mobile computing systems End User Development, Smart homes, Home automation, CCBL, ECA, Context, programming language, experimentation

This paper presents CCBL (Cascading Contexts Based Language), an end-user programming language dedicated to Smart Home. We design CCBL to avoid the problems encountered by end-users programming with ECA (Event Conditions Actions), which is the dominant approach in the domain. We present the results of an experiment where we asked 21 adults (11 experimented programmers and 10 non-programmers) to express four increasingly complex behaviors using both CCBL and ECA. We show that significantly less errors were made using CCBL than using ECA. From this experiment, we also propose some categorization and explanation of the errors made when using ECA and explain why users avoid these errors when programming with CCBL.

CCS Concepts:

INTRODUCTION

Smart Home is becoming a reality [START_REF] Bernheim Brush | Home automation in the wild: challenges and opportunities[END_REF][START_REF] Demeure | Building and Using Home Automation Systems: A Field Study[END_REF][START_REF] Mennicken | From today's augmented houses to tomorrow's smart homes: new directions for home automation research[END_REF]; with the raise of the Internet of Things (IoT), a plethora of communicant and programmable devices is being integrated into homes (e.g., smartphones, vacuum cleaner, controllable lamps, and programmable buttons). In addition, platforms such as IFTTT (https://ifttt.com/) are making available to end-users many online services that can be integrated into the home (e.g., music, news, or even smart device controls).

Smart Home is not just about controlling devices and services in isolation one from each other's, it is also the possibility to program them so that they work together to fulfill inhabitants' needs. This can be done via dedicated home automation systems [START_REF] Bernheim Brush | Home automation in the wild: challenges and opportunities[END_REF][START_REF] Demeure | Building and Using Home Automation Systems: A Field Study[END_REF] that act as bridges for the different devices and services, or via online services such as IFTTT. In any case, the programming language that is proposed is a variant of Event Condition Action (ECA), sometimes also called Trigger Action programming (TAP). ECA offers a low threshold: it is easy for novice users to get started with, simple behaviors are easy to program (e.g., when I press the button, send a notification to my friend). While there is evidence that average users can successfully engage in programming with ECA [START_REF] Ur | Practical trigger-action programming in the smart home[END_REF], it has been demonstrated that users may form a wrong mental model when confronted with rules of the form "if condition then sustained action" (e.g., when I am in the room then turn on the lights) [START_REF] Huang | Supporting mental model accuracy in trigger-action programming[END_REF]. With such rules, many users tend to apply a non-sequitur reasoning: they think that if the condition becomes false, then the sustained action is reversed (e.g., when I am not in the room, then lights are turned off).

In this paper, we elaborate on these observations by Huang et al. [START_REF] Huang | Supporting mental model accuracy in trigger-action programming[END_REF]. We consider smart home behaviors that associate device states (e.g., the lights are on) to contexts (e.g., I am in the room). We consider behaviors of increasing complexity in terms of the number of contexts involved as well as the number of transitions between them. For instance, let us consider "the volume of the music" as a device and the three following contexts: "Being outside home", "Being at home" and "Being at phone". Then a "complex" behavior could be "User want the volume of the music to be normal when she is at home, except when she is at phone (smartphone), In that later case, she wants the volume to be low. When she isn't at home, she wants the volume to be off."

We introduce CCBL [START_REF] Terrier | CCBL: A new language for End User Development in the Smart Homes. 6 pages short paper to appear in IS-EUD 2017[END_REF] (Cascading Context Based Language), a language dedicated to programming Smart Homes. CCBL focus on the notion of context rather than events as it is for ECA. We hypothesize that, with respect to ECA, CCBL lower the design barrier [START_REF] Ko | Six Learning Barriers in End-User Programming Systems[END_REF] for end-users to program correctly complex behaviors. We also hypothesize that users programming with ECA 1) will make errors due to confusion between conditions and event parts of rules and 2) will miss to express some transitions from one context to another.

In order to test our hypothesis, we set up an experimentation involving 21 participants (11 programmers and 10 non-programmers) who had to program four behaviors of increasing complexity. We compare two languages: ECA and CCBL to express aforementioned behaviors. We measure the errors made by users and categorize them to get clues on how participant structure their programs.

We now present background and related works. We then introduce CCBL and describe its cascade mechanism. In order to compare CCBL with ECA, we describe a user study where participants had to solve exercises of increasing complexity by using both CCBL and ECA. We present the results of this study and discuss the ways participant programmed in ECA and CCBL before concluding.

BACKGROUND AND RELATED WORKS

Our work is related to end-user programming in the Smart Home [START_REF] Davidoff | Principles of smart home control[END_REF]. Menniken et al. [START_REF] Mennicken | From today's augmented houses to tomorrow's smart homes: new directions for home automation research[END_REF] give an overview of the challenges in the domain. In this section, we first present the existing variants of ECA programming before providing an overview of related work.

Event Conditions Actions (ECA) and Triggers-Actions programming (TAP)

ECA programming consists of defining a set of rules. ECA programming languages are actually derived from practice; there is no unique formal definition that we can refer to. An ECA rule is as follows: ON event occurs IF conditions are satisfied THEN do some actions.

In this paper, we will use the definition proposed by Pane et al. [START_REF] Paschke | ECA-RuleML: An Approach combining ECA Rules with temporal interval-based KR Event/Action Logics and Transactional Update Logics[END_REF]. He states that ECA programming consists of specifying a set of rules where each of them "autonomously reacts to actively or passively detected simple or complex events by evaluating a condition or a set of conditions and by executing a reaction whenever the event happened and the condition is true". This means that [START_REF] Cano | Coordination of ECA rules by verification and control[END_REF]:  A rule is activated only by events;  Its execution is independent of other rules in the system;  It implements a reaction to the incoming event;  It contains a guarding condition to execute such actions.

Trigger-action programming (TAP) is a variant of ECA. Recent works [START_REF] Huang | Supporting mental model accuracy in trigger-action programming[END_REF][START_REF] Ur | Practical trigger-action programming in the smart home[END_REF] used this term although authors do no explain in which way it differs from ECA. Häkkilä et al. [START_REF] Häkkilä | Interaction and end-user programming with a context-aware mobile application[END_REF] seems to be the first to refer to it. While Dey et al. [START_REF] Anind | iCAP: interactive prototyping of context-aware applications[END_REF] do not use the term (they write about if-then rules), they propose a very similar behavior and are cited by Ur et al. [START_REF] Ur | Practical trigger-action programming in the smart home[END_REF] as an example of system that support trigger-action programming.

While none of the authors of aforementioned works do provide formal definition of trigger-action programming, we propose the following one, inspired by Häkkilä et al. [START_REF] Häkkilä | Interaction and end-user programming with a context-aware mobile application[END_REF]: Trigger action is a variant of ECA, where it is possible to express rules of the form "IF conditions THEN actions", where conditions do not make any reference to an event. The semantics of this form of rule, expressed in standard ECA, is "ON conditions become true THEN do actions".

Related works

Pane et al. [START_REF] Pane | Studying the language and structure in non-programmers' solutions to programming problems[END_REF] study how non-programmers express solutions to programming problems and find that event based programming style is the most common way to be used. In the domain of context-aware application, Dey et al. [START_REF] Anind | iCAP: interactive prototyping of context-aware applications[END_REF] show that users tend to express themselves in terms of rules (if…then…) when having to describe context aware application. This is confirmed by Ur et al. [START_REF] Ur | Practical trigger-action programming in the smart home[END_REF] who asked 318 workers on Amazon's Mechanical Turk to list five things they would want a smart home to do. They found that 62.6% of the collected behaviors were about programming. All the programs could be expressed using a TAP structure.

García-Herranz et al. [START_REF] García-Herranz | Towards a ubiquitous end-user programming system for smart spaces[END_REF] show that both programmers and non-programmers are able to code behavior for a smart home by using triggers, conditions and actions. They also show that both programmers and nonprogrammers can make the difference between triggers and conditions. However, this later result is challenged by the results we obtain in this paper. We found that non-programmers do not really perceive a difference of usage between events and conditions when programming with ECA.

Huang et al. [START_REF] Huang | Supporting mental model accuracy in trigger-action programming[END_REF] distinguish between the different types of triggers and actions. A triggers can refer to an event or a state while an action can be instantaneous (e.g., send an email), extended (e.g., brew coffee) or sustained (e.g., turn on lights). Based on that categorization, they observe that many users tend to do non-sequitur reasoning as rules of the form "When state then do sustained action" are automatically associated with the rule "When not state then do reverse sustained action". For instance, the rule "When I am at home, then lights are on" is interpreted as implying that "When I am not at home, then lights are off". We designed CCBL to take explicitly into account non-sequitur reasoning.

Chandrakana et al. [START_REF] Nandi | Automatic Trigger Generation for Rule-based Smart Homes[END_REF] considers 96 home automation rules written by end-users for the openHAB framework.

OpenHAB is an open-source framework that is popular among Do-It-Yourselfers home automation builders. In openHAB, a rule is composed of 1) a trigger part that enumerate all the events that may trigger the rule, and 2) an action part that contains imperative code with possible use of classical workflow instructions such as if-then-else. The authors show that 77 of the 96 rules (80%) had a trigger part that contains less events that necessary. This means that it is difficult for users to enumerate all the necessary events that are relevant to trigger a rule.

While aforementioned works study rules quite in isolation from each other, Cano et al. [START_REF] Cano | Coordination of ECA rules by verification and control[END_REF] study the coordination problems in ECA rules. They propose three categories for them: 1) Redundancy, when two rules will at least partially do the same actions when an event occurs; 2) Inconsistency when two or more rules send contradictory actions to a same device; and 3) Circularity when rules get activated continuously, without reaching a stable state. We deigned CCBL so that inconsistencies are impossible to express and circularities easy to detect.

CCBL

We conceived CCBL [START_REF] Terrier | CCBL: A new language for End User Development in the Smart Homes. 6 pages short paper to appear in IS-EUD 2017[END_REF] based on our experience with ECA. Our design rational is based on the notion of context instead of event as in ECA. The assumption is that contexts ordered by hierarchy and priority can support nonsequitur and general/particular case reasoning. Figure 1 illustrates a program composed of several contexts.

In CCBL, there are two types of contexts: Event Context and State Context. Event contexts are composed of an event expression and a set of actions. They are semantically close to ECA rule: if the event context is active, the trigger of its event leads to the execution of its set of actions. There is no duration associated to event contexts. respect to ECA. They provide the building blocks to structure contexts hierarchically. A State context is composed of three parts:  A Boolean expression and optionally a start and/or an end event: The context is active either after the system detects the start event (if it is specified) or the sys-tem evaluate the Boolean expression as true (if there is no start event that is spec-ified). The context stays active until either the system detects the end event (if it is specified) or the system evaluate the Boolean expression as false (in any case). For instance, the starting event could be "System detects that Martin enters his home", the Boolean expression could be "System detects that Martin is at phone".  A set of actions that change the state of devices or services when the context is active (e.g., "Set volume of the music to off and set lamp A to off").  A list of sub-contexts. Sub-contexts can be Event Contexts or State Contexts. Each sub-context can only be active if the parent context is active. For instance, one can consider the sub-context "System detects that Martin is at phone" that apply only when the context "System detects that Martin is at home" is active.

By construction, CCBL imposes to have one root state context, this state root context aims to represent the "neutral state" of the smart Home (e.g., lights are off; doors are locked). Several contexts may set the state of a device but only one has access to the device at a time to prevent inconsistencies. Unlike what happens with ECA, it is not the last who speaks who get the access. In CCBL, contexts are ordered in a contexts priority list. When several contexts try to modify a device, only the one that has the maximum index in the priority list can actually do it. If this context become inactive, then the next context in the priority list sets the state of the device. The same process happens when a new context that tries to set the device become active. The order function used in CCBL is as follow, C1 > C2 means that:

 Either C1 is a descendant context of C2.
 Or C1 and C2 have the same parent context; C1 is indexed after C2 in the list of sub-contexts.  Or C1 has an ancestor A1 and C2 have an ancestor A2 such as A1 and A2 have the same parent context, A1 is indexed after A2 in the list of sub-contexts.

Every context specifies either explicitly or implicitly the state of all devices and services. The implicit specification of the state of devices and services is what we call the cascade mechanism. We took the inspiration form the Cascading Style Sheet (CSS) language [START_REF] Wium | Cascading Style Sheets[END_REF] that enables styling of HTML documents. To illustrate the cascade mechanism, let us consider the CCBL program illustrated in Figure 1, if we suppose that Martin is at home and that he is at phone, then two contexts try to set the state of the lamp: the root context and the one that has the Boolean condition "System detects that Martin is at home"). The lamp lights in white because "System detects that Martin is at home" is a descendant context of the root context. If Martin leaves home while still at phone, the lamp will be set to off, as the only remaining context that try to set it will be the root context.

We designed the cascade mechanism to make it easy for users to express what happens when the system exits a context. Indeed, the devices can never be in an undefined state, at least the default root context defines what their state is. Consequently, users only have to specify contexts for which at least one device state has to be changed.

EXPRESSIVE POWER OF CCBL

We believe that CCBL has the same expressive power as ECA. An ECA rule can be translated into a state context having C for condition and an event sub-context having E for condition and A for actions. The way CCBL handles a context having an event for condition is different from a condition based on a state: When the event E occurs, actions A are performed. The new devices states resulting from actions A are maintained until another context modifies them.

In this paper, we focus on the strength of CCBL over ECA: in other words the handling of state-based contexts. We illustrate CCBL and in particular its conciseness with respect to ECA through the following example: Ensuring that the security context has priority over others.

Let us suppose that the security is achieved by ensuring that the electrical outlet of the PC running the security system is always on. With CCBL, the users can achieve this by adding the security context (When security is active then Power outlet is ON) as the last child of the root context. Indeed, as the security context is the last child of the root context, this ensures by construction that the security context has the highest level of priority. The priority list therefore ensures that if the security context is active, then no others contexts will have access to the power outlet. Now let us consider exactly the same example with ECA: 1) the users should first specify the rule for entering the security context, second 2) the users should find every other rules that modify the power outlet in order to prevent modification when security context is active. Third, the users have also to consider the point 2 when reprogramming the system. Each time a new rule is added or updated, the users should remember to check if this rule modifies the power outlet and act accordingly.

Last, let us now suppose users want to enrich the security context behavior as following: "When nobody is at home, then the door is locked". Programming with CCBL, the users can add a "When nobody is at home" subcontext to the security context. The cascade mechanism and priority list ensure that when this sub-context ends, the system opens or closes the door lock with respect to what others active contexts specify. Programming with ECA, the users must add two rules: R1) for specifying what the system should do when the context becomes true (i.e. "When security context becomes active, then turns on the power outlet of the PC"), and R2) for specifying what the system should do when the context becomes false. Concerning this last point, the users have to analyze all others rules to know if the system should open or close the door lock. Moreover, when users add or update another rule of the system, they have to take care to update rule R2.

EXPERIMENT

We evaluated the use of two programming languages: ECA and CCBL. These languages were used to program Smart Home behaviors that associate device states to contexts. We compare correctness of programs edited with both languages. We also categorize errors made with ECA and try to understand their causes.

The 21 participants are French adults, aged between 18 and 51 (average: 31,5y-o standard deviation: 9,7y). None of them has a smart home system, 11 participants are programmers (engineer level) and 10 have no programming knowledge (they follow or followed studies after high school). As illustrated in Table 1. , participants were split into four groups according to their programming knowledge and the order in which they used languages during the evaluation (ECA and CCBL).

Evaluation method

Each evaluation session lasts nearly one hour. The participant and the evaluator are alone during the whole session time. It takes place either in the laboratory room or at the participant's home. The participant is placed in front of a computer, sits at a desk. The evaluator first briefly exposes the objective of the study, he presents the smart home that will be considered for the rest of the session and explains what the sensors and actuators are. A presentation of the language was read at the beginning of the programming session. The presentation includes the core principles of each language and how the editor represents them (e.g., cascade for CCBL, event for ECA). The presenter illustrates these principles with the following example: "Martin wants lamps A to be lit in orange when he is at work, the lamp should be off otherwise.

The participant then programs a list of behaviors using CCBL and ECA. We implemented a software to support our experimentation (Figure 2). The software guides the evaluator and the participant through the experimentation process. It enables participants to edit programs and logs their actions into a database. At the beginning of the programming session, the evaluator lets the participant pick the interface for the first programming language (either ECA or CCBL) and answers questions. The evaluator asks the participant to program the following behavior: "Martin wants the lamp to be orange when he is phoning at work and green when he is phoning at home". The evaluator ensures that the participant understood the elements of the language by asking some questions (e.g., when is the lamp going to turn off?). The evaluator takes care that:  For ECA: Participant understands that only an event can trigger a rule and that once an actuator is set, its state remains constant until the triggering of a rule sets it to a new value.  For CCBL: Participant understands the concept of cascade and the nesting of contexts.

Participant has then to complete four exercises. The same process is repeated for the other programming language (pick up time and the 4 same exercises). At the end of the programming session, the evaluator asks the participant which language she prefers and why.

5.1.1 The prototype. The user interface of the prototype is illustrated in Fig. 1. A header indicates who the current participant is; what the current step of the process is and it enables evaluator to go to the next step. The panel on the left lists the two sensors and two sensors/actuators of the smart home:  Alice sensor: It detects if Alice is at home, at Martin's home and if she is available. Her availability is independent of her location.  Martin sensor: It detects if Martin is at home, at work, if he is phoning and if he sits in his sofa at home.  Volume of the music: It sets the volume to off, low, normal or high. It can also be used as a sensor that indicates the state of the volume of the music.  Lamp A: It sets the lamp to off, orange, green or white. It can also be used to indicate the lamp's state.

For each of them, the user interface lists related events (for ECA rules) conditions and actions (for both ECA and CCBL). The central part presents the program under edition. The footer part represent the exercise statements. As there is no standard way to represent ECA rules. We chose a representation that was consistent in terms of colors with the representation of CCBL programs. Figure 3 illustrates an ECA rule. Each rule must have one and only one event. It can have zero or several conditions and zero or several actions.

Exercises.

The four exercises consist of associating values of the state of one device -either the color of the lamp or the volume of the music -to different contexts. We defined the four exercises to represent increasing levels of complexity. The complexity refers to the number of contexts taken into account as well as the number of possible transitions to switch from one context to another. Table 2 summarizes the exercise statements presented to participants (translated from French). Exercise 1 is the simplest one (Table 2 Ex 1). The objective is to test whether the participant really understand the fundamentals of each language. We want to check that participants do not use non-sequitur reasoning when programming with ECA and that they use the cascade mechanism when programming with CCBL.

Exercise 2 (Table 2 Ex 2) uses three contexts: "Outside", "At home" and "On sofa". The latter is a sub-context of "At home". We want to test if users are able to express general case ("Being at Home") and particular case ("Being on sofa"). This exercise is close to the exercise 1.

Exercise 3 (Table 2 Ex 3) also contains three contexts: "Outside", "At home and at phone", "At home and not at phone". Figure 4 illustrates the HFSM (Hierarchical Finite State Machine) that presents the behavior of the volume of the music. A minimum of five ECA rules are needed to program the behavior. Indeed, when Martin enters his home, he can be at phone or not. Fig. 3. An example of ECA rule. The header part represent the event that will trigger the rule. The middle part represents a set of conditions that must be fulfilled in order to execute the action (lower part of the rule).

Fig. 4. HFSM of exercise 3. Three contexts are considered. When Martin enters home, the system distinguish if user is talking at phone or not.

Exercise 4 (Table 2 Ex 4) is the most complex one. It contains five contexts and programming its behavior necessitates a minimum of eleven ECA rules. We test if users identify all the triggers that may change the color of the lamp. We also test if users identify all the situations where the lamp must be turned off. Ex 2 Martin wants the volume of the music to be low when he is at home, except when he sits in his sofa. In that later case, he wants the volume to be normal. When he isn't at home, he wants the volume to be off.

Ex 3

Martin wants the volume of the music to be normal when he is at home, except when he is talking at phone (smartphone), In that later case, he wants the volume to be low. When he is not at home, he wants the volume to be off.

Ex 4

Martin wants to use his lamp to be aware of Alice when he is at home. When Alice is at home and not available, he wants the lamp to be lighted in orange. When she is at home and available, he wants the lamp to be lighted in green. When Martin receives Alice, he wants the lamp to be lighted in white. In all other cases, the lamp should be off.

Collected data

We collected edited programs, SUS questionnaires and evaluator's notes. Edited programs are used to analyze the correctness: Do the program express correctly the expected behavior? We also analyze the structure of the program (e.g., does it contain a condition?) as well as the eventual errors. As few individuals compose each group, we analyze variance by computing p-value with a Fisher's exact test.

We collected one program per participant per exercise per language (21 x 4 x 2 = 168 programs). Table 3 summarizes the number of incorrect programs specified by participants for each exercise. Participants are classified with respect to their group (see Table 1). After the use of each language, we asked participants to fill a SUS-based questionnaire. At the end of the evaluation session, the evaluator asked participants which language they prefer and why.

EXPERIMENTATION RESULTS

First, we show that participants do not always respect the ECA semantics and tend to express rules with a TAP semantics. Second, we show that even when taking into account TAP semantics, participants make fewer errors when programming with CCBL than with ECA. Third, we analyze the errors made by participant when using ECA and ECA with TAP semantics. Finally, we analyze the structures of CCBL programs and discuss the users' point of view.

From ECA to TAP semantic

We identified two programmers and two non-programmers who expressed at least one ECA rule in which they added a redundant condition that can only be true when the system triggers the event. For instance, we observed the following rule: "When Martin enters home and if Martin is at home then set the volume of the music to low". For theses participants the semantics difference between an event and a condition is not clear. These participants belong to groups G2 and G4 (see Table 1). They used ECA before CCBL, thus CCBL cannot have influence their mental model. Several participants said during the sessions that they had problems to distinguish between events and conditions when programming with ECA. Sometimes, when reading the ECA programs, they transformed the event into a condition. For instance, "Martin enters his home" was pronounced "Martin is at home".

As stated before, an ECA rule is triggered by one event. When the event occurs, then conditions are evaluated. If conditions are evaluated as true, then actions are executed. However, we cannot understand several of the proposed ECA programs when using this semantics. Instead, we observe that participant blurred the distinction between event and condition. Participant considered the event as a condition. They used the following semantic: "If the conditions become true, then execute the actions". This is actually the semantics used in TAP.

Figure 6 illustrates this shift from ECA semantics to TAP semantics. It is a solution to exercise 3 proposed by a non-programmer. If we interpret this program with the ECA semantics, then it does not describe the behavior stated in Table 2 Ex 3. However, if we replace the events by their related states (e.g., "System detects that Martin starts speaking at phone" becomes "Systems detects that Martin is speaking at phone") and if we use TAP semantics, then the behavior is correct. Fig. 6. Example of program where participant semantically blurs the distinction between events and conditions.

Related works

We analyze ECA programs edited by participants to check whether they used ECA or TAP semantics. We interpreted each program using both semantics and retained the semantics that made more sense with respect to the behavior that we asked participant to program. Table 4 summarizes the semantics (TAP or ECA) used by participants for each exercise. In some case, we were not able to determine which semantics was in use, which explain why the sum of ECA and TAP semantics may be inferior to the number of participants in the group. The use of one or the other semantics (ECA or TAP) varies from one group of participants to another and according to the exercise. This variation is related to programming knowledge of participant at least for exercise 3 (p-value <0.002). Non-programmers use ECA or TAP semantics according to the exercises (p-value <0.007). This may be due to the increasing complexity of exercises or to the fact that participants tend to forget ECA semantics with time. However, with respect to data, we have no conclusive answer about how programmers use ECA or TAP semantics. We observe that they are more likely to keep using ECA semantics than non-programmers are.

Comparing CCBL and ECA (including TAP semantics)

Figure 7 summarizes the correctness of the programs specified by participants per exercise, language and programming knowledge. It takes into account that an ECA program can be correct either with the ECA semantics or with the TAP semantics. Non-programmers who correctly programmed exercises 3 and 4 used the TAP semantics, which suggest that this semantics better support users in programming behaviors that associate devices states to contexts. When programming with ECA, the results are consistent with the level of difficulty: participants made more errors when exercises become more difficult. When programming with CCBL, only two non-programmers made an error for exercise 4. For the exercises 1, 2 and 3, every programmers edited a correct CCBL program.

We analyze the errors made by participants and summarized in Table 3. We first test three possible factors of error: a) the order in which languages have been used (ECA then CCBL or CCBL then ECA), b) the programming knowledge of participants (programmers or non-programmers) and c) the language used for programming (ECA or CCBL). For each exercise, we compute the p-value (using Fisher's exact test) between the correctness of the programs and each of the three aforementioned factors of error (Table 5). The results do not allow us to conclude on factors a and b but do show that the correctness of programs is related to the language used for exercises 2, 3 and 4 (factor c). To conclude, participants make significantly fewer errors when programming with CCBL than with ECA (using ECA or TAP semantics).

Errors made by using ECA

From related work [START_REF] Cano | Coordination of ECA rules by verification and control[END_REF][START_REF] Huang | Supporting mental model accuracy in trigger-action programming[END_REF][START_REF] Nandi | Automatic Trigger Generation for Rule-based Smart Homes[END_REF], we know that several types of errors exists when programming with ECA: non sequitur reasoning, using less triggers that necessary, redundancy, inconsistency and circularity. We observe no errors of inconsistency nor circularity. We observe only one error of redundancy (by a programmer in exercise 4).

As the most complex exercise necessitates eleven rules to behave correctly, we postulate that this is not sufficient to produce this kind of errors. Despite the fact that the evaluator tried to ensure that participants understood ECA semantics well before starting exercises, we observe that two non-programmers used non-sequitur reasoning for exercise 1. This suggest that this is a very natural way of reasoning. We observed other cases of non sequitur reasoning in exercise 2: participant specified what to do when Martin sits down on the sofa but forgot to mention what to do when he leaves the sofa. We observed similar errors in exercise 3: participants tend to forget to specify what to do when Martin hangs up the phone.

Many errors implied the use of less triggers than needed. This was especially the case for exercise 3 and 4. For instance, in exercise 4, the lamp lights in green when Martin is at home and Alice is at her home and available. This imply considering three events: "Martin enters home", "Alice enters her home" and "Alice becomes available". Most participants forgot about at least one of these events, which is consistent with what Chandrakana observed [START_REF] Nandi | Automatic Trigger Generation for Rule-based Smart Homes[END_REF].

Errors made by using ECA with TAP semantics

We observe two types of errors when programming with TAP: 1) Reasoning in terms of general and particular cases and 2) Forgetting to specify what happens when contexts are exited, which can be related to non-sequitur reasoning. Figure 8 illustrates a participant using TAP semantics. Remember that every event has to be replaced with its related state in order to be interpreted correctly. The participant expresses a general case (Martin is at home) and associates it with the volume being "normal". He then expresses a particular case (Martin is at home AND he is at phone) and associates it with the volume being "low". However, this program is incorrect. Indeed, when Martin hangs up the phone, if he is still at home, no rule will trigger so the volume will stay "low" instead of being set to "normal". We observe this error for 5/9 non-programmers that used TAP semantics for exercise 3 (three programmed it correctly and one made another error). Programmers were less likely to use TAP semantics, only two of them did it for exercise 3, and one of them made the same error (the other programmed it correctly). The other type of errors consists of forgetting to specify what happens when contexts are exited. We observe this type of error mainly for exercise 4. As illustrated in Figure 9, participants were able to specify (with TAP semantics) when the lamp should light in orange, green or white. Every participant also mentioned to turn it off "when Martin was not at home" (It was explicitly stated in the exercise) but forgot to mention that it was also the case when Alice was not at her home nor at Martin's home. There are two possible explanations for this type of error: 1) Participants applied non-sequitur reasoning or 2) Participants were not aware of all possible contexts (e.g., "Alice is not at her home nor at Martin's home). is not at her home not at Martin's home).

Analysis of CCBL programs

The experimental results suggest that CCBL provides a threshold as low as that of ECA for simple problems. There was no significant difference observed between programming with ECA and with CCBL. This suggests that the CCBL cascade mechanism and the notion of sub-context do not introduce difficulties for the user that could lead to a higher threshold than for ECA.

Only two non-programmers made an error when using CCBL. Both did it at exercise 4. The first one forgot to mention that Martin had to be at home to light the lamp in orange, green or white. The second non-programmer expressed a very different behavior than what we asked him to do. We suspect that he was tired of the exercises and wanted to finish as soon as possible (it was his last exercise and he answered very quickly to the ending questions).

We analyze the structure of CCBL programs proposed by participant with respect to the errors made when they used ECA (with or without the TAP semantics). A source of errors when programming with ECA is non-sequitur reasoning, that is to say that user expect the system to do some reverse action when a context ends. In CCBL, there is always an active context, and the set of active contexts specifies the state of all devices. Consequently, users can always know what would be the state of a device when a context ends. Indeed, participants said that they preferred CCBL because "it is not necessary to think about reverse actions as it is with ECA".

For exercise 4, 8/11 programmer and 4/10 non-programmers did use the nesting of context to specify the default case (Figure 13-A). Some of them had an unnecessary context as children of the root context, "Martin is not at home", and associated it with "Set lamp A to off". This was done by 2/11 programmers and 3/10 nonprogrammers. At the end of the session, when we asked why they added this context, participants provided two explanations: 1) they forgot about the root context and 2) They added this "just to be sure" and because the instructions explicitly stated that when Martin was not at home then the lamp should be off.

Another source of error when programming with ECA and the TAP semantics was the use of general case / particular case reasoning. Participant who made the error illustrated in Figure 8 adopted the same mode of reasoning when programming in CCBL. Figure 10 illustrates how it can be coded using CCBL. This solution was proposed by 6/11 programmers and 5/10 programmers. Other participants add an additional unnecessary context "Martin is not at home" (4/AA programmers and 4/10 non-programmers) for the same reason that mentioned before. Last, one programmer and one non-programmers implemented the behavior with a decision tree (see Figure 11), which is a valid solution despite it does not use the cascade mechanism.

Users' point of view

The software used for the experiment was instrumented to measure the editing time. Participants were faster using CCBL than ECA (average time in seconds for CCBL/ECA: ex 1: 81/142, ex 2: 105/174, ex 3: 46/209, ex 4: 240/494). CCBL was preferred by all programmers and 7/10 non-programmers. It seems that CCBL better fit the way of reasoning for the problems we tested. Participants stated: "CCBL is better because you do not have to care about counter-order", "Having a default case is much more simpler, I just have to concentrate on the case where it has to be changed", "CCBL give me the impression that it is going to take care of more things without I have to think about it. With ECA I always fear to miss something". Participants also appreciated CCBL for being able to provide a good overview of the behavior: "with CCBL, things are better classified, with ECA all is at the same level so it is difficult to get an overview"; "with CCBL you see which conditions are more fundamental, such as Martin being at home. You don't have to repeat yourself as with ECA".

Participants perceived CCBL to be a higher level programming language than ECA. One programmer said, "It is like comparing languages with and without garbage collector, there are things you just do not want to bother with". One other mentioned that he "needed to concentrate much more when programming with ECA. You have to be really methodic if you don't want to forget a case".

Three non-programmers preferred programming with ECA because "it is more linear, more sequential, you get one sentence after each other's", "CCBL programs are harder to read because of the nested boxes, especially when programming exercise 4". This claims for a redesign of the user interface. However, in spite of this comments, these three participants succeeded in programming correctly the four exercises using CCBL and failed to program exercises 3 and 4 with ECA. One possible explanation is that they had a false impression of easiness of ECA; they did not perceive the difficulties of the behaviors to program.

LIMITS OF THE STUDY

Our evaluation is a first step on testing CCBL. Indeed, we tested only a category of programs: those centered on states. We need to conduct further user studies to evaluate how CCBL could support other categories of programs (e.g., more centered on events) with respect to ECA. Related to that point, we cannot not draw conclusions on comparing CCBL and TAP, although the results may suggest an advantage for CCBL. This requires further confirmation by conducting a comparative study of CCBL and TAP.

The exercises are realistic of home programming but we formulated them in a way that favors a state-based solution. We chose to do so because we targeted state-based programs in this user study. This could explain why users tended to interpret ECA rules with the TAP semantics (thus confounding events and states). This may have an impact on their performances. We envision a complementary user study with more neutral or balanced formulations (e.g., favoring either state-based or event-based solutions).

Finally, participants could not evaluate the correctness of their programs (except for the syntax). The number of incorrect ECA programs should decrease with the capacity of correcting the programs, although testing a program may also be a difficult task for participants. As a result, this user study is dedicated to the very first steps

  L. Terrier et al. PACMHCI / EICS'17 Paper, Vol. 1, No. 1, Article 13. Publication date: May 2017.

Fig. 1 .

 1 Fig. 1. Example of CCBL program. The lamp A is lighted in white when Martin is at phone at home and in orange if he is at phone at work. It is turned off otherwise.

Fig. 1 .

 1 Fig. 1. User interface of the software that support the experimentation process (ECA rules editor).

Fig. 2 .

 2 Fig. 2. HFSM of lamp behavior for exercise 4.

  • L. Terrier et al. PACMHCI / EICS'17 Paper, Vol. 1, No. 1, Article 13. Publication date: May 2017.

Fig. 7 .

 7 Fig. 7. Correctness of programs. We use ECA and TAP semantics to evaluate correctness of ECA programs.

Fig. 8 .

 8 Fig. 8. Example of reasoning in terms of general case (rule at the top) and particular case (rule in the middle).

Fig. 9 .

 9 Fig. 9. Example of program where participant missed to express correctly when to turns light off (Miss the case when Alice is not at her home not at Martin's home).

Fig. 10 .

 10 Fig. 10. Solution to exercise 3 with CCBL a general case / particular case strategy. The priority list mechanism ensures that only the most nested active sub-context can set the music volume.

Fig. 13 .

 13 Fig.[START_REF] Pane | Studying the language and structure in non-programmers' solutions to programming problems[END_REF]. Solutions to exercise 4 with CCBL. Contexts with grey background specify the color of the lamp. MH stands for "Martin is at home". AH stands for "Alice is at home". AM stands for "Alice is at Martin's home". AA stands for "Alice is available". Strategy α rely on general/particular case. Strategy β is close to TAP. Strategy γ implements on a decision tree.

  13:6 • L. Terrier et al. PACMHCI / EICS'17 Paper, Vol. 1, No. 1, Article 13. Publication date: May 2017.

Table 1 .

 1 Groups of participants

	Order	Non-programmer	Programmer
	CCBL then ECA	G1: 3 males, 2 females	G3: 4 males, 1 female
	ECA then CCBL	G2: 1 male, 4 females	G4: 6 males

Table 2 .

 2 Statements of the four exercises (originals in French)

	Exercice	Statement
	Ex 1

Martin wants the lamp to be lighted in white if and only if he is at home (lamp is off otherwise).

Table 3 .

 3 Number of incorrect programs edited with ECA and CCBL.

	Group	Total	Ex 1	Ex 2	Ex 3	Ex 4
		#	ECA	CCBL ECA	CCBL ECA	CCBL ECA	CCBL

Table 4 .

 4 Semantics used by participants for each exercise

			Ex 1		Ex 2		Ex 3		Ex 4
	Group Total	TAP ECA TAP ECA TAP ECA TAP ECA
	G1	5	0	5	3	2	4	1	4	0
	G2	5	1	2	4	0	4	0	4	1
	G3	5	0	5	1	4	1	4	3	1
	G4	6	0	5	2	3	1	4	3	3

Table 5 .

 5 P-value for links of correctness with Order, Knowledge and Language.

		Ex 1	Ex 2	Ex 3	Ex 4
	Order	0.63	0.84	1	0.96
	Knowledge	0.5	0.67	1	1
	Language	0.55	0.03	6.16E-6	1.55E-7

PACMHCI / EICS'17 Paper, Vol. 1, No. 1, Article 13. Publication date: May 2017.

CCBL is quite tolerant in the ways users can structure programs. Figure 13 schematizes the three different types of correct solutions that both programmers and non-programmers proposed for solving exercise 4. We did not include screenshots due to lack of space and readability problems.

Figure 13-α is the optimal solution; it relies heavily on cascade mechanism and factorization of contexts. Figure 13-β is a quite straightforward translation in CCBL of the exercise 4 statement (Table 2 Ex 4), it can be read in a similar way than the ECA solution expressed in Figure 9 (with TAP semantics). On the contrary, the participant was able to concentrate on the contexts for which the lamp A had to be lit in orange, green or white. For all other contexts, the lamp is off as specified in the root context. An interesting insight is what the participant said at the end of the session: "There was the problem of specifying the invert actions, I only thought about it when programming with ECA but I would not be able to explain why".

Finally, the solution illustrated in Figure 13-γ follow a decision tree strategy elaborated by a programmer. This participant first tried to solve exercise 4 using ECA, he drew for that purpose the schema reproduced in Figure 12. Despite this schema, he forgot some rules in his ECA programs. However, it is interesting to observe that this schema is close to the structure of the CCBL program of Figure 13-C, all the more since it was written before the participant knew about CCBL. Actually, the same participant (a non-programmer) wrote these ECA and CCBL programs. However, the ECA program misses one rule ("When Alice is not as home and not at Martin's home then turn off lamp A"). Fig. 12. Schema drawn by one programmer for exercise 4 in ECA. The two roots are "Martin is at home" and "Martin is not at home". Children of the first root are "Alice is not at home", "Alice is at home" and "Alice is at Martin's home". of the programming process (e.g., we do not consider debugging). We assume that that the quicker the program is correctly specified, better it is for users.

CONCLUSION

In this paper, we introduce CCBL (Cascading Contexts Based Language), a new language dedicated for programming the Smart Home. We built CCBL around the notion of context rather than events as it is for ECA (Event Conditions Actions). CCBL support users' way of reasoning better than ECA by facilitating non-sequitur reasoning and general case / particular case reasoning.

We set up an experiment with eleven programmers and ten non-programmers. We asked them to program four Smart Home behaviors of increasing complexities that associate devices' states to context. Results show that both programmers and non-programmers do significantly fewer errors when programming with CCBL than when programming with ECA. Every participant was able to program correctly the four behaviors except two nonprogrammers that make errors for the exercise 4.

Results of our experiment also show that users, especially non-programmers, tend to blur the distinction between event and condition when programming with ECA. We observe that users tend to turn from the actual semantics of ECA, where rules are triggered by events, to the semantics of Triggers-Actions Programming (TAP). While TAP enables users to program rule of the form "if conditions than actions", our experiment show that users tend to forget to specify rules to reverse actions when behaviors are complex. We also show that users tend to apply a general case / particular case reasoning although neither TAP nor ECA actually support it, on the contrary of CCBL.


Florin Constantin

Law enforcement against rural wild

As a new EU Member, Romania faces serious challenges in providing reliable waste management services in rural areas and illegal waste disposal is still an issue. The paper examines the closure effects of wild dumps in order to start a better waste management in rural areas.

In Satu Mare County urban areas, waste collection increased from 70% in 2007 to 100% in 2009. MSW is transported to two urban landfills of Tasnad and Satu Mare cities. With the support of EU funds, a regional sanitary landfill, 2 transfer stations (in Carei and Negresti-Oas cities), 4 micro-transfer stations (in Tasnad and Livada cities, Valea Vinului and Beltiug communes) will be created. In rural areas, waste collection increased from 7% in 2007 up to 71% in 2009. But the lack of a regular waste collection service led to an uncontrolled waste disposal in local dumps. Most of rural municipalities had dumps in public areas until the EU adhesion. The closure and monitoring of these sites before July 2009 had obliged several Local Authorities to provide basic waste management services. These sites had to be closed and rehabilitated under a simplified procedure according to Minister Order nr. 1275/2005. The conventional landfills had to be closed according to the Government Decision nr. 345/2005 (which transposes the EU Landfill Directive 1999/31) following the technical normative Order 757/2004. 122 dumps were compacted and soil covered. No dump was moved or transported to urban landfills (CCSM, 2010).

Wild dumps remain a current environmental threat in rural Romania and in small urban areas, and the plain region of Satu Mare County favours waste accumulation in large dumps. The total dumping volume registered is 355,340 m3 equivalent to 142,136 tons of waste disposed using a specific density of 400 kg/m3. The demographic features and spatial patterns of human settlements influence the uncollected generated waste disposal method.

  Preprint version -please to cite: Mihai FC. 2017. Law enforcement against rural wild dumps in Romania -Satu Mare County case study In: Girotto F (Ed). A Glance at the World . Waste Management 62 : I-III doi: http://dx.doi.org/10.1016/S0956-053X(17)30211-8 Law enforcement against rural wild dumps in Romania -Satu Mare County case study Author: F.C. Mihai Department of Research, Faculty of Geography and Geology ''Alexandru Ioan Cuza" University of Iasi, B-dul Carol I, Nr. 20 A, Romania

  Reference CCSM (County Council of Satu Mare), 2010. County Waste Management Plan. Monitoring Report 2009.


Riccardo Petrolo

Valeria Loscri

Nathalie Mitton

Elisa Herrmann

Adaptive Filtering as a Service for Smart City Applications

Keywords: Smart Cities, Internet of Things, Cloud of Things, Filtering

Smart cities are a key factor in the consumption of materials and resources. As populations grow and resources become scarcer, the efficient usage of these limited goods becomes more important. Building on and integrating with a huge amount of data, the cities of the future are becoming a realization today. There are millions of sensors in place already, monitoring various things in metropolises. In the near future, these sensors will multiply until they can monitor everything from streetlights and trashcans to road conditions and energy consumption.

In this context, effective strategies or solutions for refining data sets can play a key role. Based on these premises, we propose intelligent and adaptive filtering mechanisms as a service (FIlAAS) integrated in the VITAL-OS middleware and will show their feasibility and their effectiveness in the smart city context.

I. INTRODUCTION

With the growth of our population and the advent of concepts such as cloud computing and the Internet of Things (IoT), the natural step cities will take is to become more interconnected. There are millions of sensors in place already, monitoring various things in metropolises. In the near future, these sensors will multiply until they can monitor everything from trashcans to streetlights and to road conditions and energy consumption [?].

These smart cities will allow us lowering energy consumption, optimizing resources exploitation, and building efficient cities.

The European Commission has predicted that by 2020, there will be 50 to 100 billion devices connected to the Internet [?]. When large numbers of sensors are deployed and start collecting data, traditional application-based approaches become infeasible. Therefore, researchers have introduced a significant amount of middleware solutions.

In the literature, there are numerous descriptions of middleware to support wireless sensor networks in a broad spectrum of activities. IoT middleware solutions help users retrieve data from sensors and feed them into applications easily by acting as mediators between (remote) hardware and application(s). Moreover, several filtering mechanisms have been proposed in different contexts ranging from Wireless Sensor Networks to RFID. In the IoT context, there is a real need of effective filtering mechanisms.

This work is partially supported by CPER FEDER DATA and by the European Community in the framework of the VITAL FP7 project.

In this paper, we propose an adaptive filtering mechanism as a service, able to reduce and refine the initial dataset on the basis of the parameters defined by the user. The mechanism is integrated in the VITAL platform in order to show its effectiveness.

The rest of the paper is organized as follows. In Section II, we give a general overview of the VITAL architecture and its components. In Section III, we detail the filtering module and specify the two types of filtering mechanisms implemented as static filtering. Section IV describes the continuous mechanism filtering as adaptive approach. Section V overviews the broad set of filtering problems and solutions. Finally, we conclude our paper in Section VI.

II. VITAL

The main objective of VITAL is to integrate different IoT platforms and ecosystems. To this end, a key factor is the virtualization of interfaces in combination with cross-context tools that enable the access and management of heterogeneous objects supported by different platforms and managed by different administrative stakeholders.

Figure 1 shows the VITAL architecture organized in three main layers: IoT Platforms and Data Sources, Platform Agnostic Management, Monitoring and Governance, and Smart City Applications and Tools. Below we present the features of fundamental modules:

• IoT Platforms and Data Sources. At the bottom of the architecture different data-sources stand. In order to be virtualized and integrated into VITAL, those systems have to expose a well defined PPI (Platform Provider Interface).

III. INTELLIGENT MECHANISMS OF FILTERING

The Filtering module can be accessed through RESTful web service. The communication standard used to exchange data is JSON(-LD), the format in which this information will arrive as input to the filtering module. The received parameters will then be used to drive the filtering process itself. In order to retrieve information, the Filtering module relies on the query endpoint provided by the Data Management Service (DMS). To this end, queries are defined using MongoDB1 Query standard. According to the standard, query parameters are exchanged using a JSON object containing specific criteria, or conditions, to be used for the selection of required results. The VITAL Filtering module supports two different functions, threshold and resampling.

A. Threshold Filtering

Threshold filtering is a function that allows users and applications to retrieve observations based on the comparison of the measured value of a property and a threshold value defined in the request. Figure 2 shows an example of the interactions between the Filtering module and a generic requester. In this example, a requester (i.e., the Orchestrator module) directly activates the Filtering with the objective to filter observation for a specific ICO. The function receives as input a JSON object containing a set of keys like ICO identifier and threshold numerical value. The request object is enriched with other options in order to configure the filtering process to operate on a wider set of parameters.

In the following, we give some more details about the available options in the filtering request and how they can be configured to change the filtering logic. The key position has been included to allow the filtering in a specific spatial region. The aforementioned key is associated to a JSON object with the triple latitude, longitude and radius. Even though position is optional, the triple is mandatory. If a user wants to restrict the filtering process over a specific area, all the elements of the triple must be provided. If one of the element is missing the request is considered as malformed and a status code 400 (Bad Request) is returned. The keys ICO and position are meant to be used alternatively. If the request object contains the ICO key, the filtering is performed only over the observations measured by the selected internet connected object. If, instead, the request is characterized by the definition of position option, the filtering process is performed over the observations measured by all the internet connected object that are registered in the geographical region specified in the request. The option inequality defines the relationship between the threshold value and the observed value.

Keys from and to define a time interval over which the filtering is performed and expect input values in the XSD format. The limitation over a time interval is optional, and the filtering behavior changes according to the received configuration. If both time boundaries are defined the filtering is limited on the observations within the selected range. If only from is provided, to is automatically set to the time value at the moment of the request. If no time range is defined the filtering process is performed over all the observation in the system. For visually illustrating the filtering mechanism, we can consider all available observations stored in the DMS, for a specific ICO, regarding speed measurement. Such observations can be plot as illustrated in Figure 3.

B. Resampling

In the digital signal processing theory, a signal can be sampled on a specific sample rate, measuring a physical value on regular time intervals. Once the signal have been sampled, the need to change this time interval can occur. This change can be indicated as upsampling when the number of samples is increased and downsampling when the number of sampling is decreased. Upsampling operations are usually executed using an interpolation process, whereas the downsampling operations are conducted through a decimation process. In the case where both operations are available the resultant is known as resampling. For the filtering functionalities we wanted to extend this concept also to data measured by an internet connected object. Through the use of the resampling function, observations stored in the DMS can be used as data source to create a set of observation, which are separated in time by a constant value. To provide an example, suppose that an application need to calculate the speed measured by an ICO with an interval of 15 minutes, while data are measured with a interval than can vary from 8 to 12 minutes. To this end Adaptive filtering provides the capability of creating customized filters that support complex filtering pattern by means of a Complex Event Processing. The filter takes streams of incoming events, in the form of input observations and evaluates whether those events meets the rules specified by the user and then publishes the resulting events to observers. The VITAL CEP components for the different adaptive filters are implemented based on the ATOS reference architecture for distributed, scalable and cloudified complex event processing [?]. An event stream can have an infinite number of events. Windows provide a means to select event subsets for complex event detection. Out of many possible ways to select events, two of the most basic mechanisms include:

• Time Windows: In some specific cases, it is not sufficient to detect a complex event when certain values are detected. There is a need to take time range into account as well. For example, detecting events when certain values exceed or fall below some threshold within a specified time period. These time periods are usually represented by fixed time windows or sliding time windows. For example, sliding time window can collect all sensor readings during the last two hours and fixed time window collects readings once every second hour; • Tuple Windows: Instead of measuring elapsed time, tuple windows select events based on number of occurrences of particular events within an input stream. A typical example of tuple window is collection of last twenty sensor readings for further evaluation. The typical transient event lasts for infinite small periods. However real world scenarios require support for so called long lasting events. The duration of such events is for a fixed amount of time or until another event arrives. Specifically, in the context of VITAL the idea of join events is to match events coming from different input streams and produce new complex event stream. A join between two data streams necessarily involves at least one window. To perform a join, it is usually necessary to wait for events on the corresponding stream or to perform aggregation on selected events.

The most complex event processing implementations support window to window joins, outer joins or stream to database joins. The joins are used for example to correlate information across different security devices for sophisticated intrusion detection mechanism and response.

A. Continuous Filtering

The CEP reference architecture is composed of four functional blocks as listed below: • Complex Event Detector • Complex Event Publisher Continuous filtering is the capability of attaching filtering to a data stream and receiving filtered results by listening to observations of different sources collected in the DMS till a delete filter request tells the filtering mechanism to stop. This filtering mechanism will create a CEP as a data stream endpoint, and will publish the results as observations continuously to the DMS until the filter is no longer needed and is stopped by the user application. The components of the Continuous Filter are depicted in 4. The Filter Administrator for the continuous filter has been redefined to create, read, update, and delete continuous filters as virtual sensors.

• Coordinator • Event Collector
In this case, the Event Collector the Listener component is totally redefined for subscribing observations sources from the DMS allowing the collection of historical and real time observations to be filtered. The listener process has been implemented for pulling observations from the source sensors until the user sends a request to stop the filter. Since the filter is going to last longer than the creation request, the Event Collector and the Event Publisher are redefined to run in different threads from the Filtering Administrator component as they are going to be needed until the filter is stopped. Once the CEP instance is created and the components are running, the response to the user application is the identification of this new virtual sensor in order to query the filtered observations or to manage the continuous filter. Due to the modularity of the Atos CEP architecture, it is possible to implement many different kinds of adaptive filters providing different implementations of the functional blocks of the architecture. For example, filters that compare events to events in same or different stream, or compare events to some aggregated values. A typical example of event filtering is capturing sensor readings where values average fall outside of expected range.

In this case, the Event Collector the Listener component is totally redefined for subscribing observations sources from the DMS allowing to gather historical and real time observations to be filtered. The listener process has been implemented for pulling observations from the source sensors until the user send a request to stop the filter. The VITAL Event Filtering functionality is exposed through set of RESTFul Services through the Filtering administrator for managing the different type of filters it provides.

V. RELATED WORK

In literature there are numerous descriptions of middleware that implement filtering functionality. IoT middleware solutions help users retrieve data from sensors and feed them into applications easily by acting as mediators between (remote) hardware and application(s). One example is Middleware Linking Applications and Networks (MiLAN) [?], which describes a complex middleware aimed to assist the communication over WSN for specific purposes. MiLAN receives information about the applications and about the sensors and resources available in the network. It exploits such information to adapt the network configuration and, at the same time, meet the application's needs while extending the network lifetime. One of the filtering functions provided by MiLAN is mainly related to the selection of nodes actively involved. As an example, there may be scenarios where multiple sensors have overlapping coverage areas, hence producing redundant information. The ability to enable only a subset of nodes in the area can meet the application requirements and at the same time save energy and extend the network lifetime. To this purpose the system takes into account the power costs of using every node in the network, which include the power to run the device, the power to transmit its own and other nodes data and the power needed to maintain a specific role in the network. The resources available in the network can be used to introduce Virtual Sensors obtained by mixing different data sources. Such functions can be exploited in the VITAL system.

Another example of proposed middleware is Garnet [?], where the architecture is mainly focused in data stream management. In the model depicted in Garnet, many sensors transmit their data to a fixed network infrastructure via a wireless medium. The access to this network is granted through receivers. The relationship between sensor nodes and receivers is many to many, thus arriving data undergoes a filtering process. Such a process reconstructs the data stream by eliminating duplicates generated by the reception of the same information by multiple receivers. Moreover the broker is capable to filter sensor data according to the global needs. So the acquired raw data are pre-processed, filtered and enriched with semantic information. Another important aspect is that those data should be sent to the interested receivers in near real time. To this end the publish/subscribe paradigm offers an appropriate solution. It offers a selective and flexible acquisition and filtering mechanism of sensed data on mobile devices. The dynamism and flexibility offered is because it takes user's preferences expressed as subscription into account. Furthermore, communication between publishers and subscribers is asynchronous, thus a device can be registered and disconnected at the same time. All the data that suits device's subscriptions can be sent as soon as it gets reconnected.

Liu and Martonosi in [?] propose a middleware architecture that enables application modularity, adaptability, and reparability in wireless sensor networks. The proposed Impala allows software updates to be received via the nodes wireless transceiver and to be applied to the running system dynamically. The filtering capabilities in this case are used in order to dispatch events to the above system units and initiate chains of processing. Within the context of RFID, different filtering mechanisms have been introduced in literature; for example the EPCglobal standard specifies filtering mechanisms as part of the ALE (Application Level Event) layer of the architecture [?]. As specified by the EPCglobal standard in [?], the role of the ALE interface within the EPCglobal Network Architecture is to provide independence among the infrastructure components that acquire the raw EPC data, the architectural component(s) that filter & count that data, and the applications that use the data. In detail, the ALE interface:

• Provides a means for clients to specify, in a high-level, declarative way, what EPC data they are interested in, without dictating an implementation. • Provides a standardized format for reporting accumulated, filtered EPC data that is largely independent of where the EPC data originated or how it was processed. • Abstracts the sources of EPC data into a higher-level notation of "logical reads", often synonymous with "location", hiding from clients the details of exactly what physical devices were used to gather EPC data relevant to a particular logical location. Authors in [?] introduce a middleware implementation of ALE mechanisms. The proposed AspireRFID2 extends the filtering function to any kind of data such as active sensor data, MAC addresses, phone numbers, etc. The Cougar project3 aims to tasking sensor networks through declarative queries. Given a user query, a query optimizer generates an efficient query plan for in-network query processing, which can vastly reduce resource usage and thus extend the lifetime of a sensor network. In this case, the filtering capabilities of the system are used in order to filter the sensors interested by the query. The main aspect that we addressed with this literature analysis was to identify a broad set of filtering problems and solutions. Unfortunately, due to the position of our filtering functions, some of those problems cannot be properly addressed. This is because some of those functionalities are strictly connected with the sensing devices. This means that they have to be handled by entities themselves, which reside inside the individual silos, before data is sent to the VITAL platform, like the filtering of duplicated values. Some other aspects are instead too specific to applications or users thus such operations should be left to the applications, which lie in an upper layer.

VI. CONCLUSION

In this paper, we have proposed different filtering mechanisms as a service and we have shown their feasibility and their effectiveness when integrated in the context of VITAL-OS framework, a semantic-based framework able to manage several data sources in the context of the Internet of Thing paradigm with an horizontal vision of the different platforms. Specifically, we have shown a viable solution to shrink the data set based on the parameters defined by a user. Continuous and adaptive filtering give the possibility to compare events to events that belong to the same or to different stream, or

Fig. 1 :

 1 Fig. 1: The VITAL architecture.

Fig. 2 :

 2 Fig. 2: Filtering threshold -Example of interactions.

  (a) Speed observations of an ICO (b) Selection Threshold

  Fig. 3: Filtering mechanisms.

Fig. 4 :

 4 Fig. 4: CEP Continuous Filter Architecture.

https://www.mongodb.com

http://wiki.aspire.ow2.org

https://www.cs.cornell.edu/boom/2004sp/ProjectArch/Cougar/index. html compare events to some aggregated values. Filtering mechanisms represent a very valuable added functionality for IoT platforms.