Smart Services for Home Automation. Managing Concurrency and Failures: New Wine in Old Bottles ?

Smart Services for Home Automation.

Managing Concurrency and Failures: New Wine in Old Bottles ?

Roberto Baldoni Massimo Mecella Leonardo Querzoni

SAPIENZA Universit`a di Roma

Dipartimento di Informatica e Sistemistica A

R

Via Ariosto 25, 00185, Roma, Italy

{baldoni|mecella|querzoni}@dis.uniroma1.it

Abstract

Home automation represents a growing market in the industrialized world. Today’s systems are mainly based on ad hoc and proprietary solution, with little to no in- teroperability and smart integration. However, in a not so distant future, devices installed in our home will be able to smartly interact and integrate in order to of- fer complex services with rich functionalities. Realiz- ing this kind of integration push developers to increase the amount of abstraction within the software architec- ture. In this paper we give a high-level view of what are the inherent trade-offs that stem from this process of abstraction and suggest how they could be tackled in these complex home automation systems. More specifi- cally we focus our analysis on two problems: concurrent execultion of multiple plans and failure detection.

Keywords: smart homes, domotics, concurrency, relia- bility

1. Introduction

Embedded systems are specialized computers used in larger systems or machines to control equipment such as automobiles, home appliances, communication, con- trol and office machines. Their growing pervasiveness is particularly evident in immersive realities, i.e., scenar- ios in which invisible embedded systems need to con- tinuously interact with human users, in order to provide continuous sensed information and to react to service re- quests from the users themselves. Examples are digi- tal libraries and eTourism, automotive, next generation buildings and domotics.

The work is partly supported through the FP7-224332SM4ALLproject.

Sensors/devices/appliances/actuators offering ser- vices are no more static, as in classical networks, (e.g., for environmental monitoring and management or surveillance), but they form an overall distributed sys- tem that needs to continuously adapt on the basis of the user context, habits, etc. That can be done by adding, removing and composing on-the-fly basic elements that are the offered services. Moreover, in order to really immerse the users in the system, the number of sen- sors/devices/appliances/actuators is becoming huge, at least an order of magnitude more than the current situa- tions.

This paper intends to present some in- sights stemming from the European-funded project SM4ALL (Smart hoMes for All - http://www.sm4all-project.eu), started on September 1st, 2008 and finishing on August 31st, 2011. SM4ALLaims at studying and developing an in- novative platform for software smart embedded services in immersive environments, based on a service-oriented approach and composition techniques. This is applied to the challenging scenario of private home and building in presence of users with different abilities and needs (e.g., young, elderly or disabled people).

In order to introduce the novel idea of services under- lyingSM4ALL, the reader should consider the following scenario: a person is at home and decides to take a bath.

He/she would like to simply express this to the house and have the available services collaborate in order to move the house itself to a new state which represents the desired one. The temperature in the bathroom is raised through the heating service, the guardrobe in the sleep- ing room is opened in order to offer the bathrobe, the bath is filled in with 37^oC water, etc. If we suppose the person is a disabled one, some services cannot be di- rectly automated, e.g., the one of helping the person to move into the bath. In this case, a service still exists, but 978-1-4244-9142-1/10/$26.00©2010 IEEE

it is offered by a human, e.g., the nurse, which is doing her job in another room, and that at the right moment is notified – through her PDA or any other device – to go into the bath and help the patient. Maybe this service is offered also by the son of the patient (or any other per- son), living in a nearby house, which is notified at the right moment, and if the nurse is not present at home, to help the patient. The scenario shows the idea of a sys- tem of services, some offered in a completely automated way through sensors/appliances/actuators, other realized through the collaboration of other persons, which moves continuously from a desired state to a new one, in order to satisfy user goals. Clearly, as in all complex systems, there are trade-offs to be considered (the goal of the per- son willing a relaxing bath is in contrast with the avail- ability of the nurse/son offering the “help” service).

Systems like SM4ALL require designers and devel- opers to raise the level of abstraction of the offered ser- vices, in order to be able to compose them in a smart and dynamic way; this, in turn, raises new challenges in terms of concurrent execution of different plans (i.e., complex actions that include the access to several re- sources in a house) and failure management within the system; luckily the redundancy inherent in the huge number of services may help in some case. In this paper we give the reader a first glimpse of how these problems impact the whole system and provide possible sugges- tions and intuitions on how to solve these new problems.

The rest of the paper is organized as follows: Section 2 provides a background on the current state of the art for home automation systems, Section 3 gives the reader an overview of theSM4ALLsystem architecture, Section 4 introduces the difficulties in coping with concurrency management and failure detection within these systems and, finally, Section 5 concludes the paper.

2. Relevant Work

Presently, we are assisting at a blooming of research projects on the use of smart services at home and do- motics, in particular for assisting people with physical or mental disabilities.

For instance, at Georgia Tech a domotic home has been built for the elder adult with the goals of com- pensating physical decline, memory loss and support- ing communication with relatives [10]. This work also considers issues of acceptability of domotics identifying key issues for the adoption of the technology by the end user. Acceptability, dangers and opportunities are also surveyed in [11]. Having a reliable system is a primary concern for all users.

At Carnegie Mellon people’s behavior is studied by automatic analysis of video images [6]. This is funda-

services WSDL-based

interface UPnP interface

Service Repository

Publish of rich service descriptions Context

Manager

Publish of status information (values of variables, service status, …)

Composition

Engine Composite

Service Off-line synthesis On-line

Goal

Figure 1. The SM4ALLarchitecture

mental in detecting anomalies and pathologies in a nurs- ing home where many patients live. Pervading the en- vironment with active landmarks, called Cyber Crumbs, aims at guiding the blind by equipping him/her with a smart badge [12]. A number of projects to give vir- tual companion’s to people, to monitor people’s health and behavioral patterns, to help Alzheimer patients are presented in [8]. The Gator Tech Smart House [7] is a programmable approach to smart homes targeting the elder citizen. The idea is to have a service layer based on OGSi [13] in order to enable service discovery and composition.

To the best of our knowledge, none of the previously cited projects and solutions directly addresses the two main problems we discuss within this paper, i.e. con- currency and failures management. This is also a conse- quence of the goals of such projects, which do not target directly the interaction with multiple users at the same time and that rely on lower level technologies to solve failure detection and management issues.

3. The SM4All Architecture

Figure 1 shows the SM4ALL architecture. Devices and sensors available in the house constitute the basis of theSM4ALLsystem. There is an ever increasing vari- ety of devices, for example for controlling parts of the home (doors, lights), or media devices, etc. Sensors are devices for measuring physical quantities, ranging from

simple thermometers to self-calibrating satellite-carried radiometers. Sensors and devices have an inherent con- nection, e.g., a device for opening the window blinds can change the luminosity value sensed by a sensor. Both sensors and devices make their functionalities available according to the service oriented paradigm. In particu- lar, services (offered by sensors and devices) are offered as SOAP-based services, both in the UPnP technology and in the WSDL-based one. A Pervasive Controller is in charge, when a new sensor/device joins the system, to dynamically load and deploy the appropriate service wrapping it, and to register all the relevant information into the Service Repository. Each service, in order to be dynamically configurable and composable, exposes rich service descriptions, comprising (i) interface specifica- tions, (ii) specifications of the externally visible behav- iors, (iii) offered QoS. As previously introduced, human actors in the environment are also abstracted as services, and actually “wrapped” with a rich description (e.g., a nurse offering medical services). This allows including them in a service composition and having them collab- orate with devices and sensors to reach a certain goal.

Such rich service descriptions are stored in the Service Repository, in order to be queried and retrieved by the other components of the architecture. During their op- eration, services continuously change their status, both in terms of values of sensed/actuating variables (e.g., a service wrapping a temperature sensor report the cur- rent sensed temperature, a service wrapping windows blinds report whether the blinds are open, closed, half- way, etc.) and in terms of conversational state of the service itself. All these status information are available, through a publish&subscribe mechanism, in the Context Manager.

On the basis of the rich service descriptions, a Com- position Engine is in charge of providing complex ser- vices by suitably composing available ones. The en- gine can work in two different ways: (i) off-line and (ii) on-line. In the off-line mode, at design/deployment time of the house, a desiderata (i.e., not really exist- ing) target service is defined, and the composition en- gine (through its synthesis subcomponent) synthesizes a suitable orchestration of the available services realiz- ing the target one. Such an orchestration specification is used at execution-time (i.e., when the user chooses to invoke the composite/desiderata service) by the orches- tration subcomponent in order to coordinate the avail- able services (i.e., to interact with the user on one hand and to schedule service invocations on the other hand).

In this mode, the orchestration specification is synthe- sized off-line (i.e., not during user requests) and exe- cuted on-line as if it were a real service of the home.

The off-line mode is technically based on the so-called

Roman approach to automatic service composition [4].

Conversely in the on-line mode, the user, during its in- teraction with the home, may decide not to invoke a spe- cific service (either available/real or composite one), but to ask the home to realize a goal; in such a case, the composition engine, on the basis of specific planning techniques [9], synthesizes and executes available ser- vice invocations in order to reach such a goal.

The user is able to interact with the home through dif- ferent kinds of user interfaces, either centralized (e.g., in a home control station accessible through a touchscreen in the living room) or distributed and embedded in spe- cific interface devices. Specifically, Brain Computer In- terfaces (BCIs) allow also people with disabilities to in- teract with the system.

4. The Impact of Abstraction

In a system like SM4ALL, strong abstraction layers must be introduced in the controlling software. This is mandatory in order to cope with the amount of complex- ity that the organization of composition tasks requires.

Devices are no more accessed at the low level, but are wrapped in software components that, like sort of prox- ies, offer their capabilities as services. These services can then be accessed, configured, and executed with- out knowing the low-level technological details that are automatically handled by the proxy. Exposing device capabilities as services is the first step needed to orga- nize, compose and orchestrate simpler services in order to expose to users more high-level functionalities whose complex execution is completely hidden and managed automatically by the system.

These design guidelines are clearly represented in the

SM4ALL architecture previously described. The user interacts with the system by issuing requests (complex services, high level goals) that do not necessarily take into account the specific technological devices that are present in the house. The system synthesizes execu- tion plans/orchestrations that are based on available ser- vices and on the current status of the system. Such plans/orchestrations are then executed and the corre- sponding services invoked. When a service is invoked the corresponding proxy will translate this invocation in low level commands for its attached device. It is the in- troduction of these several levels of software abstraction that let the user interact in a simpler way with the sys- tem, without knowing the details of how his request will be fulfilled.

However, abstraction creates several barriers between the final user and the devices. These barriers, while fa- voring the realization of complex functionalities, have an impact on two fundamental non-functional aspects of

these applications: concurrency management and failure detection, as further discussed in the following.

4.1. Concurrency Management

Systems likeSM4ALLare meant to be part of the en- vironment where humans live, and are thus designed to allow interaction with multiple users at the same time.

Moreover, the actions users can fulfill with these sys- tems can be both limited in time or last for several tenths of minutes (e.g., the preparation of the bath discussed in the Section 1).

As a consequence, several actions involving different devices can be in execution at the same time and this can easily lead to concurrency issues. As an example, suppose that Alice wants to bake a cake and this requires four eggs from the fridge. At the same time Bob wants to prepare fresh pasta that requires two eggs. However, the fridge currently contains a total of five eggs. There is clearly a contention among a set of limited resources (the eggs) that are needed to fulfill some goals.

Managing the concurrent access to shared resources is a well-known problem with several applications in many fields (operating systems, databases, etc.). How- ever, the home automation scenario gives a new twist to this problem and make existing solutions hard to use or adapt, thus creating the need for further research in this area. In our example, we have a set of processes (i.e., the execution plans synthesized after goals have been expressed) that compete to access a limited set of re- sources (the eggs of our example but, more in general, the resources in the house). The system should control the execution of concurrent plans in order to avoid pos- sible deadlocks (two or more plans cannot complete be- cause each of them needs resources currently assigned to the other one) or starvation issues (one plan cannot be executed because the resources it needs are always assigned to some other plan).

This problem has obvious similarities to the manage- ment of concurrent transactions in databases [3], where rows pertaining to several tables of a database must be updated with an all-or-none semantic, while multiple operations tries to access them. However, differently from that case, the execution of a plan cannot always be considered like a single transaction: complex plans can be, in fact, subdivided in sequential simpler groups of actions; operations pertaining to single groups must be executed atomically, but once a group of actions has been executed, the resources required till then can be freed. Other similarities can be found with the din- ing philosophers problem [5]: several philosophers are sitting at a round table waiting to eat; there is a fork between any two philosophers, but every philosopher

needs to grab two forks in order to eat and he can only grab the forks at its immediate left and right. If no syn- chronization strategy is provided, the philosophers can easily end in a deadlock where each of them has a single fork in his hands and waits forever for the second one.

This abstract problem partially describes our scenario.

However, different goals expressed by users in our sys- tem can try to access different sets of resources with different characteristics. Differently from the forks in the dining philosophers problem, some resources in the house could possibly allow a single utilization and pos- sibly be available again after a long time (e.g., the eggs are no more available after the “bake a cake” plan has been executed; they will be available again in the fridge only after a new set has been bought). While the din- ing philosopher problem tries to explain how resources should be mapped to processes, the opposite point of view has been studied in the driving philosophers prob- lem [2]. In this case several philosophers driving cars want to access a roundabout in a concurrent way; each section of the roundabout can be occupied only by a sin- gle philosopher, and each philosopher can only see if the section in front of him and the one behind him are free.

Also in this case deadlock and starvation problems can arise. However, differently from the home automation scenario, all the philosophers are required to access the resources in a specific order, while we can have two dif- ferent plans requiring exactly the same set of resources that can be requested in completely different orders.

Building a system that guarantees the correct use of shared resources to concurrent users while striving to maximize the concurrency level is thus a complex task.

The solution to this problem necessarily passes through a formal modeling of available resources, how processes (i.e., the execution of plans) are assumed to behave with respect to resource accesses, and which correctness properties must be met (mutual exclusion, fairness, etc.) by the system. Only after this formalization is available, it will be possible to start defining efficient scheduling algorithms that will let multiple goals to coordinate their actions in a concurrent way while guaranteeing system correctness.

It is important to remark that in a home automation environment this modeling of resources and processes have to consider important aspects not present in other contexts such as database concurrency control, dining or driving philosophers. Exogenous factors may impact indeed the available resources by changing their state even if these have already been associated to a plan ex- ecution (think about an automated window that is man- ually opened by a human even if the system was trying to control it). Also the number of available resources of a certain type (e.g. eggs in the fridge) can either in-

crease or decrease due to external factors. Intuitively, the fact that either the status or the number of a resource can change even if this has been locked by the system, means that scheduling algorithms have to be flexible in order to adapt at run-time in order to push performance to their maximum while guaranteeing system correctness.

The system must thus be provided with mechanisms to actively control the status of the resources in order to track possible unexpected changes and possibly abort or act through remedial actions on affected ongoing execu- tions.

4.2. Failure Management

An environment like SM4ALL can contains several heterogeneous devices that we can roughly categorize as sources of data (sensors, input devices, etc.) or actua- tors. An actuator is any device that can induce a change in the physical world when a software command is is- sued on it; this category includes a wide range of very heterogeneous devices: from very simple objects (like a lamp) attached to a controller, to complex intelligent ap- pliances (like an advanced media server). These devices can fail and this can cause errors in the system that is controlling them [1].

Proxy Light bulb

Sensor

Proxy

Internal state Failure

detetcion

Figure 2. Failure detection scenario.

The ability of such devices to auto-detect their fail- ures may vary. As an example (see Figure 2), the reader should suppose that the house contains a plain old lamp that is connected to the system through a switch that can be controlled via software. The system commands the controller to switch on the lamp but nothing happens. Is it possible to detect where a failure actually happened ? If the switch is really simple in its nature it could have no mean to detect if the lamp is working properly or the bulb blew out. In this case the switch could erro- neously report to the controlling software that the op- eration was executed successfully and the failure could remain unsignaled. More advanced controllers might

monitor the amount of current flowing in the wire to understand if the bulb is correctly working. Generally speaking, current automated devices can expose vari- ous levels of self-inspection capabilities that range from full-fledged malfunctioning diagnosis (quite common in modern TV sets) to no diagnosis at all.

This allows us to underline a common problem of complex software architectures: sometimes the internal state maintained by the system diverges from the state of the physical world. This latent error represents an inconsistency that could possibly give rise to critical er- rors as the system would act in in the real world without knowing its real state.

Correctly detecting these errors is a difficult task, but the presence of deployed sensing devices can sometimes help. Going back to the previous example, imagine that a light sensor is placed in the same room where the lamp is. After issuing the command to turn on the lamp the system will end in an internal state characterized by a correctly functioning ligth bulb (because this is what the controller erroneously reported) and a correctly func- tioning light sensor detecting no change in light inten- sity. Clearly, this information is enough to detect the presence of an inconsistency. This presence can be au- tomatically detected by the system through the use of rules that encode conditions that characterize inconsis- tent states. In our example a rule could simply state that any internal state characterized by “light is on” and

“light intensity is very low” is inconsistent and conse- quently raise a software alarm. Rule checking can be enforced by means of software components implement- ing the Event-Condition-Action pattern.

Once an inconsistent state is detected by the system, actions should be performed to identify the problem that caused it. Referring to our example, the system should understand if the light bulb blew out or the sensor is mal- functioning. The identification of the correct cause of the problem could lead the system to a new consistent state where information about the malfunctioning device is correctly present. Breaking the symmetry between the devices could be realized either in a manual way through human intervention or automatically by leverag- ing information coming from other devices in the envi- ronments. The system could be configured with a set of tests to be executed when the malfunctioning of a device is suspected; these tests should be executed by involving several distinct devices in order to build a convincing proof that a specific device is faulty or not. Through these test the system could try to assign diverse proba- bilities in order to isolate broken devices. Assume, for example that a second light sensor is present in the same room where the lamp and the first sensor are located. A test for the correct functioning of the lamp could con-

sist in checking the current status of all the light sensors in the same room where the lamp is, in order to calcu- late a probability that the lamp is correctly working. If two (or more) sensors report that there is no light in the room then the system can infer that with high probabil- ity the lamp blew out. Note that there is no way to have this probability reach 100%, because all the devices in the system can possibly fail, therefore there is always a non-zero probability that all the devices involved in a test are faulty and their return values by chance collude and make the system erroneously think that the tested devices is malfunctioning.

5. Conclusions

In the near future we will witness the born of a new generation of home automation systems characterized by the ability to seamlessly integrate heterogeneous de- vices and to offer complex functionalities. These sys- tems will internally resort to several abstraction layers, needed to simplify the management of a huge amount of devices, protocols, etc. TheSM4ALLarchitecture intro- duced in Section 3 is an example of a supporting infras- tructure for these new home automation systems where software abstraction plays a fundamental role.

However, abstracting from the specific characteristics of the devices, while increasing the possibilities of inte- grating them in a coherent software architecture, makes it more difficult to adequately cope with some non- functional aspects like concurrency management and failure detection.

Concurrency issues arise as a straightforward conse- quence of the fact that the environment where the system is immersed and the system itself are the target of mul- tiple user inputs. Different users can issue commands that require the system to fulfill inherently incoherent goals. The lack of adequate formalizations of concur- rency issues in this specific scenario, makes it difficult to system designers to deal with it. A research effort on this line would possibly lead to the definition of novel efficient algorithms that could increase the amount of concurrency in the system while preserving its correct- ness.

From the reliability point of view, it is possible to design and configure systems that leverage all their ca- pabilities (in terms of available information on the envi- ronment status) to (i) detect inconsistencies between the real world and its representation in the software compo- nents and (ii) try to pursue the cause of these inconsis- tencies by identifying the malfunctioning devices. How- ever, it should be always taken into account that no tech- nique can guarantee that every malfunction scenario is correctly identified; in the end, it is the final user him-

self the only certain interconnection between the system and the environment. A thorough effort on this point could lead to a coherent vision about which kind of fail- ures can actually be detected in these environments and which can not.

In summary, the evolution of home automation sys- tems still present some open problems that need to be investigated in order to pave the way for a new genera- tion of products. In this paper we gave the reader a short overview on two such problems: concurrency manage- ment and failures detection. This leaves space for an exciting research agenda in this area.

References

[1] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr.

Basic concepts and taxonomy of dependable and secure computing. Dependable and Secure Computing, IEEE Transactions on, 1(1):11 – 33, 2004.

[2] S. Baehni, R. Baldoni, R. Guerraoui, and B. Pochon.

The driving philosophers. In Exploring New Frontiers of Theoretical Informatics, pages 181–194. Springer Boston, 2004.

[3] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Con- currency Control and Recovery in Database Systems.

Addison-Wesley, 1987.

[4] D. Calvanese, G. De Giacomo, M. Lenzerini, M. Me- cella, and F. Patrizi. Automatic Service Composition and Synthesis: the Roman Model. IEEE Data Eng. Bull., 31(3):18–22, 2008.

[5] E. W. Dijkstra. Hierarchical ordering of sequential pro- cesses. Acta Inf., 1:115–138, 1971.

[6] A. Hauptmann, J. Gao, R. Yan, Y. Qi, J. Yang, and H. Wactlar. Automatic analysis of nursing home obser- vations. IEEE Pervasive Computing, 3(2):15–21, 2004.

[7] S. Helal, W. C. Mann, H. El-Zabadani, J. King, Y. Kad- doura, and E. Jansen. The gator tech smart house: A pro- grammable pervasive space. IEEE Computer, 38(3):50–

60, 2005.

[8] A. Joseph. Successful aging. IEEE Pervasive Comput- ing, 3(2):36–41, 2004.

[9] E. Kaldeli, A. Lazovik, and M. Aiello. Extended Goals for Composing Services. In Proc. 19th Interna- tional Conference on Automated Planning and Schedul- ing (ICAPS 2009), 2009.

[10] E. Mynatt, A. Melenhorst, A. Fisk, and W. Rogers. Un- derstanding user needs and attitudes. IEEE Pervasive Computing, 3(2):36–41, 2004.

[11] J. Roberts. Pervasive health management and health management utilizing pervasive technologies : Synergy and issues. The Journal of Universal Computer Science, 12(1):6–14, 2006.

[12] D. Ross. Cyber crumbs for successful aging with vision loss. IEEE Pervasive Computing, 3(2):30–35, 2004.

[13] S. Tuecke, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, D. Snelling, and P. Vanderbilt.

Open service grid infrastructure, 2003.