«To cite this version: Zo´ Drey, Charles Consel. Taxonomy-Driven Prototyping of Home Automation Applicae tions : a Novice-Programmer Visual Language ...»
Context-centric model. To represent the reactive nature of Pantagruel, we leverage the context information provided by the taxonomy, focusing on what data are available at each orchestration step, instead of how these data are acquired. These data, representing the runtime state of a program, are made easy to manipulate via the sensor column of the orchestration panel.
Discrete time and parallel mode. Discrete time is modeled as clock ticks. Each tick corresponds to an orchestration step where all the rules are evaluated within a tick. Parallel mode assumes that all the rules, whose conditions are satisﬁed at a given step, are executed with the same state, making this execution simultaneous. As a result, there are no rule dependencies within a step; the user can observe the intended method invocations in the right part of the visual layer by selecting speciﬁc sensors in the left part.
Non-interfering execution. We say that execution is non-interfering when two rules can be executed independently from each other because their side-eﬀects are disjoint. The side-eﬀect declarations of methods enable to detect potential interferences. We use this language property to guide the user when he deﬁnes orchestration rules with side-eﬀecting methods. A conﬂict can be displayed on the visual layer by highlighting interfering rules. This process forces deterministic behavior, thus increasing the conﬁdence of the domain expert when developing orchestration rules.
6. Development process
The visual editor is parameterized with respect to an environment description, loaded as an XML ﬁle. Doing so enables to guide the domain expert in the creation of rules. This process is decomposed in conformance with the Pantagruel visual paradigm: ﬁrst, the domain expert selects the entities relevant to the application to be deﬁned (Figure 10). To do so, he selects the entity tool in the palette, which opens a contextual window listing the entity classes and their entity instances, available in the target environment description. The domain expert can ﬁrst deﬁne a program that manipulates speciﬁc entities. To generalize rules, he can replace speciﬁc entities with an entity class, by simply selecting the generic entity, as speciﬁed by the ANY keyword in the pop-up window.
Figure 10: Selecting the relevant entities for the application
Second, he extracts context information from the selected entities (Figure 11). To guide the domain expert, another pop-up window lists the available attributes within a section, as well as their possible values, according to the data types deﬁned in the concrete environment. In doing so, the programming process prevents syntax and type errors by contruction.
Figure 11: Selecting the relevant context information among the available attributes Third, he selects the actions that achieve the expected behavior from a pop-up window, similar to the attribute window. Finally, the domain expert connects the conditions and actions with a controller selected in the palette; a phrasing of the rule appears on the controller pop-up window (Figure 12).
7. Towards an expressiveness study A ﬁrst step towards evaluating the expressiveness of Pantagruel is to study its ability (1) to model a range of entities that are found in the home automation domain, and (2) to model a range of applications related to home automation. We now present this study.
7.1. Study context To conduct our study, we have decomposed the requirements for applications of the home automation domain into increasingly speciﬁc goals This decomposition has resulted into elementary goals. For example, the “managing energy” requirement was decomposed into subgoals.
One of them was “controlling lights”, which itself was further decomposed into three subgoals, “detecting presence”, “measuring luminosity”, “adjusting light intensity”.
This decomposition process exposes the context information and the functionalities needed to express a range of applications in a given area. In doing so, each elementary goal is readily mapped into one or more objects, selected from a library of entities, according to the functionalities provided by these objects. For example, “measuring luminosity” was mapped to a light sensor. In our study, this type of mapping resulted in a taxonomy for each application area.
Table 2: Orchestration application case studies Each taxonomy deﬁnition consisted of 9 to 15 entity classes as reported in Table 1. In total, the three areas involved 50 entity classes. Some of them were shared among the areas (e.g., the presence detectors, the lights, and the calendars). For each area, we developed 3 to 6 applications, each consisting of 2 to 7 rules. Out of 20 applications, 15 of them have been deployed on the DiaSim simulator. These applications are reported in Table 2. We consider school management as a generalization of the home automation domain to large-scale buildings. Applications reported for the assisted living area were demonstrated at Percom’10 .
7.2. Entity design space
Writing the taxonomy deﬁnitions for the domain of home automation exercised key dimensions of our language expressiveness. Each dimension addresses the following facets of entities:
physical and virtual sensing, conﬁguring and monitoring, and processing. An entity class may be an arbitrary combination of these facets.
Physical and virtual sensing. Home automation applications highly depend on the periodical changes of the surrounding environment. For example, an application that manages energy needs to react to temperature changes. The varying nature of an environment is captured by physical and virtual sensors. Unlike physical sensors, virtual sensors capture a status related to a computer activity. For example, an instant-messenging client detects whether the owner of a computer is online or away. The Calendar entity class of our example application, sending events according to a day planning, can also be modeled as a virtual sensor. Such varying information can be represented by volatile attributes, whether coming from physical or virtual devices.
Conﬁguring and monitoring. A fundamental requirement of home automation is to be able to conﬁgure an environment according to sensed information and user preferences. We call components performing such activities, conﬁguration components. For example, consider a music management application deployed in a house that relies on a radio installed in every room. Each radio is conﬁgured according to the preferences of the user entering the room. The conﬁgurable parts of this entity class are modeled as write attributes, such as a musicGenre attribute on Radio.
The preferences of a person can be gathered in a speciﬁc entity class (e.g., PersonProfile), deﬁning constant attributes (e.g., a preferredMusic attribute).
Entity classes monitoring actions also declare speciﬁc write attributes. In the shower example, the run method of MixingValve is monitored by adding a showerStatus write attribute on the MixingValve methods.
Processing. When they involve numerous entities, home automation applications often consist of gathering and processing data sources. Such processing is typically deﬁned in terms of input/output dependencies. To illustrate this approach, let us consider an energy management application. This application needs to conﬁgure heaters by processing sensed temperatures and other sources such as time and room occupancy. An example of such component is the HeatManager entity class that collects the people locations and working hours, and determines a target temperature for the heaters. The target temperature is captured by a write attribute (e.g., avheat); the processing is deﬁned by the calculateHeat method, declaring the avheat in its side eﬀects.
Summary. In this section, we identiﬁed three facets of entities, covering a range of application areas, captured by our taxonomy language. Our preliminary expressiveness study provides an illustration of the relevance of the Pantagruel taxonomy abstractions (e.g., attribute kinds and side-eﬀect declarations).
7.3. Orchestration language expressiveness The taxonomy language provides the necessary building blocks to model a range of home automation entities. This is put to practice by the following analysis that conforms with the iCAP process  and covers Schilit’s four applications categories .
Proximate selection. Proximate selection applications enable to access resources according to their proximity. The ﬁltering mechanism of the Pantagruel orchestration layer generalizes this selection process to any context information beyond location: it provides a concise means to prototype a range of applications requiring resource selection. For example, it is used to select a tagged outﬁt according to the current weather (see the Tag section of Figure 7). Such applications involve at least sensing components, as deﬁned in our entity design space (see Section 7.2).
Automatic contextual reconﬁguration. Applications of this category can detect the dynamic change of resources, that is, appearance or disappearance of components, or new connections between components. These applications include the follow-me applications, where the user interface of the application can follow the user as he moves around . For example, a light follow-me application written in Pantagruel is displayed in Figure 8. Because Pantagruel leverages an entity discovery mechanism provided by its underlying platform , applications can manage appearing and disappearing entities. Such applications combine conﬁguring and sensing components.
Contextual information and commands. Applications in this category execute commands parameterized by the contextual information captured by entities. We support these applications through the use of typed attributes and parameterized methods. Attributes, representing the context information may serve as parameters on the entity methods. For example, consider an application such that when a person enters a room, his smart phone displays information customized with respect to his new location; this operation would correspond to an actuator invoking a displayLocation method on a smart phone entity class, with the location as an argument.
Such applications combine conﬁguring and processing components.
Context-triggered actions. Applications that deﬁne such actions extend the previous category by allowing context-triggered commands to be “invoked automatically according to previously speciﬁed rules” . In the Pantagruel orchestration layer, this feature is enabled by the write attributes, as deﬁned in monitoring components. Speciﬁcally, a write attribute depicts a dependency between two rules when (1) it is accessed in the sensor part of a rule, and (2) it is modiﬁed in the actuator part (i.e., an assignment or a side-eﬀecting method) of another rule. This rule dependency is illustrated in our working example (Figure 6): on the one hand, the R5 rule includes in its sensor part the todolist attribute of the TimeTracker entity class; on the other hand, the R3 and R4 rules set the value of todolist in their actuator part, through the init method invocation; therefore, triggering R5 depends on the previous execution of either R3 or R4.
Summary. Through this study, we experimented and illustrated the ability of Pantagruel concepts and paradigm to embrace the four categories of applications proposed by Schilit et al., in conformance with their meaning.
8. User Study We evaluated whether non-programmer users could create orchestration rules for a predeﬁned taxonomy, using the Pantagruel visual programming environment. In particular, we evaluated the
following aspects of our language:
• Intuitiveness of the Pantagruel visual paradigm. We evaluated whether a development process driven by the entities was suitable for a non-programmer.
• Accessibility of the Pantagruel abstractions. We evaluated whether a non-programmer could create class-based orchestration rules for a range of entities.
We conducted a user study in two phases. The ﬁrst phase involved 12 participants, and aimed to collect feedback for improving the Pantagruel tool. The second phase involved 6 participants, and aimed to assess an improved version of the Pantagruel tool, as reported in Section 9.3. Both phases were conducted with the same study context and process. We now describe the material of this user study.
8.1. Study context The user study was composed of the following material: a pre-questionnaire aimed to collect the computer science background (programming language or visual software) of the participants.
After the participants were presented a short tutorial of our tool, we observed them expressing a set of 6 rules (see Tables 3 and 4) using our tool. Finally, a post-questionnaire, based on the System Usability Scale , gathered their overall acceptance of the Pantagruel tool. As shown in Figure 5 of Section 5, two screens were set up for each session of our user study: a screen displayed the Pantagruel editor; the other screen displayed a 2D-model of a house. It served as a visual support for choosing the entities to orchestrate. Initially, the Pantagruel visual editor was empty.
To accompany each participant during the study session, we recruited two test observers in our research group. One of them helped the participant if he felt confused for too long (i.e., hesitating for more than 3 minutes) or if he had problems with the graphical interface (e.g., how to use the tool palette). The other observer noted down the behavior of the participant (e.g., an invalid user-interaction with the editor, or when he thought aloud) and the interventions of the ﬁrst observer. Interventions mainly consisted in showing how to interact with the editor, and showing elements of the solution (e.g., pointing at the ANY keyword on the entity pop-up window).
Table 4: Advanced rules sentences and average rule completion time (groups 1 and 2), in minutes