«To cite this version: Zo´ Drey, Charles Consel. Taxonomy-Driven Prototyping of Home Automation Applicae tions : a Novice-Programmer Visual Language ...»
Taxonomy-Driven Prototyping of Home Automation
Applications : a Novice-Programmer Visual Language
and its Evaluation
Zo´ Drey, Charles Consel
To cite this version:
Zo´ Drey, Charles Consel. Taxonomy-Driven Prototyping of Home Automation Applicae
tions : a Novice-Programmer Visual Language and its Evaluation. Journal of Visual Languages and Computing, Elsevier, 2012, Journal of Visual Languages & Computing, 23 (6),
10.1016/j.jvlc.2012.07.002. hal-00718943 HAL Id: hal-00718943 https://hal.inria.fr/hal-00718943 Submitted on 17 Apr 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destin´e au d´pˆt et ` la diﬀusion de documents e eo a entiﬁc research documents, whether they are pub- scientiﬁques de niveau recherche, publi´s ou non, e lished or not. The documents may come from ´manant des ´tablissements d’enseignement et de e e teaching and research institutions in France or recherche fran¸ais ou ´trangers, des laboratoires c e abroad, or from public or private research centers. publics ou priv´s.
e *Manuscript Click here to view linked References
Taxonomy-Driven Prototyping of Home Automation Applications:
a Novice-Programmer Visual Language and its Evaluation Zoé Dreya, Charles Consela,b a INRIA, Bordeaux Sud-Ouest b University of Bordeaux/LaBRI Abstract Home automation environments are dedicated to helping users in their everyday life and are being deployed in an increasing number of areas, including home security, energy consumption, and assisted living. The range of situations to be addressed makes the development of home automation applications challenging: it requires to manage heterogeneous entities with a wide variety of functionalities. Moreover, since this area covers a large spectrum of user needs, it is crucial to ease the development and the evolution of t
Preprint submitted to Journal of Visual Languages and Computing May 31, 2012 Because the users of home automation environments are intimately concerned with applications, it is crucial to make the development process usable by the widest audience. To address this challenge, the learning threshold of application programming can be lowered, enabling the user of applications to program them. To do so, end-user approaches have been proposed to prototyping pervasive computing applications. These approaches provide a domain-speciﬁc vocabulary (e.g., iCAP ) or use a metaphor-based representation (e.g., CAMP ). To assess their approaches, researchers conducted user studies [3, 1, 7, 4].
In most cases, usability is obtained at the expense of expressiveness: the proposed approaches are restricted to a speciﬁc area, making hard the evolution of applications with regard to the technology advances. Because new devices and functionalities are continually made available, the application areas should be enriched accordingly (for example, cellphones turned into a multifunction device). Furthermore, as user requirements evolve over time, applications should be easily adjusted. This situation is well illustrated in the assisted-living area. For example, applications for assisting an intellectually impaired person necessitate periodic adjustment as his conditions improve or deteriorate.
Therefore, combining usability and expressiveness is crucial for an application development approach in the domain of home automation.
This paper This paper presents Pantagruel, a high-level language that integrates expressiveness and usability for programming home automation applications. Pantagruel is dedicated to the development of applications, parameterized by the description of a home automation environment.
Speciﬁcally, our approach consists of a two-step process: (1) the description of a home automation environment takes the form of a taxonomy and deﬁnes the functionalities and the properties of the environment entities; (2) the development of a home automation application is driven by a taxonomy of entities and consists of orchestrating them using high-level constructs. To support these two steps, the Pantagruel language consists of a taxonomy layer and a visual orchestration layer.
The taxonomy deﬁnition allows our approach to be instantiated with respect to a given application area. This description deﬁnes the classes of entities that are relevant to the target area.
Each class speciﬁes an interface to access its functionalities. Because the orchestration logic is written with respect to the environment description, entities are combined in compliance with their description. The taxonomy deﬁnitions make our approach open-ended, adding an expressiveness dimension to cover a range of areas. A ﬁrst step towards evaluating this expressivenes is reported in Section 7.
To facilitate the programming of the orchestration logic, we have developed a visual tool that uses a sensor-controller-actuator paradigm. This paradigm is suitable for novice programmers, as demonstrated by its use in various ﬁelds such as computer game design (e.g., Blender1 ) and robot control (e.g., Altaira  or LegoSheets  for Lego Mindstorms2 ). Like a game logic, an orchestration logic collects context data from sensors, combines them with a controller, and reacts by triggering actuators. Furthermore, our visual programming environment oﬀers the developer an interface that is customized with respect to the environment description. Information about the environment entities is exploited to guide the programmer in deﬁning sensor-controller-actuator 1 http://www.blender.org 2 http://mindstorms.lego.com/ rules. This approach makes Pantagruel usable by novice programmers, as illustrated by our user study, reported in Section 8.
The main contributions of this paper are as follows.
An open-ended approach We introduce an approach to visually prototyping orchestration applications. The novelty in this approach is that it is parameterized with respect to a description of a home automation environment. This makes our approach applicable to a range of areas for the domain of home automation.
A taxonomy-driven visual language We extend the sensor-controller-actuator paradigm to allow the programming of the orchestration logic to be driven by an environment description. This approach eases programming and enables veriﬁcations. Moreover, early testing of applications is made possible by leveraging a home automation simulator, named DiaSim , in the Pantagruel environment.
Towards an evaluation of Pantagruel expressiveness We show that our taxonomy language ranges over the categories of entities of the home automation domain. Furthermore, we evaluate the ability of the orchestration layer of Pantagruel to express a range of home automation applications.
An evaluation of the orchestration logic usability We validate the usability of the orchestration layer of Pantagruel by a user study performed with eighteen novice-programmer participants. This study is based on existing usability evaluation processes found in the home automation literature.
To motivate our approach, Section 2 presents an example of an assisted-living application.
Section 3 examines the requirements for a development approach targeting the domain expert of home automation areas. Section 4 introduces our taxonomical approach to deﬁning descriptions of home automation environments. Section 5 presents a visual environment to develop applications that orchestrate entities, deﬁned in a taxonomy. Section 6 details the development process for building home automation applications using our taxonomy-driven approach. Section 7 presents a study towards validating the expressiveness of our approach. Sections 8 and 9 validate the usability of our approach. The related work is detailed in Section 10. Concluding remarks and future work are provided in Section 11.
2. Working Example
To motivate our approach, we consider as an example an assisted-living application. This example is based on scenarios collected by a thirty-years experienced caregiver, and dedicated to cognitively impaired persons.
This application area orchestrates various kinds of entities, consisting of RFID readers and tags, a calendar, an alarm clock, a mixing valve, and a time tracker to indicate a task status.
Figure 1 is an example of a physical layout for an impaired person’s apartment.
Our example scenario compiles situations encountered in Svensk’s career as a care- TAGREADER ALARM SMARTDOOR TIMETRACKER MIXINGVALVE MOTIONSENSOR giver . More scenarios have been collected TAG and documented in Carmien’s thesis .
Figure 1: Henrick’s apartment Svensk describes the beginning of a working day for Henrick, a ﬁctitious character with intellectual disabilities, who lives independently in an apartment. He needs to be assisted during the day, from the time he wakes up until he leaves his apartment for work. Speciﬁcally, Henrick needs to wake up on time according to his day activity: work or holiday. To help him wake up, his alarm clock is conﬁgured to play a music whose genre is determined with respect to the day activity.
Once Henrick is awake, he needs to take a shower, then get dressed, and have breakfast. Because he has diﬃculties to regulate the water temperature, automation needs to be introduced in the shower to address this problem. Svensk proposes a system such that “when [Henrick] closes the door, the water comes on automatically at just the right temperature”. Such automation enables Henrik to turn the shower activity into an ordinary step of his morning routine. After the shower, Henrick gets dressed. To select the clothes that are appropriate for the weather, he is assisted by a caregiver: he “gets dressed in the clothes a staﬀ member has laid out on a chair”.
To relieve the caregiver from the task of picking clothes for Henrick a Web service and RFID technology can be combined. Speciﬁcally, Henrick is being informed about the latest weather report, when he enters the dressing room. To ensure that selected clothes are appropriate, they are attached a RFID tag. These tags, combined with a tag reader, make it possible to warn Henrick in case the selected clothes are not adequate for the weather of the day.
Because Henrick is unable to read the time on a clock, a speciﬁc process must be devised to allow him to keep track of time and tasks he needs to perform. In doing so, Henrick’s daily tasks can be streamlined, preventing panic caused by a task that is omitted or performed for too long.
To do so, software appliances such as a calendar and a time tracker can be used.
Many other scenarios for assisted living could be imagined, combining other related activities, such as assistance for cooking and leaving home on time. In fact, for a given environment, it should be possible to deﬁne various orchestration scenarios, adapting to users’ requirements and preferences, and reacting to users’ feedback. Because these scenarios can have a tremendous impact on people’s life, it is critical to ease the creation and improvement of orchestration logic.
In doing so, orchestration logic becomes understandable to the widest audience and close to the users’ informal speciﬁcation.
Also, our example application area illustrates the richness of the entities that are commonly available today, requiring expressiveness to combine them. Finally, the assisted-living environment consists of entities for which numerous variations are available, requiring an approach to deﬁning the orchestration logic that abstracts over these diﬀerences.
3. Requirements for home automation development tools
The requirements for tools to develop home automation applications strongly depend on the developers targeted for these tools. In this section, we ﬁrst identify these developers. Then, we examine the needs for such tools. Finally, we examine the needs to make accessible the building blocks of an application area of the home automation domain.
3.1. Identifying the users The home automation domain involves a variety of roles, from the installer, who equips the house with networked devices, to the occupants, who are the end users of applications. These users can be more or less involved in the development of applications. Let us take the assistedliving area as an example and consider caregivers as the end-user’s proxy. Building applications for the apartment of an impaired person involves at least a caregiver and the impaired person.
The caregiver is a domain expert of the assisted-living area. Also, he has a good knowledge of the needs of the person he is assisting.
Because they have an extensive knowledge of the end-user needs and the application area, caregivers are most qualiﬁed to propose solutions. Speciﬁcally, they can picture what kind of application could assist the end user to perform a given task based on his abilities and preferences.
This is particularly meaningful because the end user may not be able to directly express his needs .
Consequently, an end user, or his proxy, is the domain expert required to develop a home automation application.
3.2. Enabling a high-level description for orchestration Entity orchestration occurs in a variety of areas, ranging from robot control to game programming and service orchestration. In these ﬁelds, the ﬂow-based paradigm [14, 15, 16] as well as the rule-based paradigm [8, 17, 18, 19, 20] have been widely adopted and proved their usability. Our aim is to apply one of these well-established paradigms for the home automation area. Home automation devices are mainly composed of sensors and actuators, where actuators perform actions in reaction to sensed data. There is a direct correspondance between the sensor-controller-actuator paradigm and the rule-based paradigm: sensors represent context data deﬁning a condition; actuators represent actions triggered when this condition holds; and, a controller combines conditions and actuators to form a rule. In contrast to the ﬂow-based paradigm, rules represent elementary reactions to sensor detection; they represent small units of program that can be understood independently of each other, thus easing their visualization inside a window .