In this paper, we address the problem of integrating many heterogeneous and autonomous tiny data sources, available in an ambient environment (AmI). Our goal is to facilitate the development of context-aware and personalized embedded applications on mobile devices. The originality of the approach is the new ambient mediation architecture which provides declarative and dynamic services, based on rules/triggers. These services provide facilities to develop and deploy ambient applications over devices such as smartphones. This paper reports also on our rst experimental prototype, combining Arduino+Android.
Over the last 20 years there have been some signicant progresses on the miniaturization of hardware components and wireless networks. The number and capabilities of mobile devices, wireless sensors and sensor networks open new research elds and applications. Terms such as the Web of sensors, the Internet of Things and Ambient Intelligence (AmI) emphasize the trend towards a tighter connection between the cyberspace and the physical world.
Today, we are witnessing an unprecedent explosion of
mobile data volumes (i.e. ambient data). According to a study
from ABI Research [
In his survey, Sadri [
In many ambient environments, data arrives as streams or as alerts/notications and is only relevant for a period of time; its interpretation depends on the user’s context and preferences. For instance, an information about a free parking place can be relevant for a user if this information is recent and if the parking place is nearby the user’s location. Another example is the heat setting to the right temperature in the room where a given person is in and accordingly to his/her own comfort preferences.
In the database community, a lot of work has been devoted
to eciently monitor huge amount of data streams coming
from sensors that continuously push their data to a xed
centralized system, without being concerned in privacy,
mobility, context-awareness and reactivity. But as soon as a
sensor is linked to my personal life (e.g, my home location,
my traveling itinerary, etc), the applications using the
captured data may become intrusive in my private life.
Moreover, in the opposite, as soon as I leave the smart
environment, I may lose the ambient capabilities that may support
my everyday life (e.g. tension and heart beat measurement,
mandatory presence in a certain place). Consequently, the
ambient environment and applications are considered as
undesirable constraints in some cases and helpful tools in
others. Since my ambient environment is changing over the time
and over the space (e.g. at home, at work, at the hospital),
the query processing should adapt itself to these two
dimensions. As Feng said [
As seen before, smartphones and the underlying applications are, under some restrictions, good support for everyday life. However, their repetitive development from scratch is time and money consuming, it makes the software evolution quite dicult, in particular because components updates are frequent. We claim that an embedded data management system for AmI may signicantly contribute to ease the development and maintenance of such applications.
The contribution of this paper is to propose an ambient mediation system (called CAIMAN for C ontext-aware dAta I ntegration and M anagement in Ambient eN vironments) which : • facilitates personalized and contextual integration and monitoring of heterogeneous data streams through continuous query execution; • enables applications to dynamically sense and control, according to some preferences, the ambient environment of the user, which is changing over time and space; • enables the user to keep some control over his personal data as the monitoring is done exclusively on his personal device.
In the remaining of this paper, Section 2 denes the requirements and the constraints imposed on the design of an ambient mediation system, and presents the architecture of C˜IMAN. In Section 3, the ambient mediation approach is described and illustrated through a scenario. In Section 4, we detail the main components of our system and report on our experimental prototype combining Arduino+Android. Section 5 concludes with some open issues. 2.
To develop ambient applications, there is a need of an ambient data mediation system (ADMS) which allows interoperability between a set of dynamic and loosely-coupled ambient data sources. An ambient data source is a (xed or mobile) communicating object which generates or consumes continuous (or discontinuous) ows of data. Among such objects, we can distinguish a wide spectrum of sensors and mobile phones as well as any other data services which can push specic data to the applications. In addition to these data sources, there exist other ambient objects called actuators, that do not exchange data, but simply perform some actions on other objects. Notice that a single physical object can play both the role of a data source and actuator. All ambient physical objects are abstracted by software services which encapsulate them and make visible their capabilities, especially their data exchange protocol.
The design choices of our system have been motivated by the requirements of AmI applications in general, and mobile/ubiquitous users/equipments in particular; the key issue being the continuity of ambient services whatever the dynamic changes are. In this section we review them and compare our design choices with existing related work. The proposed CAIMAN architecture is built on the basis of these choices. 2.1
An ambient information system (AmIS) is a set of data ows provided by a collection of ambient objects to achieve the needs of AmI applications (e.g. intelligent home, intelligent city, health care, mobile social network, etc). Some AmIS objects can play the role of a mediator which is able to integrate and interpret data of many ambient data sources, as well as to perform actions over their environment. Most of the AmIS data may persist only a few seconds or minutes in the system, unless the application or the user decides otherwise for various reasons. The main specic requirements imposed to the design of an ADMS are the following : • Data sources are heterogenous. They may be xed or mobile and arbitrarily connect and disconnect from the mediator, during variable intervals of time. Data sources have dierent capacities in terms of storage and computation. • The mediator can dynamically connect to the sources when and as long as they are active (i.e. visible over the wireless network and ready to provide data). • The mediator should provide, for each application, the capability to dene its data requirements in terms of event types, so oering a concept of a virtual schema similarly to conventional mediators, and a mechanism which handles continuous queries. • The mediator should be able to aggregate data ows originated from the same source and integrate data ows originated from dierent sources on the basis of specic rules provided by the applications. As in conventional mediators, data heterogeneity should be transparent to the user, adaptors are aware of data transformation. • The mediator should adapt itself to the user’s context by continuously searching for the appropriate data sources. It should also satisfy user’s preferences in terms of data delivery, relevance to domain of interest, privacy, etc. • The mediator should be aware of energy consumption and manage consequently the connections to the sources and the usage of its resources.
These requirements clearly distinguish an ambient mediator
from a conventional one [
In this section, we list the CAˇMAN main objectives and compare them with existing related works.
The rst goal of CAˇMAN is to provide a high-level
declarative approach which permits user applications to
interoperate over distributed ambient objects. The expected data
streams are relatively small in their length/size. Many
formalisms for event streams processing and querying have
been proposed, see [
In Sensor Databases such as TinyDB [
The second goal of CAˇMAN is to make the ADMS aware
of the user’s context and user’s preferences. Again, a lot
of work has been devoted to context and preference-aware
queries by the database community. Traditionally, the
integration of context and preferences in queries is made in two
ways [
In existing context-aware frameworks [
The overview of the CAˇMAN architecture is depicted in the Figure 1. The resource discovery component facilitates objects discovery and handles dynamic connections and disconnections to these objects. AmIS objects should be able to rely on their own battery, so short-range wireless communication such as Bluetooth are assumed in CAˇMAN as these personal area networks are known to have a low consumption of energy. Once, a data source is discovered the data collectors are responsible for acquiring the data. Data sources do not push their data continuously, but rather sporadically in response to the mediator request. This requests is done only if the data source can serve the needs of the applications which have been deployed on top of the mediator. The originality of our ADMS is to oer an hybrid approach combining both the push and the pull modes.
In our environment, we assume that sensors/actuators remain passive most of the time with a default behavior unless someone requests a service (i.e. light o, that can be turned on). All sensors/actuators implement some generic functions (e.g. services) and some that are optional. Sensors can only send data during a period of time xed by the mediator, enabling the sensors and actuators to fall automatically asleep when they have nished their duty and thus turn back to their default state.
As the mediator should t into lite clients such as smarphones and function in a complete autonomy, no system functionality is delegated to a central server. We don’t rely on a global data source registry that might not be available at all time. Meta-data exchange between AmIS objects should be done instead at runtime and the context and prole managers should be local.
CAˇMAN provides a declarative language which allows to
describe most of the system and application semantics which
is based on the ECA (Event-Condition-Action) paradigm
used in active databases [
In this section, we detail our mediation approach. First, we describe the dierent types of ambient sources on which the CAˇMAN is built on, then the virtual mediation schema is presented. To understand the approach, we illustrate it with a scenario. In this scenario, Paul is a student and lives at the university residence. He wants to benet of an intelligent home behavior, by automatically controlling the air conditioning of the room where he is located according to his preferences. He also needs to organize his evenings and wants to be notied about interesting cultural events located not far from his current location. In order to do so, Paul will have to deploy two AmI applications which have been specied in a declarative manner by some designers. During the deployment, the declarative description will be used to instantiate the virtual schema of the mediator, i.e. the application meta-data as described in the Figure 1. 3.1
Three types of data sources [
Dynamic ambient sources correspond to sources that appear and disappear to the mediation system over time due to the source mobility itself or due to the mobility of the user which embeds a mediator on his personal smartphone. If a smartphone is close to a mobile device, a communication can be established and some messages can be exchanged as long as the device is reachable. If suddenly it disappears due to the user mobility, some messages can be lost. Moreover, the user himself can be an ambient data producer as he/she behaves like any other sensor (intelligent sensor). For instance, the user is discovering a broken window and wants the mediation system to inform automatically the technical sta in charge of repair.
In the remaining of the paper, we focus more on the dynamic data sources. Each one exports its capabilities (e.g., metadata) in an XML document as depicted in the Figure 2. Each dynamic source corresponds to a physical device characterized by an ’id’, a ’type’ (e.g., Arduino, Android) and a version number.
The declarative approach used in CAˇMAN is ECA. ECA
rules are a generalization of several methods to achieve
active behavior, such as triggers and production rules. ECA
rules are evaluated in three steps: (1) when an occurrence
of an event is detected, (2) the system evaluates the
condition under which the event is considered relevant, and (3)
if it is veried, the rule action is executed. The separation
between E-C-A is important for many reasons and has been
emphasized by the active database community [
When designing a mediator based on the ECA paradigm it is important to carefully take into account the life cycle of a rule and the dimensions related to its semantic execution. Indeed this knowledge is mandatory for those designing an application. Moreover by separating the dimensions, there is more exibility, dierent behaviors can be proposed for specic applications. In the Figure 3, we summarize them. Here we shortly explain some of the dimensions. The event detection and composition and the visible DB states will be explained in the next section.
There exist many modes of event consumption, among them we selected two modes more suitable to our environment: 1. recent: only the most recent instances of any event are considered; older events are discarded. It is most suitable for fast-changing environments in which new events supersede old ones. 2. chronicle: the oldest instances are considered and then discarded; i.e. events are consumed in a chronological order. It is preferred when there is a causal dependency between events.
The granularity of processing denes whether the rule processor reacts after the detection of each event (instanceoriented processing) or after a detection of a set of events (set-oriented processing). An example of instance-oriented processing is to call emergency after detecting a critical situation like the unconsciousness of a person. In order to avoid a false alarm, we can wait for multiple events before calling the emergency. In CAˇMAN, this latter dimension can be oered by dening windows on the events arrival. The rule priorities determines how rules are selected among a conict set of rules (i.e. rules triggered by the same event). The EC and CA coupling modes indicates when condition (resp. action) is evaluated after event detection (resp. condition evaluation). The dierent options are: immediate, deferred, or detached. CAˇMAN proposes immediate coupling modes. In our system, we do not consider cascading execution because we assume that our actions have no side eect.
In our experimental prototype, only one semantics is implemented for the rule processor. Rules are evaluated in parallel and no cascading executions is allowed, but the event consumption and the granularity of processing can be parameterized. 3.3
The CAˇMAN mediation schema is composed of: (1) a set of events types, corresponding to the data ows required by ambient applications, and events detectors, (2) a context model and a default user prole, and (3) a set of personalized and contextual continuous queries (dened as ECA rules). 3.3.1
An event type can be either simple (SE) or complex (CE). A complex event type is a combination of other simple or complex events types. These event types are dened by the application designer.
Each event type (SE & CE) is dened by a set of attributes: • name: name of the event type, • lifespan: default time interval during which the event instance is valid, • aggrFunction : function which aggregates events to produce a complex event. For simple events, there is no aggregation function.
Each event type can be instantiated at runtime according to data ows arriving to the mediation system. These event instances (SE & CE) are dened by a set of attributes: • value : event instance value, • source : source name that captured the event instance, • raisingDate : moment when the event instance is produced/observed by its source, • systemTime : moment when the event instance is detected by the mediation system, • lifespan: time interval during which the event instance is valid after its raisingDate, • raisingLocation: geo-location where an event instance is produced/observed by its source.
The lifespan is a metadata which can be provided by the event source or assigned by the application. Event instances are relevant during a limited period of time. Pervasive environments can cause delays between the raising date of an event instance and the time for treating this instance. Consequently the validity V of an event ei is dened by: V (ei) = (1 if raisingDate(ei) + lifespan(ei) < currentT ime) 0 otherwise The raisingLocation is a useful notion for many locationaware applications. Indeed, the location can inuence the relevance of a given event instance. For example, an event ood detected far away from a user can be irrelevant for him.
Once event types are dened, one should specify how and when event instances are created or captured. This is done by specifying event detectors. Depending on the event type and on the target data source, an event detector may be dened in various ways: a listener, a lookup function or any other procedure able to transform a specic signal into a semantic event.
For our scenario, the designers have separately dened three simple event types : UnvalidTemperature, UnvalidHumidity and Advertisement, with respectively a default lifespan of 5 min, 5 min and 1 week, and one complex event type UncomfortableSituation with its associated aggregate function Foo as depicted in the Figure 4. For each event, the designer must dene a detector. Here, we only give the simple event detector DT on temperature expressed as a CQL query and the complex event detector US expressed as a CEP-like manner. Others are omitted as they can be expressed in a similar way. 3.3.2
According to [
Following our previous work [
1. The spatial dimension is an important characteristics of mobile and pervasive environments. Indeed, depending on how much the user is mobile, the system will react dierently. For instance, if a user is highly mobile, he will not have time to establish proper connections with all equipments around him. The other important aspect is the location. It can be expressed in many ways depending on the application: GPS coordinates, an address, or a locality label (e.g. Room 305B, Administration Building). The spatial information can be provided by GPS built-in sensors or mobile networks or derived from Google Maps or databases. 2. The temporal dimension is an important information that can be used for personalizing an application. For instance, a user can be interested to receive events only in the morning. Designers can change the notion of moment in the core context, e.g. when the morning begins and ends. This information can be provided by the phone clock (i.e. date, time) or derived from context denition (i.e. moment). 3. The environmental dimension concerns all the sensors describing the environment of the user (e.g. temperature, humidity, luminosity). This information is important when the environment is xed, for example a smart home. 4. The equipment dimension characterizes all information about the media used by the user to interact with the application: the used device (e.g. type, battery autonomy, memory storage, computing power) and the connectivity (e.g. type of connection, rate). This dimension is important to adapt dynamically the system accordingly with the equipment constraints (e.g. low battery, uncertain connectivity). 5. The user state dimension allows to know if a user is available or not, and how he feels. In our case, we are more interested in the user availability which can have an impact on the system behavior.
Designers have to provide the context model used by their application and the set of context rules to the mediator that can compute the current context. For that, a list of context models is proposed with default context rules. For example, if the application designer is interested in the location information, there exists a rule associated with this dimension which captures the GPS coordinates from the smartphone GPS sensor every minute. However designers can also write their own context rules and submit them to the mediator. 3.3.3
The survey [
Following the denition given in [
In the same way as the context, designers specify a default user prole for their application. The Figure 5 describes the application default prole set by the designers for our scenario. We have gathered the prole of each application into a global one, but in reality each application has its own. $name and $$name variables represent respectively a string or a set of strings. actuators located in the same room where the user is currently located. Some variables have a default value set by the designer. If not, they will be lled by the user when installing his application on his mobile device. For instance, the default temperature variables are ($1=18 , $2=22 ) for the day time and ($13=16 ,$4=18 ) for the night. In the same manner, advertisements relevant to a user are those within $6=’15km’. Others variables are set by the user. For instance, Paul decides to change the default value $6 to 25km, and set the $$5 to (‘music’,’sport’). 3.3.4
The last task of the designer consists in dening his set of ECA application rules. For example, let’s consider the following rules dened in the Figure 6 that model our scenarii. As said before rules are contextual and personalized. Thus, the context and the user prole can be either explicitly used by designers in their rules and in particular in the condition, or implicitly used by the system during the runtime when specied within the user prole.
The rst rule of the smart oce scenario explicitly uses the user prole and in particular the UserPref.Temperature.min and UserPref.Temperature.max variables described above. As these variables are context-dependent (i.e. day or night), their values are changing over time. So, they will be instantiated just before evaluating the rule condition.
In the second rule, a user receives advertisements. Here no condition is specied; however one will be added by the system at runtime since an implicit preference has been dened on this event type in the default prole. The reason why the condition is not directly written in the rule, is to allow the user to change his condition at any time. Here, users receive advertisements relevant to their personal topics and within the required distance. When an event is relevant for the user, he is informed by email.
Up to now, we have given some intuitions of our rule language, now the semantics of rules is briey described.
The granularity of processing (e.g. instance or set-oriented) is dened as a window. The default window [Now] is a timebased window of size 1 and corresponds to the instanceoriented. Others windows are dened as in any continuous query language and correspond to the set-oriented. For instance, range 5 min represents all events that appear within the last ve minutes. Notice that we do not allow unbounded windows. The visible state of conditions and actions is dened by the window and the event type. The event consumption mode is dened as a xed parameter of the mediator and is taken into account in event detectors that specify how to raise events.
Some generic actions are possible and are dened by a template. The rst action inform($who,$how,$what) informs a user or a group of users, or an application through a delivery mode (i.e. local, wireless, email, SMS), of a particular message or event. We separate messages from events, messages are generated to users and denitively leave the system, by opposition to events that will be ltered and reinjected later in a mediator that can interpret them. The action activate($type, $service, $serviceparameters) activates a service with some parameters on a specic actuator type that satises some user preferences.
In this section, we briey describe the behavior of the main components of our system at runtime. Thus, we assume that AmI applications have been deployed on the smartphone, and that their default prole, detectors and rules have been transmitted to the mediator and uploaded in the application metadata database. 4.1
As the data sources are heterogeneous, a set of generic data collectors and actuator commands are needed to allow communications with the mediation system. The Data Collectors are used to collect and transform any kind of heterogeneous data so it can be understood and integrated in the mediator. Each source is bound with one instance of a data collector that is responsible for querying and controlling this data source. All communications are asynchronous. Another issue also considered is the data transformation as the data provided by a source is not necessarily compatible to the coding, format, unit and scale of the expected data at the mediator level. The data collector is in charge of transforming these raw data into events, thus it activates the simple event detector associated with the source.
Actuator Commands allows the mediator to transform commands into real actions on the environment through actuators services. 4.2
Due to the numerous communicating objects that enter and leave the eld of detection because of the user mobility, there is a need of a Resource Discovery component which is continuously aware of the equipment’s environment.
Ambient data sources may connect and disconnect arbitrarily. As the mediator cannot rely on a centralized resources registry, the resource discovery service is dened as a seeking function which detects the surrounding objects, identies them through some metadata exchange and establishes connections to them if they are relevant at least for one active application deployed on the mediator.
As connections/disconnections can be frequent, the resource discovery component stores a history of all the discovered sources with their version number. This version number is useful to know if the source has changed since the last time it was discovered. This is to avoid unnecessary metadata exchanges. The history plays the role of a local resource registry which can be deleted at anytime, since it can be rebuilt at runtime.
Before communicating with a data source, one should know if the information it contains is relevant. For doing so, a matching is made between the source metadata and a part of the mediation schema. At the same time the context and prole information is used to select only the sources in a given location and at a given time, according to the preferences of the application or the user. Once the source is selected and a communication established, a dynamic binding enables to link the data source to the mediator, by instantiating the suitable data collector. 4.3
As many context-aware systems [
The Rule Processor is an idempotent service to which
ECA rules with their associated detectors are submitted. As
said earlier, it is important to follow rule execution
semantic as described in the Figure 3. The query processor relies
on a multi-threaded execution framework. The approach we
follow is, in a way, very similar to what has been proposed
by Krmer [
As events of the same type can be used in many rules, events are not removed when used for triggering a rule. Thus, a garbage collector is necessary and events are removed from the dynamic structure when their lifespan has expired. In order to avoid triggering multiple times a rule with the same events, each rule has a context summarizing the past execution. When the rule processor is looking for the rules that can be triggered, it uses the context which is also computed in a continuous way. Only the most recent event is kept for each dimension. 4.5
Smartphones as well as computers cannot really sense the
world. For AmI environments, there is a need for tools for
making computers that can sense and control more of the
physical world than any other desktop computer. This is the
role of the Arduino [
In this paper, we have presented the dierent requirements posed by ambient environments and proposed an ambient mediation system called CAˇMAN. As we have seen, a declarative approach based on ECA rules is proposed. The main originality is that it combines in an elegant way the context, the user prole and the continuous queries together. Some dimensions of the proles can be integrated and changed at anytime by the user. Another important contribution of our work is that it is based on personal mobile devices and local computation that better fulll the user privacy. To our knowledge CAIMAN is the rst ambient mediation system embedded in a smartphone oering such functionalities.
Some open issues still remain to be considered such as how to adapt the system if the context is critical (i.e., low battery), what to do when many mediators are acting in a conicting way on specic resources, how an event that has been sent several times by dierent data sources can be discovered to avoid repeating the same actions again and again.
Acknowledgment This work is partially funded by the French National Agency for Research (ANR) project under grant KISS (2011-INSe005-03).