xAAL: A Distributed Infrastructure for Heterogeneous Ambient Devices

2.1 Issues and Existing Solutions in AAL Systems

One of the main issues in home automation systems is the choice of a communication protocol. There are well known protocols (Z-Wave [34], KNX [20], EnOcean [13], etc.) and some of them are widely used; however, their interoperability is not well considered. Therefore, if someone wants to use a sensor using Z-Wave with an actuator using KNX, it is not feasible without a special gateway in charge of the interoperability between both protocols. In the past, it was not necessarily a big problem. Indeed, when a home automation system was installed, sensors/actuators using the same communication protocols were deployed.

The number of different protocols in home automation systems is the result of several factors. First of all, sensors and actuators do not have the same characteristics in terms of the following:

• Throughput and bandwidth – Usual central frequency: 433 MHz, 868/915 MHz (Eu/Usa), 2.4 GHz.

• Range – Wireless area network, body area network, etc. Devices handling Bluetooth or 802.15.4 do not have the same range.

• Problem of spectral occupancy, interference – Occurs especially in the ISM band at 2.4 GHz.

• Energy consumption – It is a critical topic that has a deep impact on the PHY and MAC layers. A lot of devices are battery powered, and it is not acceptable to change them every day, month, or year.

Those characteristics have a deep impact on the PHY and MAC layers. On the other hand, sensors and actuators are dependent on application domains. Indeed, for e-health (health care based on electronic communication means) and m-health (mobile health) applications, sensors will use WiFi or Bluetooth 4.0 because they are well deployed in smartphones. In the home automation domain, historical vendors have developed their own solution, e.g., X2D [11] (Delta Dore), to switch lights on and off, or to pull roller shutters up and down. Finally, the business model has a deep impact on the system architecture currently deployed in a house. The consumer is facing a captive market: few providers with solutions that cover every needs, with few chances to add equipment from others. That is why, the common architecture is composed by a network of sensors/actuators speaking the same proprietary protocol and a gateway gathering all the messages. The gateway also plays the role of manager with an administration interface and offers a connection with Internet to develop access via a mobile application.

Nowadays, new services appear, like actigraphy, e-health, preventive care, etc. Health and well-being applications are growing, and new devices are proposed on the market every month. They often use smartphones as access points to communicate first in Bluetooth or WiFi, then on Internet in 3G/4G or WiFi. Those new applications also need to use several data from different sensors using different communications protocols to quantify activity, sleeping quality, and environment to give a specialized feedback to the user in order to advice that person to have a healthy life. One of the ideas of preventive care, like in the PRECIOUS project [1], is to change user behavior or to advice the user to have a healthy life and reduce cardiovascular disease or type II diabetes. To achieve this goal, it appears that a model in charge of analyzing user behavior needs a lot of data from different sources like home sensors, social networks, physiological sensors, activity trackers (wearable devices), etc. In new AAL systems, it is necessary to have a seamless sensor/actuator layer to aggregate a huge quantity of data and to allow easy access to developers of new applications for AAL systems.

The main challenge is the interoperability between devices. Actually, there is a lack of standardization in the home automation systems. In the past 10 years, a lot of initiatives, alliances, or standards appeared, like ZigBee, EnOcean, or Z-Wave; however, they still do not promote interoperability with other alliances or standard. At the same time, the AAL domain has been developed in the research domain, and different solutions have been proposed about the interoperability between heterogeneous devices. The next section provides a short review of research and solutions proposed to solve the problem of interoperability between heterogeneous devices used at home.

2.2 Proposed Solutions for Home Automation Interoperability

As shown in the previous section, a transparent sensor/actuator layer is needed to propose more ambitious AAL systems. In the literature, we focused our attention on existing solutions in the domains of personal health system architectures, smart home/home automation architectures, smart home, and health system architectures; communications protocol related to the e-health/m-health domain; and communications protocol related to the smart home domain.

Existing solutions have been classified in three categories: protocol of communication, middleware, and architecture/framework. For those three categories, common mechanisms (or functionalities) are used to achieve interoperability. Indeed, most of the solutions have similar components or functionalities that are essential for a system including heterogeneous devices:

• Addressing is an essential functionality to send/receive information to/from devices. Several techniques can be employed, e.g., UUID, IP address, etc.

• Description gives information about the functions available on a device.

• Discovery mechanism gives information to the system about the available devices.

• Communication protocol is the way a device shares its functionality or information.

• Security and privacy are now a necessity to protect user information.

• Store/cache data are essential for sensors that are not queryable, or to verify the state.

Those criteria are used to classify solutions for each of the previous three categories.

2.3 Findings of the Survey

Solutions exist to address the interoperability issues. Almost all solutions play around the idea of a so-called gateway often implemented with middleware: a box (a small computer) is equipped with two or more modules, each module talking to a given home-automation protocol; then, a piece of software over those modules make it possible to forward messages between protocol A and protocol B. Moreover, those boxes embed additional functions to make all of these usable: HMI (via Web and/or smartphones), configuration facilities, connectors to extra services in the cloud, etc. Such solutions are partial from the interoperability point of view, as each box manages a limited number of low-level protocols, and boxes are hardly able to talk to each other.

There is also a key point about applications. Thanks to middleware approaches, those boxes are also designed to be the dedicated place to run applications. Boxes are not only the gateway for low-level physical devices, but they also act as a hub for applications and smart services. Everything that should cover all needs is in the same box: home automation, alarm, telemedicine, actigraphy, etc. Thus, the box provider should provide everything by itself, or should ask (beg) third parties to offer components for its box, based on strong specifications of means to plug such add-ons. Brønsted et al. [7] noticed that “with an approach using a central server, it is more difficult to obtain a balanced business relationship between market actors since one actor is likely gain dominance over the server.”

One should also consider sporadic devices. For instance, a newly connected TV may embed applications, which is an opportunity. A TV is not supposed to be mobile, but it may be on or off depending on the time of the day. Moreover, mobile devices such as smartphones or tablets are nowadays common. This may be interesting from the AAL point of view: they embed sensors relating to user activity, and they can run applications. However, such devices may enter or leave the system at any time. This poses questions about means to interconnect such mobile devices to the above-mentioned boxes.

Starting from those basements, we decided to reorganize and formalize the architectures of those boxes, which are in fact all composed of the same functionalities. Therefore, we propose to split functionalities into well-defined functional entities, communicating to each other via a message bus over IP. Each entity may have multiple instances, may be shared between several boxes, and may be physically located in any box. Thanks to the distributed architecture of the system, the xAAL solution can address interoperability. Each sensor’s family, each vendor, may peacefully provide its own xAAL box without revealing details of its technology.

3.1 Functional Architecture

Figure 1 shows the general functional architecture of the xAAL system.

Figure 1:

Functional Architecture of xAAL.

Native equipment: Some devices (sensors, actuators) can communicate natively using the xAAL protocol.

Gateways: In general, home automation devices only support their own proprietary communication protocol. Gateways translate messages between the manufacturer protocols and the xAAL protocol. This is the very classical function found in all other home box solutions. This part is very specific to manufacturers’ technologies. It may be the role of vendors to provide it by themselves. All other functions may be shared.

Schema repository: Home automation devices are described by a schema (the nature of the equipment, how to interact with it). These schemas are listed in one or more schema repositories that can be queried by other entities. Those repositories may be fed with specific schemas describing the vendor’s devices. Some usual schemas are generic.

Database of meta-data: Each automation device within a facility is likely to be associated with a piece of information: at least location information (e.g., declare that the equipment typed as a lamp and having address X is located in the kitchen) and possibly a symbolic name (e.g., device having address X is called “lamp#1”). This information is stored as a set of tags in one or more databases of meta-data. Those databases somehow contain the configuration of the home automation installed.

Cache: Some sensors can just send information in a sporadic way (e.g., a thermometer that sends the temperature data only if it changes). One or more caches store this information (with a timestamp) so that other entities can query them whenever necessary.

Automata of scenarios: Scenarios are advanced services like, for example, start a whole sequence of actions from a click of the user, or at scheduled times, or monitor sequences of events and then react, etc. To support it, one may have one or more entities of the type automata of scenarios. AAL services usually imply some actions to be triggered locally close to the user at home, and some other actions to be computed somewhere in the cloud. Automata of scenarios are dedicated to the former.

These automata of scenarios are also the right place to implement virtual devices: for example, a scenario could aggregate and correlate a variety of events from real devices, and then synthesizes information such as “presence” and notify it on the bus, in order to be used by other entities. By proceeding in this way, this scenario should appear by itself as a device on the bus, with its address and its schema. This scenario is a kind of a virtual device.

User interfaces: One or many user interfaces are provided by specific entities connected to the xAAL bus. This can be a real hardware device with a screen and buttons, or a software component that generates Web pages (for instance) to be used by a browser on a PC, a connected TV, or other devices; or software that provides a REST API for mobile applications (tablets, smartphones), to an external server on the cloud for advanced services, to an MQTT server, or to offer features for service composition, etc.

The typical workflow of an HMI could be as follows: (i) query the bus to be aware of the present devices; (ii) query the schema repository for the type of these devices, the type of data from the sensors/actuators, the possible actions, and URLs to retrieve icons; (iii) query the database of meta-data about devices to get the configuration of the installation (a friendly name to display, location, and other tags associated with each device); (iv) query the cache for the latest known states of such equipment; and, finally, (v) dynamically build display screens and control interfaces for these devices.

3.2 Devices and Schemas

Devices are identified by a unique address on the bus. This is a UUID (RFC 4122): the textual representation of a 128-bit random number. Address 0 is reserved for broadcast and refers to all devices. Device address may be assigned in the factory, or autogenerated (random) at installation time. However, it is recommended that this address remains persistent, e.g., after power breaks.

A device has a type, i.e., a schema name. This name is a string consisting of a pair of words separated by a dot. The first word refers to a class of device type (e.g., lamp, heating, multimedia, etc.). The second word refers to a specific type in a given class (e.g., within the lamp class, one may have lamp.basic, lamp.trigger, lamp.dimmer, etc.) The second word may also refer to a schema extension by a manufacturer. The identifier “any.any” is reserved and refers to all types of all classes.

The schema associated with a device provides semantics to a device and describes its capabilities: a list of possible methods on this device (mechanism of request-response), a list of notifications that it sends spontaneously, and a list of attributes (a device announces any change of values on the bus). Those schemas are inspired by the UPnP approach [29].

There is a notion of inheritance between schemas. A schema can extend an existing schema. We define the first three levels of this genealogy: (i) a generic schema common to all existing devices worldwide that everyone has to implement; (ii) a specific schema for every class (e.g., lamp, thermometer, switch, etc.) – such specific schemas thus inherit from the generic schema; and (iii) a specific schema for each type that inherits from a class schema, which indicates the level of functionality (e.g., a lamp type can be on/off, some are of a trigger type, and others with dimmer, etc.). Thereafter, manufacturers of home automation equipment will naturally define their own schemas among their product range that will inherit of schemas of level three.

3.3 Messages

Messages are transported by an IP multicast bus (IPv4 and/or IPv6). As proposed by UPnP [29], a bus allows the discovery: when a new component appears in the installation, it announces itself. All other entities can then take it into account. Similarly, when a new component enters, it can query the bus to discover the other components already present. This greatly facilitates the configuration and allows dynamicity. However, UPnP use the multicast bus only for discovery, not for transmission of data or control/command that therefore requires a large set of point-to-point TCP communications between UPnP devices (plenty of call-backs to get notifications).

We choose JSON [10] as the exchange format on the bus. Many libraries are available in many development environments. A message consists of a header and a body. The header is mandatory, while the body is optional. Figure 2 gives an example of xAAL messages. The header of a message includes the source and destination addresses of the message. A destination address of 0 means a broadcast message: everybody is invited to filter the relevance of the message based on the device type (name of the schema). Note that device type mentioned by the requester may contain the keyword “any” to widen the broadcast request. The body contains parameters and values for queries, responses, and notifications, if needed. The body is optional: it depends on what has been defined in the schema for the mentioned action.

Figure 2:

Example of xAAL messages.

In the above example, there is no encryption (cipher:none). One keeps the possibility of communicating without encryption. However, one may have cipher:md5 with the signature of the message with a shared key; to avoid replay attacks, a timestamp parameter is added in the message before signing.

3.4 Experiments

Nowadays, a prototype of the xAAL solution is developed in C and in Python. Both implementations [18] are proposed to the open-source community, which is very active on home automation solutions. In the meantime, several experiments were carried out in the form of student projects with the collaboration of some of our industrial partners (mostly small to medium enterprises and startups).

xAAL is deployed in our Experiment’HAAL living’lab. It can manage X2D, KNX, and Z-Wave devices: lights, shutters, door-opening sensors, heating, water flow sensors, pressure sensors, etc. Ad-hoc xAAL-native devices are prototyped using GrovePi hardware platform, which allows connecting Grove sensors/actuators with a Raspberry Pi [14, 24].

We drove experiments to interface a Nao robot (by Aldebaran Robotics [3]) to the xAAL bus of our living’lab. The robot acted like a remote control for the home automation system thanks to its voice recognition facility, and as an alerting device with its gestures and voice. For instance, the user says “Nao, morning scenario please!,” then Nao makes a gesture to the direction of the windows and says, “I raise shutters.,” while sending the corresponding xAAL query; then, it does the same to switch off the lights of the bedroom, switch on lights of the bathroom, etc. If the tap water remains open after the user leaves the bathroom, the xAAL system detects it and sends a dedicated notification to Nao that puts its hands on his head and says “Oups! I think the tap water is still open.” The idea is to bring a kind of presence near lonely people. The xAAL ecosystem eases developing such smart services.