Towards an ambient data mediation system Kim Tâm Huynh Béatrice Finance Mokrane Bouzeghoub PRiSM Laboratory PRiSM Laboratory PRiSM Laboratory University of Versailles University of Versailles University of Versailles Saint-Quentin-en-Yvelines Saint-Quentin-en-Yvelines Saint-Quentin-en-Yvelines Versailles, France Versailles, France Versailles, France kth@prism.uvsq.fr beatrice@prism.uvsq.fr mok@prism.uvsq.fr that AmI can provide sophisticated support for everyday living, but the information capabilities it may use for this ABSTRACT purpose can also potentially provide an invisible and com- prehensive surveillance networks  walls literally can have In this paper, we address the problem of integrating many ears . It inevitably opens up issues of privacy risk, accep- heterogeneous and autonomous tiny data sources, available tance and security. in an ambient environment (AmI). Our goal is to facili- In many ambient environments, data arrives as streams tate the development of context-aware and personalized em- or as alerts/notications and is only relevant for a period of bedded applications on mobile devices. The originality of time; its interpretation depends on the user's context and the approach is the new ambient mediation architecture preferences. For instance, an information about a free park- which provides declarative and dynamic services, based on ing place can be relevant for a user if this information is rules/triggers. These services provide facilities to develop recent and if the parking place is nearby the user's location. and deploy ambient applications over devices such as smart- Another example is the heat setting to the right tempera- phones. This paper reports also on our rst experimental ture in the room where a given person is in and accordingly prototype, combining Arduino+Android. to his/her own comfort preferences. 1. INTRODUCTION In the database community, a lot of work has been devoted to eciently monitor huge amount of data streams coming Over the last 20 years there have been some signicant from sensors that continuously push their data to a xed progresses on the miniaturization of hardware components centralized system, without being concerned in privacy, mo- and wireless networks. The number and capabilities of mo- bility, context-awareness and reactivity. But as soon as a bile devices, wireless sensors and sensor networks open new sensor is linked to my personal life (e.g, my home location, research elds and applications. Terms such as the  Web of my traveling itinerary, etc), the applications using the cap- sensors , the  Internet of Things and  Ambient Intelligence tured data may become intrusive in my private life. More- (AmI) emphasize the trend towards a tighter connection over, in the opposite, as soon as I leave the smart environ- between the cyberspace and the physical world. ment, I may lose the ambient capabilities that may support Today, we are witnessing an unprecedent explosion of mo- my everyday life (e.g. tension and heart beat measurement, bile data volumes (i.e. ambient data). According to a study mandatory presence in a certain place). Consequently, the from ABI Research [1], in 2014 the volume of mobile data ambient environment and applications are considered as un- sent and received every month by users around the world desirable constraints in some cases and helpful tools in oth- will exceed by a signicant amount the total data trac for ers. Since my ambient environment is changing over the time all of 2008. In 2011, 1.08 billion of mobile phone users have a and over the space (e.g. at home, at work, at the hospital), Smartphone and in the near future they will be surrounded the query processing should adapt itself to these two dimen- by many sensors/actuators. sions. As Feng said [10] AmI imposes strong user-centric In his survey, Sadri [18] denes AmI as the vision of a context-awareness requirement on data management, but future in which the environments support the people inhab- also strong system requirements in terms of hardware con- iting them. For example, instead of using mice, screens and straints (i.e. energy consumption, wireless communication). keyboards, we may communicate directly with our clothes, As seen before, smartphones and the underlying applica- household devices,... The identied key features of AmI tions are, under some restrictions, good support for everyday are: embedment, intelligence, context-awareness, personal- life. However, their repetitive development from scratch is ization, adaptation and anticipation. It is also mentioned 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 de- velopment 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 : 13 • facilitates personalized and contextual integration and • The mediator can dynamically connect to the sources monitoring of heterogeneous data streams through con- when and as long as they are active (i.e. visible over tinuous query execution; the wireless network and ready to provide data). • enables applications to dynamically sense and control, • The mediator should provide, for each application, the according to some preferences, the ambient environ- capability to dene its data requirements in terms of ment of the user, which is changing over time and event types, so oering a concept of a virtual schema space; similarly to conventional mediators, and a mechanism • enables the user to keep some control over his personal which handles continuous queries. data as the monitoring is done exclusively on his per- • The mediator should be able to aggregate data ows sonal device. originated from the same source and integrate data In the remaining of this paper, Section 2 denes the re- ows originated from dierent sources on the basis quirements and the constraints imposed on the design of an of specic rules provided by the applications. As in ambient mediation system, and presents the architecture of conventional mediators, data heterogeneity should be CÄIMAN. In Section 3, the ambient mediation approach is transparent to the user, adaptors are aware of data described and illustrated through a scenario. In Section 4, transformation. we detail the main components of our system and report on our experimental prototype combining Arduino+Android. • The mediator should adapt itself to the user's con- Section 5 concludes with some open issues. text by continuously searching for the appropriate data sources. It should also satisfy user's preferences in 2. MOTIVATIONS terms of data delivery, relevance to domain of inter- To develop ambient applications, there is a need of an est, privacy, etc. ambient data mediation system (ADMS) which allows in- teroperability between a set of dynamic and loosely-coupled • The mediator should be aware of energy consump- tion and manage consequently the connections to the ambient data sources. An ambient data source is a (xed or sources and the usage of its resources. mobile) communicating object which generates or consumes continuous (or discontinuous) ows of data. Among such These requirements clearly distinguish an ambient mediator objects, we can distinguish a wide spectrum of sensors and from a conventional one [21] where the mediation schema mobile phones as well as any other data services which can and the sources are known in advance. Here the environment push specic data to the applications. In addition to these is dynamic as data sources enter and leave continuously the data sources, there exist other ambient objects called actu- eld of detection. The personalized and contextual integra- ators, that do not exchange data, but simply perform some tion and monitoring of heterogeneous data streams rely on actions on other objects. Notice that a single physical object continuous query evaluation. can play both the role of a data source and actuator. All ambient physical objects are abstracted by software services 2.2 Related work which encapsulate them and make visible their capabilities, In this section, we list the CAÏMAN main objectives and especially their data exchange protocol. compare them with existing related works. The design choices of our system have been motivated by The rst goal of CAÏMAN is to provide a high-level declar- the requirements of AmI applications in general, and mo- ative approach which permits user applications to interop- bile/ubiquitous users/equipments in particular; the key is- erate over distributed ambient objects. The expected data sue being the continuity of ambient services whatever the streams are relatively small in their length/size. Many for- dynamic changes are. In this section we review them and malisms for event streams processing and querying have compare our design choices with existing related work. The been proposed, see [9] for a good survey. In Data Stream proposed CAIMAN architecture is built on the basis of these Management Systems (DSMS) [4], many CQL-like query choices. languages which extend SQL have been dened. They are 2.1 The requirements based on the concept of window used to manage and lter data streams in a declarative way [5, 14, 8, 13]. In Com- An ambient information system (AmIS) is a set of data plex Event Processing (CEP), some formalisms based on ows provided by a collection of ambient objects to achieve composition operators (i.e. sequence, conjunction, disjunc- the needs of AmI applications (e.g. intelligent home, intel- tion,etc), or time-based automata are used. The goal of ligent city, health care, mobile social network, etc). Some CEP is to detect event patterns (i.e. situation) with tempo- AmIS objects can play the role of a mediator which is able to ral constraints in data streams. Today, the two approaches integrate and interpret data of many ambient data sources, are seen as complementary [9, 16]. Both approaches focus as well as to perform actions over their environment. Most on events detections but none on the events reactivity which of the AmIS data may persist only a few seconds or minutes is an important feature of AmI applications, e.g. the abil- in the system, unless the application or the user decides oth- ity to identify the context during which active behavior is erwise for various reasons. The main specic requirements relevant and the situations in which it is required. Both ap- imposed to the design of an ADMS are the following : proaches assume that the data (i.e. events) are continuously • Data sources are heterogenous. They may be xed pushed to a centralized system known in advance. These as- or mobile and arbitrarily connect and disconnect from sumptions do not t with our constraints, as the push mode the mediator, during variable intervals of time. Data consume a lot of energy. sources have dierent capacities in terms of storage In Sensor Databases such as TinyDB [15], data is acquired and computation. in a pull mode to avoid battery consumption. The query 14 (i.e. Tiny SQL) is sent through the network and evaluated in a distributed mode. Sensors are active only when they are queried. The advantages of this approach is its adapt- ability to the features of hardware devices and to their con- straints. The sensor network can contain a large number of sensors. However, the sensors are homogeneous, they all have a TinyOS and there is no mechanism of source discov- ery because the sensors are all known in advance. 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 inte- gration of context and preferences in queries is made in two ways [10]. The query pre-processing consists in enriching the query with context or preference informations before execut- ing it. The query post-processing ranks the query's answers according to these informations. Unfortunately, this mecha- Figure 1: CAÏMAN nism works only for one-time queries and not for continuous queries in which the notions of pre and post-processing do sors can only send data during a period of time xed by not exist. Indeed, in traditional DBMS, data are permanent the mediator, enabling the sensors and actuators to fall au- and queries are transient. In DSMS, data are transient and tomatically asleep when they have nished their duty and queries permanent as they are continuously evaluated over thus turn back to their default state. the transient data. To our knowledge, no solution has been As the mediator should t into lite clients such as smar- proposed to handle the context and the user preferences on phones and function in a complete autonomy, no system continuous queries. functionality is delegated to a central server. We don't rely In existing context-aware frameworks [6], the context man- on a global data source registry that might not be avail- ager is generally represented by a centralized server which able at all time. Meta-data exchange between AmIS objects is in charge of collecting context information, interpreting should be done instead at runtime and the context and pro- and providing them to the client applications. However in le managers should be local. pervasive environments, there are frequent disconnections CAÏMAN provides a declarative language which allows to and low connectivity, making this architecture not robust describe most of the system and application semantics which enough and adequate for this type of application. In the is based on the ECA (Event-Condition-Action) paradigm literature, only few systems [7, 11] have proposed a local used in active databases [17]. Thus, the rule processor is a context server to overcome this problem. However, in [11], core component of our system. It will be detailed in the next the context sources are known in advance and correspond section. Notice that in this paper our goal is not to propose to built-in sensors. Conversely in [7], the authors have de- yet another query language nor a complex context-aware veloped a sentient object model for ad-hoc mobile environ- model, but rather to select a subset of existing formalisms, ments where the context is only used to adapt the applica- keep them simple and tractable as much as possible to t tion behavior. It doesn't allow to enhance application data into lite clients. with contextual information. For instance, many applica- 3. THE AMBIENT MEDIATION APPROACH tions need to add the location to the data produced. In this section, we detail our mediation approach. First, we describe the dierent types of ambient sources on which 2.3 The CAÏMAN architecture the CAÏMAN is built on, then the virtual mediation schema The overview of the CAÏMAN architecture is depicted in is presented. To understand the approach, we illustrate it the Figure 1. The resource discovery component facilitates with a scenario. In this scenario, Paul is a student and objects discovery and handles dynamic connections and dis- lives at the university residence. He wants to benet of an connections to these objects. AmIS objects should be able intelligent home behavior, by automatically controlling the to rely on their own battery, so short-range wireless com- air conditioning of the room where he is located according munication such as Bluetooth are assumed in CAÏMAN as to his preferences. He also needs to organize his evenings these personal area networks are known to have a low con- and wants to be notied about interesting cultural events sumption of energy. Once, a data source is discovered the located not far from his current location. In order to do so, data collectors are responsible for acquiring the data. Data Paul will have to deploy two AmI applications which have sources do not push their data continuously, but rather spo- been specied in a declarative manner by some designers. radically in response to the mediator request. This requests During the deployment, the declarative description will be is done only if the data source can serve the needs of the ap- used to instantiate the virtual schema of the mediator, i.e. plications which have been deployed on top of the mediator. the application meta-data as described in the Figure 1. The originality of our ADMS is to oer an hybrid approach combining both the push and the pull modes. 3.1 The Ambient Sources In our environment, we assume that sensors/actuators re- Three types of data sources [12] are considered: (1) physi- main passive most of the time with a default behavior un- cal sources (e.g. GPS built-in sensors, smartphone, external less someone requests a service (i.e. light o, that can be temperature sensor such Arduino), (2) virtual sources (e.g. turned on). All sensors/actuators implement some generic user, agenda alerts, SMS, emails, contacts) and (3) logi- functions (e.g. services) and some that are optional. Sen- cal sources which combine physical and virtual sources with 15 information from databases. These sources can be either xed (e.g. already embedded in a mobile device where the mediator is), or dynamic (i.e., another smartphone, a sen- sor/actuator). Fixed ambient sources are known in advance and always connected to the mediator, e.g.built-in sensors. Dynamic ambient sources correspond to sources that ap- pear 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 Figure 3: Active Rules & their Execution Semantics behaves like any other sensor (intelligent sensor). For in- 2. chronicle: the oldest instances are considered and stance, the user is discovering a broken window and wants then discarded; i.e. events are consumed in a chrono- the mediation system to inform automatically the technical logical order. It is preferred when there is a causal sta in charge of repair. dependency between events. In the remaining of the paper, we focus more on the dy- namic data sources. Each one exports its capabilities (e.g., The granularity of processing denes whether the rule pro- metadata) in an XML document as depicted in the Figure cessor reacts after the detection of each event (instance- 2. Each dynamic source corresponds to a physical device oriented processing) or after a detection of a set of events characterized by an 'id', a 'type' (e.g., Arduino, Android) (set-oriented processing). An example of instance-oriented and a version number. processing is to call emergency after detecting a critical situ- ation like the unconsciousness of a person. In order to avoid a false alarm, we can wait for multiple events before call- ing 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. con- dition evaluation). The dierent options are: immediate, Figure 2: Sources Description deferred, or detached. CAÏMAN proposes immediate cou- pling modes. In our system, we do not consider cascading 3.2 A declarative approach execution because we assume that our actions have no side eect. The declarative approach used in CAÏMAN is ECA. ECA In our experimental prototype, only one semantics is im- rules are a generalization of several methods to achieve ac- plemented for the rule processor. Rules are evaluated in par- tive behavior, such as triggers and production rules. ECA allel and no cascading executions is allowed, but the event rules are evaluated in three steps: (1) when an occurrence consumption and the granularity of processing can be pa- of an event is detected, (2) the system evaluates the condi- rameterized. tion under which the event is considered relevant, and (3) if it is veried, the rule action is executed. The separation 3.3 The Ambient Mediation Schema between E-C-A is important for many reasons and has been The CAÏMAN mediation schema is composed of: (1) a emphasized by the active database community [17]. set of events types, corresponding to the data ows required When designing a mediator based on the ECA paradigm by ambient applications, and events detectors, (2) a context it is important to carefully take into account the life cycle of model and a default user prole, and (3) a set of personalized a rule and the dimensions related to its semantic execution. and contextual continuous queries (dened as ECA rules). Indeed this knowledge is mandatory for those designing an application. Moreover by separating the dimensions, there 3.3.1 Events & Event Detectors is more exibility, dierent behaviors can be proposed for An event type can be either simple (SE) or complex (CE). specic applications. In the Figure 3, we summarize them. A complex event type is a combination of other simple or Here we shortly explain some of the dimensions. The event complex events types. These event types are dened by the detection and composition and the visible DB states will be application designer. explained in the next section. Each event type (SE & CE) is dened by a set of at- There exist many modes of event consumption, among tributes: them we selected two modes more suitable to our environ- • name : name of the event type, ment: • lifespan: default time interval during which the event 1. recent: only the most recent instances of any event instance is valid, are considered; older events are discarded. It is most • aggrFunction : function which aggregates events to pro- suitable for fast-changing environments in which new duce a complex event. For simple events, there is no events supersede old ones. aggregation function. 16 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 pro- duced/observed by its source, • systemTime : moment when the event instance is de- tected by the mediation system, • lifespan: time interval during which the event instance is valid after its raisingDate, • raisingLocation: geo-location where an event instance Figure 4: Simple & complex event detectors is produced/observed by its source. mobile, he will not have time to establish proper con- The lifespan is a metadata which can be provided by the nections with all equipments around him. The other event source or assigned by the application. Event instances important aspect is the location. It can be expressed are relevant during a limited period of time. Pervasive en- in many ways depending on the application: GPS co- vironments can cause delays between the raising date of an ordinates, an address, or a locality label (e.g. Room event instance and the time for treating this instance. Con- 305B, Administration Building). The spatial informa- sequently the validity V of an event ei is dened by: tion can be provided by GPS built-in sensors or mobile networks or derived from Google Maps or databases. ( 1 if raisingDate(ei ) + lif espan(ei ) < currentT ime) V (ei ) = 2. The temporal dimension is an important information 0 otherwise that can be used for personalizing an application. For The raisingLocation is a useful notion for many location- instance, a user can be interested to receive events only aware applications. Indeed, the location can inuence the in the morning. Designers can change the notion of relevance of a given event instance. For example, an event moment in the core context, e.g. when the morning ood detected far away from a user can be irrelevant for begins and ends. This information can be provided him. by the phone clock (i.e. date, time) or derived from Once event types are dened, one should specify how and context denition (i.e. moment). when event instances are created or captured. This is done 3. The environmental dimension concerns all the sensors by specifying event detectors. Depending on the event type describing the environment of the user (e.g. temper- and on the target data source, an event detector may be ature, humidity, luminosity). This information is im- dened in various ways: a listener, a lookup function or any portant when the environment is xed, for example a other procedure able to transform a specic signal into a smart home. semantic event. For our scenario, the designers have separately dened 4. The equipment dimension characterizes all informa- three simple event types : UnvalidTemperature, UnvalidHu- tion about the media used by the user to interact with midity and Advertisement, with respectively a default lifes- the application: the used device (e.g. type, battery au- pan of 5 min, 5 min and 1 week, and one complex event tonomy, memory storage, computing power) and the type UncomfortableSituation with its associated aggregate connectivity (e.g. type of connection, rate). This di- function Foo as depicted in the Figure 4. For each event, mension is important to adapt dynamically the system the designer must dene a detector. Here, we only give the accordingly with the equipment constraints (e.g. low simple event detector DT on temperature expressed as a battery, uncertain connectivity). CQL query and the complex event detector US expressed 5. The user state dimension allows to know if a user is as a CEP-like manner. Others are omitted as they can be available or not, and how he feels. In our case, we are expressed in a similar way. more interested in the user availability which can have an impact on the system behavior. 3.3.2 Context Model According to [20], there exist six dierent models for rep- Designers have to provide the context model used by their resenting the context information. Some models like the application and the set of context rules to the mediator that ontology-based model is very expressive and allows power- can compute the current context. For that, a list of context ful context processing. However in CAÏMAN the model used models is proposed with default context rules. For example, is the simple key-value model as it should be embedded. if the application designer is interested in the location infor- Following our previous work [3], we dene a context by mation, there exists a rule associated with this dimension ve dimensions : spatial , temporal, environmental, equip- which captures the GPS coordinates from the smartphone ment and user state. GPS sensor every minute. However designers can also write their own context rules and submit them to the mediator. 1. The spatial dimension is an important characteristics of mobile and pervasive environments. Indeed, de- 3.3.3 Profile Model pending on how much the user is mobile, the system The survey [19] highlights the diculty of choosing the will react dierently. For instance, if a user is highly good representation for the user preferences: qualitative or 17 quantitative. The quantitative approach allows a total order actuators located in the same room where the user is cur- between preferences but is not intuitive because this implies rently located. Some variables have a default value set by that the user put weights on his preferences. While the the designer. If not, they will be lled by the user when qualitative approach is very intuitive but makes dicult the installing his application on his mobile device. For instance, usage because there is not necessarily a total order between the default temperature variables are ($1=18°, $2=22°) for preferences. In CAIMAN the user preferences considered are the day time and ($13=16°,$4=18°) for the night. In the viewed as dynamic criteria by the application. Thus there same manner, advertisements relevant to a user are those is no order between preferences as all preferences must be within $6='15km'. Others variables are set by the user. considered by the application. For instance, Paul decides to change the default value $6 to Following the denition given in [3], a user prole is or- 25km, and set the $$5 to (`music','sport'). ganized into several dimensions, possibly decomposed into sub-dimensions. Each dimension and its sub-dimensions 3.3.4 Application ECA Rules contain a set of attributes and their values on which prefer- The last task of the designer consists in dening his set of ences are expressed. We retain four important dimensions: ECA application rules. For example, let's consider the fol- 1. Personal data contains all information about the user lowing rules dened in the Figure 6 that model our scenarii. (e.g. his name, his address, his birthday). This dimen- As said before rules are contextual and personalized. Thus, sion may also contain data on social groups to which the context and the user prole can be either explicitly used the user belongs to (e.g. student, professor). by designers in their rules and in particular in the condition, or implicitly used by the system during the runtime when 2. Domain of interest is generally the central dimension specied within the user prole. of the user prole, it represents the user domain of in- The rst rule of the smart oce scenario explicitly uses the terest and preferences. For example, the domain of in- user prole and in particular the UserPref.Temperature.min terest may be the types of events the user is interested and UserPref.Temperature.max variables described above. in and the preferences on how/when event instances As these variables are context-dependent (i.e. day or night), are received or treated. their values are changing over time. So, they will be instan- tiated just before evaluating the rule condition. 3. Resource discovery contains the user preferences on In the second rule, a user receives advertisements. Here the remote resources (i.e. type of resource, associated no condition is specied; however one will be added by the data collectors, related security issues and all meta system at runtime since an implicit preference has been de- data useful to understand data stream semantics). An ned on this event type in the default prole. The reason example can be receiving events only from sources lo- why the condition is not directly written in the rule, is to cated in the same place as the user. allow the user to change his condition at any time. Here, 4. System adaptation groups user preferences on how the users receive advertisements relevant to their personal topics system should adapt to the user context or to its own and within the required distance. When an event is relevant behavioral parameters. An example can be to disable for the user, he is informed by email. the resource discovery component during the night. A set of preference rules can also be dened to adapt the system behavior in case of low battery, that is either disabling some functionalities or changing the frequency of the captured data. 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 Figure 6: Rule Examples into a global one, but in reality each application has its own. $name and $$name variables represent respectively a string Up to now, we have given some intuitions of our rule lan- or a set of strings. guage, 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 time- based window of size 1 and corresponds to the instance- oriented. Others windows are dened as in any continu- ous 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 Figure 5: User Prole that specify how to raise events. For each application, the designer has specied the re- Some generic actions are possible and are dened by a source discovery constraints. Indeed, to control the tem- template. The rst action inform($who,$how,$what) in- perature in a room, we are only interested by sensors and forms a user or a group of users, or an application through a 18 delivery mode (i.e. local, wireless, email, SMS), of a partic- a given location and at a given time, according to the pref- ular message or event. We separate messages from events, erences of the application or the user. Once the source is se- messages are generated to users and denitively leave the lected and a communication established, a dynamic binding system, by opposition to events that will be ltered and re- enables to link the data source to the mediator, by instan- injected later in a mediator that can interpret them. The tiating the suitable data collector. action activate($type, $service, $serviceparameters)  acti- vates a service with some parameters on a specic actuator 4.3 Profile & Context Manager type that satises some user preferences. As many context-aware systems [6], the mediation system proposed makes a separation between the context acquisi- tion, the context processing, and the context information 4. THE CAÏMAN MEDIATION SYSTEM usage. In fact, data collectors are in charge of retrieve con- text raw data, the context manager processes these data In this section, we briey describe the behavior of the to infer context information which will be stored and used main components of our system at runtime. Thus, we as- by applications and in particular application rules. These sume that AmI applications have been deployed on the smart- context information are also used by the prole manager to phone, and that their default prole, detectors and rules derive the active prole (i.e., all prole information which have been transmitted to the mediator and uploaded in the is valid for this current context). Indeed, the user prole application metadata database. is composed of a static part and a dynamic part. In the rst one, the prole information doesn't change frequently 4.1 Data Collectors & Actuator Commands while the second one depends on a context that can change As the data sources are heterogeneous, a set of generic rapidly. As we have seen in the Figure 5, the user prole can data collectors and actuator commands are needed to al- be contextual and it will be the role of the context and prole low communications with the mediation system. The Data managers to keep the active prole up to date for the ap- Collectors are used to collect and transform any kind of het- plication. For simplicity reasons, an assumption is made on erogeneous data so it can be understood and integrated in dening a contextual prole. Only If-then-else statements the mediator. Each source is bound with one instance of a are allowed in order to avoid conicts between contextual data collector that is responsible for querying and control- predicates. Only one active prole is valid at any instant of ling this data source. All communications are asynchronous. time. Notice also that all variables can be changed at any Another issue also considered is the data transformation as time by the user, via a simple interface on his smartphone. the data provided by a source is not necessarily compati- 4.4 Rule Processor ble to the coding, format, unit and scale of the expected The Rule Processor is an idempotent service to which data at the mediator level. The data collector is in charge ECA rules with their associated detectors are submitted. As of transforming these raw data into events, thus it activates said earlier, it is important to follow rule execution seman- the simple event detector associated with the source. tic as described in the Figure 3. The query processor relies Actuator Commands allows the mediator to transform on a multi-threaded execution framework. The approach we commands into real actions on the environment through ac- follow is, in a way, very similar to what has been proposed tuators services. by Krämer [14] and especially their SweepArea that models a dynamic data structure to manage a collection of events 4.2 Resource discovery & Bindings of the same type. ECA rules act as continuous queries over Due to the numerous communicating objects that enter collection of events and react over their environment when and leave the eld of detection because of the user mobility, a situation is encountered. there is a need of a Resource Discovery component which is As events of the same type can be used in many rules, continuously aware of the equipment's environment. events are not removed when used for triggering a rule. Ambient data sources may connect and disconnect arbi- Thus, a garbage collector is necessary and events are re- trarily. As the mediator cannot rely on a centralized re- moved from the dynamic structure when their lifespan has sources registry, the resource discovery service is dened as expired. In order to avoid triggering multiple times a rule a seeking function which detects the surrounding objects, with the same events, each rule has a context summarizing identies them through some metadata exchange and estab- the past execution. When the rule processor is looking for lishes connections to them if they are relevant at least for the rules that can be triggered, it uses the context which is one active application deployed on the mediator. also computed in a continuous way. Only the most recent As connections/disconnections can be frequent, the re- event is kept for each dimension. source discovery component stores a history of all the dis- covered sources with their version number. This version 4.5 The prototype number is useful to know if the source has changed since Smartphones as well as computers cannot really sense the the last time it was discovered. This is to avoid unnecessary world. For AmI environments, there is a need for tools for metadata exchanges. The history plays the role of a local making computers that can sense and control more of the resource registry which can be deleted at anytime, since it physical world than any other desktop computer. This is the can be rebuilt at runtime. role of the Arduino [2] platform to sense the environment by Before communicating with a data source, one should receiving input from a variety of sensors and to aect its sur- know if the information it contains is relevant. For doing roundings by controlling lights, motors, and other actuators. so, a matching is made between the source metadata and a A rst prototype combining Arduino and Android validating part of the mediation schema. At the same time the context the approach has been implemented. Many sensors and ac- and prole information is used to select only the sources in tuators have been prototyped. The CAÏMAN mediator and 19 many simple AmI applications can be deployed on an AN- [7] G. Biegel and V. Cahill. A framework for developing DROID platform. For the time being, data collectors and mobile, context-aware applications. In Proc. of the 2nd actuators are operational, as well as the resource discovery. IEEE Int. Conf on Perv. Comp. and Comm. Simple and complex event detectors, as well as simple ECA (PerCom'04), pages 361, Washington, USA, 2004. rules are supported. When the validity of events expires, the [8] I. Botan, R. Derakhshan, N. Dindar, L. Haas, R. J. garbage collector automatically deletes the events. We are Miller, and N. Tatbul. SECRET: a model for analysis currently integrating the context and the user prole within of the execution semantics of stream processing the rules. The user agrees or not to install an AmI applica- systems. Proc. VLDB Endow., 3(1-2):232243, Sept. tion on top of CAÏMAN. He can turn it on/o whenever he 2010. wants to. He can also checked the types and the number of [9] M. Eckert, F. Bry, S. Brodt, O. Poppe, and events, the mediator is currently monitoring. S. Hausmann. A CEP Babelsh: Languages for Complex Event Processing and Querying Surveyed. In 5. CONCLUSION S. Helmer, A. Poulovassilis, and F. Xhafa, editors, In this paper, we have presented the dierent require- Reasoning in Event-Based Distributed Systems, ments posed by ambient environments and proposed an am- volume 347 of Studies in Computational Intelligence, bient mediation system called CAÏMAN. As we have seen, pages 4770. Springer Berlin / Heidelberg, 2011. a declarative approach based on ECA rules is proposed. [10] L. Feng, P. P. M. Apers, and P. W. Jonker. Towards The main originality is that it combines in an elegant way context-aware data management for ambient the context, the user prole and the continuous queries to- intelligence. In 15th Int. Conf. on Database and gether. Some dimensions of the proles can be integrated Expert Systems Applications, pages 422431, 2004. and changed at anytime by the user. Another important [11] T. Hofer, W. Schwinger, M. Pichler, contribution of our work is that it is based on personal mo- G. Leonhartsberger, J. Altmann, and bile devices and local computation that better fulll the user W. Retschitzegger. Context-awareness on mobile privacy. To our knowledge CAIMAN is the rst ambient devices - the hydrogen approach. In Proc. of the 36th mediation system embedded in a smartphone oering such Annual Hawaii Int.Conf. on Syst. Sci. (HICSS'03), functionalities. pages 292.1, Washington, DC, USA, 2003. Some open issues still remain to be considered such as [12] J. Indulska and P. Sutton. Location management in how to adapt the system if the context is critical (i.e., low pervasive systems. In Proc. of the Australasian inf. battery), what to do when many mediators are acting in sec. workshop conf. on ACSW frontiers, pages a conicting way on specic resources, how an event that 143151, Darlinghurst, Australia, Australia, 2003. has been sent several times by dierent data sources can be [13] N. Jain, S. Mishra, A. Srinivasan, J. Gehrke, discovered to avoid repeating the same actions again and J. Widom, H. Balakrishnan, U. Çetintemel, again. M. Cherniack, R. Tibbetts, and S. Zdonik. Towards a Acknowledgment streaming SQL standard. Proc. VLDB Endow., 1(2):13791390, Aug. 2008. This work is partially funded by the French National Agency [14] J. Krämer and B. Seeger. Semantics and for Research (ANR) project under grant KISS (2011-INSe- implementation of continuous sliding window queries 005-03). over data streams. ACM Trans. Database Syst., 34(1):4:14:49, 2009. 6. REFERENCES [15] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and [1] ABI research. http://www.abiresearch.com/press/ W. Hong. TinyDB: an acquisitional query processing 1466-In+2014+Monthly+Mobile+Data+Traffic+Will+ system for sensor networks. ACM Trans. Database Exceed+2008+Total. Syst., 30(1):122173, 2005. [2] Arduino site. www.arduino.cc. [16] A. Margara and G. Cugola. Processing ows of information: from data stream to complex event [3] S. Abbar, M. Bouzeghoub, D. Kostadinov, S. Lopes, processing. In Proc. of the 5th ACM int. conf. on A. Aghasaryan, and S. Betge-Brezetz. A personalized Distributed event-based system, DEBS '11, pages access model: concepts and services for content 359360, New York, NY, USA, 2011. ACM. delivery platforms. In Proc. of the 10th Int. Conf. on Information Integration and Web-based Applications [17] N. W. Paton and O. Diaz. Active database systems. and Services., pages 4147, New York, USA, 2008. ACM Comput. Surv., 31(1):63103, 1999. [4] A. Arasu, B. Babcock, S. Babu, M. Datar, K. Ito, [18] F. Sadri. Ambient intelligence: A survey. ACM I. Nishizawa, J. Rosenstein, and J. Widom. STREAM: Comput. Surv., 43(4):36:136:66, Oct. 2011. the Stanford stream data manager (demo). In Proc. of [19] K. Stefanidis, G. Koutrika, and E. Pitoura. A survey the ACM SIGMOD Int. Conf. on Management of on representation, composition and application of data, pages 665665, New York, USA, 2003. preferences in database systems. ACM Trans. [5] A. Arasu, S. Babu, and J. Widom. The CQL Database Syst., 36(3):19, 2011. continuous query language: semantic foundations and [20] T. Strang and C. L. Popien. A context modeling query execution. The VLDB Journal, 15(2):121142, survey. In UbiComp 1st Int. Workshop on Advanced 2006. Context Modelling, Reasoning and Management, pages [6] M. Baldauf, S. Dustdar, and F. Rosenberg. A survey 3141, September 2004. on context-aware systems. Int. J. Ad Hoc Ubiquitous [21] G. Wiederhold. Mediation in information systems. Comput., 2(4):263277, 2007. ACM Comput. Surv., 27(2):265267, 1995. 20