R Buttin

F Zara

B Shariat

T Redarce

A Biomechanical Model of the Female Reproductive System and the Fetus for the realization of a Childbirth Virtual Simulator

Our main work consists in modeling of the female pelvis and uterus, as well as the human fetus. The goal of this work is to recover the different forces generated during the delivery. These forces will be input to the haptic obstetric training tool BirthSim which has already been developed by the Ampère Laboratory at the INSA of Lyon. This modeling process will permit us to develop a new training device to take into account different anatomies and different types of delivery.

In this paper, we will firstly show the different existing haptic and virtual simulators in the obstetric world with their advantages and drawbacks. After, we will present our approach based on a biomechanical modeling of concerned organs. To obtain interactive time performance, we proceed by the simplification of the organs anatomy. Then, we present some results showing that FEM analysis can be used to model forces during childbirth. In the future, we plan to use this work to more accurately control a childbirth simulator.

I. INTRODUCTION

Generally, residents learn medical gesture by conducting experiments on real cases. It is the experts' responsibility to guide and transmit their knowledge to the novice trainee. In addition, this learning can result in invasive medical procedures that could threaten patient safety. The use of medical simulators permits the practitioner to acquire some experience before working on real cases. This training method is already used in aerospace or aeronautics [START_REF] Muffler | Av-8b harrier ii training capabilities[END_REF] for its risk free aspect. In the medical field, some companies propose simulators in ophthalmology, laparoscopy and surgical endoscopy, orthopedic ( [START_REF] Baumann | The pantoscope: A spherical remote-center-of-motion parallel manipulator for force reflexion[END_REF], [START_REF] Cotin | Volumetric deformable models for simulation of laparoscopic surgery[END_REF], [START_REF] Cakmak | Advanced surgical training in laparoscopy with vest simulators[END_REF], [START_REF] Dubois | Simulator for laser photocoagulation in ophtalmology[END_REF], [START_REF] Zambelli | planning and navigation solution in resurfacing hips surgery : A way to reduce the surgical approach[END_REF]). In obstetric, very few complete training systems exist.

Our main interest is to develop a virtual simulator for the training of the young obstetricians. In this paper, we present our biomechanical model of the uterus that will be integrated in the whole model of the woman pelvis. In the future, the forces generated during the delivery will be integrated in a haptic system.

In this paper, we first introduce a state of the art of the childbirth simulators. Then, we show briefly the anatomy of female reproductive system and we present our biomechanical approach.

II. EXISTING CHILDBIRTH SIMULATORS

It exists two kinds of medical training simulators: the static simulator, and those inspired from the augmented reality techniques. The first type is based on a haptic interface, tanneguy.redarce@insa-lyon.fr composed of several physical (plastic) parts which represent the anatomy of some concerned organs (generally the pelvis and the head of the fetus), as well as a motorized articulated system animating the physical parts and simulating the interaction of the fetus with maternal body and the obstetrician. Thus, a position and force feedback control of motors deriving the articulations will generate resistant forces to reproduce a sensation similar to that felt by the practitioner during the delivery. Moreover, these simulators permit the practitioner to have a very good immersion because of the similarities between anatomical representation by plastic parts and the reality. In this case, the real problem is the development of the haptic device and the realization of the necessary control system to derive the motors. The main disadvantage of this type of devices is that, it is a static system that does not take into account different female morphologies, and/or configurations and conditions related to childbirth. Moreover, the device behavior based on the "sensation felt" by the practitioner could be unrealistic despite some realistic sensations felt. In this category, some childbirth simulators are developed like the GeburtenSimulator of the Automatic Control Laboratory of Zurich [START_REF] Riener | Birth simulator (geburtensimulator)[END_REF] or the BirthSim [START_REF] Silveira | A new mechanical birth simulator: Birthsim[END_REF] simulator designed in the Ampère Laboratory in Lyon.

The second type of simulators use augmented reality techniques and propose a physically based modeling of the environment. Interactions with the environment through haptic interfaces will provide more realistic effort computations. Thus, with the help of the modeling process, various scenarios reflecting various childbirth configurations could be considered. This compensates the morphology nonadaptability shortcomings of the first type of simulators.

A virtual simulator has already been developed by Boissonnat [START_REF] Boissonnat | 3d simulation of delivery[END_REF] but they simplify their model by imposing a theoretical fetus trajectory, and the fetal displacement is not the result of a realistic simulation. Kheddar [START_REF] Kheddar | Preliminary design of a childbirth simulator haptic feedback[END_REF] proposed in 2004 another virtual simulator based on a biomechanical model. However, he doesn't consider the uterus as a deformable object but only as a boundary condition. Moreover, like the Boissonnat simulator a theoretical fetus trajectory is imposed.

In the next section, we present a short anatomical study of the female reproductive system, before introducing our approach coupling this two kind of simulators.

III. ANATOMIC STUDY

Our goal is to simulate the delivery and to integrate the result of the computed forces generated during childbirth into a training simulator. First, we have to understand the role of the different organs and analyze which organs play a significant role (the "useful" and the "fundamental" ones).

Fundamental organs, like the bony pelvis, the fetus, the uterus or the pelvis muscles, play a significant role during the childbirth and need to be modeled more precisely. Indeed, they have a direct role in the determination of the expulsion forces and the trajectory of the fetus. Pelvis muscles, for example, are fixed to the pelvis, and their role is to prevent the descent of the fetus before the pregnancy is "at term". A good geometrical model of the pelvis is also indispensable because this bone interacts with the fetus and guides its trajectory. The last fundamental organ is the womb, a muscular chamber in which the fetus grows during gestation. Moreover, during the delivery, womb contractions move the fetus toward the cervix, causing its dilatation.

The useful organs have not a direct impact on the delivery, but their influence on the delivery process are not insignificant. So, we also take them into account. In this type of organs, we can find the placenta (which brings to the fetus food and oxygen), the bladder and the rectum, some big organs which are directly in contact with the womb. The mechanical properties of these object have an influence on the displacement of the fetus (see Fig 1). To sum up, we have seen that the forces are caused by the womb. But these uterine contractions are not strong enough to provoke the delivery. Indeed, we also have to consider the action of the abdominal muscles of the mother which push the fetus through out of the birth canal.

IV. OUR BIOMECHANICAL MODEL

In this section, we propose a biomechanical model of the female reproductive system and the fetus, to simulate the delivery forces to be input into the BirthSim simulator developed in the Ampère Laboratory [START_REF] Moreau | Design of a new instrumented forceps: Application to safe obstetrical forceps blade placement[END_REF]. This simulator is composed of three parts (see Fig. 2):

• A Graphic User Interface (GUI) used to display the position of the fetal head inside of the pelvis and the different parameters like uterine contraction forces, orientation of the head, or the mother push forces. • An electro pneumatic system with a pneumatic actuator and a rotating system to simulate the forces and the displacement of the head. • A mechanical part (haptic interface) which is composed of a plastic representation of the pelvis and the fetal head. This part allows the practitioner to have an interaction with the pneumatic system (haptic interface).

So, our virtual simulator will replace the GUI part of the BirthSim simulator and moreover, will compute the forces which are then generated by the pneumatic actuators. Fig. 2. The BirthSim simulator developed in the Ampere Laboratory [START_REF] Moreau | Design of a new instrumented forceps: Application to safe obstetrical forceps blade placement[END_REF] To save computation time, we simplify the anatomy by taking into account only the organs that play a significant role during the delivery. Moreover, we can note that the human body is composed of organs with different non homogeneous mechanical properties. Practically, this highly complicates the computations. Therefore, we made a second simplification by assuming homogenous properties for different anatomical regions.

The fetus is an other complex object. In fact, for the sake of computation time, we cannot model precisely the fetal body. Therefore, we have to find a good approximation of the representation of the fetus. It is interesting to notice that the morphology of a fetus is very different from a grown up child. Indeed, the proportion of the head is very important compared to the body size. Consequently, the essential of the forces applied on the pelvis by the fetus will be caused by the pressure exerted by the head of the fetus. Moreover, we have estimated that the behavior of the head is essentially caused by the skull. That is why we considered the entire fetus having the same mechanical property as the fetal skull. We simplify again this object. After nine months of gestation the bony structure of the fetus is not totally developed [START_REF] Schall | Mécanique et Technique Obstétricales[END_REF] and this changes the elastic properties of the skull. So, to simplify the simulation, we apply to our fetus model only an elastic behavior law.

The womb is considered to be a membrane to which we apply two force fields. The first one represents the action of the Uterine Contraction Forces (UCF) that will appear at regular intervals. The second one is the simplification of the effect of the abdominal muscles force. This second forces field is applied to the top of the womb (see Fig. 3) and have to be strong enough to counter the resistance of the pelvis muscle (PMRF). It is important to note that, if the uterus contraction forces help the movement of the fetus, the forces generated by abdominal muscles push the fetus out of the birth canal.

Amniotic liquid is the interface between the fetus, the placenta and the womb. For simplification reason, we modeled it by a very elastic material.

V. THE GEOMETRICAL MODEL

For the realization of this biomechanical model, we first need to recover the geometry of the different organs. The segmentation of MRI data provides an over-sampled points cloud which is then converted to a dense mesh representing the geometry of different organs. To decrease the computation time, this mesh should be simplified. The simplification of the mesh size is a sensitive problem. We use ReMESH application [START_REF] Attene | ReMESH: An interactive environment to edit and repair triangle meshes[END_REF] to simplify our surface mesh. Indeed, ReMESH suppresses nodes in the regions where the angular gradient is very low, but keeps a representation enough precise to respect the geometry of the object.

Then, the MESH application [START_REF] Aspert | MESH: Measuring errors between surfaces using the hausdorff distance[END_REF] proposes an efficient method to determine the distance between two surface meshes. Thanks to it, we can estimate the error between the original and the simplified mesh. For sample, we remove more than 90% of the mesh nodes of the fetus (initial mesh: 45000 nodes; final mesh: 4000 nodes) with a mean error equal to 0.5mm. The error due to the mesh simplification of the womb, the fetus and the placenta varies from 0.5 to 0.7 mm. Note that, this error margin is highly acceptable for the precision required in our application.

Consequently, the total mesh before the simplification contains more than 1, 000, 000 tetrahedral elements, and after the ReMESH simplification we have a total number of tetrahedral elements that do not exceed 130, 000 elements.

VI. THE WOMB SIMULATION

Then, we have to propose a physically based simulation method which simulates the deformation and the force fields. Mass-Spring systems are often used in computer animation, because of their simplicity of implementation and their speed of computation. However, they suffer from very bad stability and the poverty of precision.

On the contrary, Finite Elements Method (FEM) is very stable and precise, with computation time that could be too long for real time simulation. But many solutions have been proposed in the literature to counter this last problem ([6], [START_REF] Debunne | Interactive multi resolution animation of deformable models[END_REF], [START_REF] Nesme | Efficient, physically plausible finite elements[END_REF]). Consequently, we chose the FEM for its stability and precision.

One of the most important organs during the delivery is the womb. This muscular part of the female reproductive system is the support of the forces which will push the fetus out of the birth canal. As stated before, two kinds of efforts are applied to fetus: uterine contractions and forces generated by abdominal muscles. During the first stage of the labour, the womb natural contractions push the fetus towards the cervix causing its dilatation. These contractions are regular and uncontrolled. During the second stage, the mother uses her abdominal muscles to apply forces to the uterus to finish the delivery. The action of both types of muscles is necessary to push the fetus out of the mother's body. However, the resultant forces generated by a separate action of the uterus or the abdominal muscles is smaller than the resistance of the pelvis muscles. Consequently, because of the uncontrolled aspect of the womb contractions, it is up to the abdominal forces to be synchronized with theses latter efforts.

Our womb model is composed of four different parts (see Fig. 4): the internal surface, the external superior part, the external surface, and the birth canal. The birth canal is an extension of the uterus and its role is to guide the fetus as it exits the cervix. Because of the increased volume of the womb, the abdominal muscles are enhanced and their actions can be applied to the upper part of the uterus.

We have developed and compared two models of abdominal efforts. The first model assumes unidirectional forces field, from the top of the uterus toward the centre of the cervix. The second forces model is based on the principle that abdominal muscles cover a more important surface of the uterus and that efforts are applied perpendicularly to the surface of the uterus. We compared the results of deformation and the direction of displacement fields generated by these two forces fields to which we applied to the same womb contractions. The results show that the distribution is slightly more homogeneous in the second case, with efforts following the normal direction (see Fig. 5). Therefore, we only consider abdominal contraction model.

To check the consistency of our model, we integrated the fetus model. The goal is to assess the convergence of the model by observing that the uterus comes into contact with the fetus and placenta meshes. At this step, for the simplification of the computation, we assume the fetus rigid by increasing its elastic modulus. In these new conditions, we obtain a good deformation of the womb geometry, with satisfying contact conditions between different organs.

Next we study the displacement of the fetus in the two stages of the delivery. At the first stage, we only apply the uterus contraction and we want to check, if we have a good positioning of the fetus. We observe a very light descent (1mm) with a rotation of the fetus' body. At the second stage of the delivery, we add the abdominal forces to verify if we have a correct displacement of the fetus in the direction of the cervix. We observe a good descent (20-22 mm) of the fetus near to the cervix (see Fig. 6).

VII. CONCLUSION

We proposed a biomechanical model based on the Finite Elements Method and mechanical laws to simulate the delivery and to recover the different forces applied to the different organs concerned by childbirth. Our model takes into account the principal obstetrical organs. We verified that the different simplifications that we apply (like using an elastic behaviour law, assuming homogeneous elastic mechanical properties for the fetus, or the simplification of the force fields applied to our model) do not result in erroneous behaviors. We used the Finite Elements Method to obtain dynamic simulations and to estimate different mechanical parameters such as forces, displacements to be input to BirthSim childbirth simulator. At this stage, our goal was to model a realistic anatomical behaviour of the organs, by finding the right boundary conditions for each organ. Interactive time performance was not researched. Moreover, we propose a simplified model to verify the feasibility of our approach. In the future, we will develop a more precise model, using more realistic contraction forces (several elementary contractions). Then, the next step will be devoted to accelerate the computation time, by introducing new real time simulation algorithms.

Fig. 1 .

 1 Fig. 1. Anatomy of the pregnant woman

Fig. 3 .

 3 Fig. 3. Anatomic and mechanical pelvis and fetus model scheme

Fig. 4 .

 4 Fig. 4. Different parts of the womb modelThe internal surface is used for the contact conditions between the uterus and the fetus. It includes the internal face of the womb and the internal face of vaginal canal. The superior external face is shared by the abdominal muscle and the womb. The second forces field is applied to this part. The womb contraction forces are applied to external surface of the uterus. These efforts are directed towards the birth canal. The birth canal is an extension of the uterus and its role is to guide the fetus as it exits the cervix. Because of the increased volume of the womb, the abdominal muscles are enhanced and their actions can be applied to the upper part of the uterus.We have developed and compared two models of abdominal efforts. The first model assumes unidirectional forces field, from the top of the uterus toward the centre of the cervix. The second forces model is based on the principle that abdominal muscles cover a more important surface of the uterus and that efforts are applied perpendicularly to the surface of the uterus.

Fig. 5 .

 5 Fig. 5. Comparaison of the displacement field with unidirectionnal force field and normale force field

Fig. 6 .

 6 Fig. 6. Fetus displacement with uterus contraction forces (up) or uterus contraction and abdominal forces (down)

ACKNOWLEDGMENT

This work is partly financed by a grant of the GMCAO project of the cluster ISLE of the Rhône-Alpes region. Special thanks to Jeremy Arquez (TELECOM ParisTech, CNRS, UMR-5141, LTCI) for the segmentation of the medical data provide by the Prof. C. Adamsbaum (St Vincent de Paul hospital, Paris).


Colin Aygalinc

Eva Gerbert-Gaillard

German Vega

Philippe Lalanda

Service-oriented autonomic pervasive context

Keywords: Autonomic Pervasive Context pervasive computing, context, service-oriented components

HAL is

Introduction

A growing number of smart, communication-enabled devices are integrated in our living environments. This is essentially due to major advances in hardware and networking technologies, which make sensors more powerful, cheaper and smaller in size. Such digitalized environments, said to be pervasive or smart, are increasingly accepted in all places where social or professional activities take place. They support the creation of new added-value services that are delivered anytime and in a non-obstructive way. This new form of computing is raising huge economical and societal expectations in domains like manufacturing, buildings and homes, energy, commerce, and even healthcare. Applications integrated in such smart, pervasive environments are context-aware by essence. They are able to adapt their behaviors and the provided services according to environmental conditions [START_REF] Baldauf | A survey on context-aware systems[END_REF]. The notion of environment should be taken in its broad sense here. It includes any information that can be of interest for an application like, for instance, physical quantities, locations and expectations of human beings (implied or not in the functions provided by the application), the software itself, and even remote digital resources. Initially, context was essentially limited to location-awareness [START_REF] Bauer | Location models from the perspective of context-aware applications and mobile ad hoc networks[END_REF] and to information collection. Since then, it has evolved towards more elaborated models. As a consequence, developing and evolving context information for pervasive applications is still very challenging. This explains why research into context-awareness is a firmly grounded activity in computer science and will continue to expand with the recent emergence of Internet of Things, IoT [START_REF] Perera | A survey on internet of things from industrial market perspective[END_REF].

Context evolutions, in terms of models and supporting technologies, actually follow architectural evolutions of pervasive applications. Indeed, these applications are today very distributed from devices to cloud facilities, going through multiple gateways [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF]. Contextual information is used at every level but with different requirements. For instance, at the cloud level, focus is on large scale and completeness whereas, at the fog level [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF], concerns are more about reactivity and security. This leads to different ways to represent, query, build, and update contextual information. In our work, we focus on the fog level where contextual information is usually manipulated for two different purposes. First, it is used to implement local actions with stringent real-time requirements. Then, part or all of the gathered information is aggregated, synthesized and sent to the cloud level for longer-term analysis. In this paper, we propose a novel approach based on service-oriented and autonomic computing in order to better manage context at the fog level. Our solution relies on an architecture where context is a programming module, connected to the physical environment and publishing information as a dynamic set of services. Context is dynamic in order to reflect the changing nature of the execution environment but also to deal with applications evolving needs. Context also includes event-based facilities to make consumer applications aware of contextual evolutions. Finally, context is autonomic in the sense that it can self-adapt to those evolutions. Our solution is seamlessly integrated in a pervasive platform, called iCasa, used by our industrial partners (Orange and Schneider Electric). It heavily uses the facilities of the iPOJO service-oriented component model [START_REF] Escoffier | ipojo: an extensible service-oriented component framework[END_REF]. In order to ease context development, we have also developed a Domain-Specific service-oriented Language (DSL) allowing the straightforward definition of a context module and of its autonomic capabilities.

The structure of this paper is the following. The coming section provides background about our application domain and about the notion of context in pervasive computing. Section 3 presents the overall approach defended in this paper. Then, the following section gives details about the way it is implemented in iCasa. Section 5 is about the evaluation of the proposed approach. It has been experimented on smart home use cases, defined with the Orange Labs. Finally, related work is developed in section 6, and section 7 concludes this paper.

Background

Our research deals with pervasive applications in intelligent environments like smart homes, smart buildings or smart manufacturing (industry 4.0). These applications are now widely distributed, from the sensors up to cloud facilities. Some code is executed at the edge of the network, in an Internet gateway for instance, while other code is run in computing farms. More and more, code is also executed in intermediary machines in order to prune the volume of data to be transmitted in the cloud, and perform mediation operations. Depending on the code location, various forms of context are needed. They are based on different formalisms, different real-time constraints, and different interaction pat-terns between context providers and context consumers. Current architectures are illustrated here after by Fig. 1. To make these various needs more concrete; let us focus on an actimetrics application that we have been investigating for years with the Orange Labs. Two major functions can be distinguished for actimetrics: the first one is about early diagnosis of degenerative diseases like Alzheimer whereas the second one is concerned with real-time supervision of people at home. The first function, concerned with identification of degenerative diseases, deals with long-term evolutions spanning several months. It requires complex time-series and event correlation analysis, and is based on a rich, slowly evolving context that is explicitly accessed and browsed by the analysis algorithms. The second function is about real-time supervision. It deals, for instance, with fall detections or automated alerting in case of unusual events like prolonged inactivity or irregular sleep hours. This second function may use the same environmental data as the first one, but it is has to deal with stringent real-time constraints: new information should be made available very rapidly to the application. This is made particularly difficult by the inherent dynamicity of pervasive environments.

Let us now define more precisely what we mean by context. Context is traditionally presented as a synchronized description of concepts and relationships between them pertaining to the execution environment. Precisely, contextual information comes from computing environment (memory, network, etc.), user environment (location, needs, preference, etc.) and physical environment (temperature, noise, etc.). It can be the description of a fact, a physical object, a physical value, or an event.

There are several architectural approaches to build context-aware applications. A popular solution is to separate context and applications into different programming modules (see Fig. 2). Context-specific tasks like information gathering (context acquisition), information processing through inferences or explicit code-based operations, information storing, and information presentation lie outside the application boundaries. This pattern where context and applications are clearly separated improves code readability, debugging and evolution. It also allows context sharing between pervasive applications. We subscribe to this architectural approach but we readily acknowledge that building a context module is complex. Multiple design trade-off decisions have to be made and implemented regarding data access, synchronization mechanisms, knowledge representation, reasoning, and presentation. A common solution to alleviate these difficulties is to use a context management framework. Its purpose is to deal with a number of generic features like information synchronization or publication. In our work, we concentrate on the fog level, where reactivity is essential. The supporting framework has to deal with dynamic environments, where resources can appear and disappear without notice, and dynamic applications that can be launched or de-activated anytime. Specifically, we have identified the following requirements:

-Coupling between applications and context middleware must be as loose as possible. Applications should not be aware of information sources. They have to be aware of the availability (or not) of the information and its quality. -The context middleware must present the information in a format understandable by the application and in the expected quality (level of security or preciseness for instance) that can change overtime. -The context middleware must be able to adapt dynamically in order to provide the best contextual information depending on the application needs without interruption of service. -The context middleware must adapt autonomically since, in pervasive settings, no administrator is available or skilled enough to perform management operation. For instance, the middleware must be able to adjust synchronization frequencies depending on the application needs. -The context middleware must be able to activate or deactivate the sources of information, in particular to save energy. Sensors that are not connected to the mains power source should be activated only when necessary. -The context middleware must be able to alert running applications when contextual information of interest has changed since physical environment can change anytime without notice.

We believe that service-orientation coupled with autonomic features is well suited to meet these requirements. Our interest in services is twofold. We aim to present context as a service to pervasive applications. We also aim to implement the context module with service-oriented components to enhance self-adaptation of the context.

Overall approach

We have integrated an autonomic, service-oriented context module in our pervasive platform, named iCasa [6][7]. This platform builds upon the Apache serviceoriented component model, iPOJO. Context appears as a dynamic set of services. Depending on the sources availability and the platform needs, different services are published in and withdrawn from the platform service registry. They are then opportunistically used by the pervasive applications, coded in iPOJO. As illustrated, the context module receives goals from the platform that are used for context self-adaptation. The context module tracks any contextual modifications and sends an event to alert consumer applications. The overall approach is illustrated by Fig. 3. In our solution, services are made available in the iPOJO registry. A major driver of our approach is not to go beyond what is necessary in order to achieve the applications expectations. This is the whole purpose of the autonomic management. It should only create and keep up to date the services of interest for the current applications, depending on the available sources. Our approach also enforces application development through dynamic composition of context services. An application specifies its required context services and, at run time, it is bounded to an appropriate service and kept informed of every evolution.

Regarding implementation, the context module is also based on the iPOJO service-oriented component model. Context is modeled as components representing concepts and relationships. Some of them can publish services. Others are used to compute information and are not proposed as external services. IPOJO containers include some autonomic features in the dynamic selection of services. Also, iPOJO includes touchpoints in the containers that can be used by more global autonomic manager. There are then several autonomic loops in the context module. It appears however that implementing the context and the associated autonomic manager is still rather complex, especially regarding the timing aspects. We have then developed a Domain Specific Language (DSL) to cope with identified context specific concerns.

Context Management Domain Specific Language

The purpose of the proposed DSL is to enforce the architectural pattern described in the previous section, and to help developers with the most common tasks found in context management. The DSL is an extension of the iPOJO Component Model.

Service Oriented Component

An iPOJO component is implemented as a plain Java class decorated with specific annotations to specify non-functional concerns. The set of Java annotations can be regarded as the concrete syntax of the DSL. The base iPOJO annotations support the dynamic service interaction pattern. To illustrate iPOJO core, the following code shows a simplified Light-follow-me using two context services: lights and presence.

An application component is implemented by a Java class decorated with the annotation @Component. Component dependencies are specified using the @Requires annotation. A dependency is specified in terms of a service specification defined by a Java interface (BinaryLight and PresenceService in the example). Each dependency is associated with a field of the class (binaryLights and presenceServices), which will be bound at runtime to the selected service. The field can then be used to transparently access the required service. Dependencies can specify filters to match the available service providers.

Java code for service-oriented components @Component(name="LightFollowMeApplication") @Instantiate public class LightFollowMeApplication { @Requires(id="lights", optional = true,specification = BinaryLight.class, filter = "(!(locatedobject.object.zone=LOCATION_UNKNOWN))") private List<BinaryLight> binaryLights; @Requires(id="presence", optional = false,specification = PresenceService.class) private List<PresenceService> presenceServices; }

Context Service Description

Application development relies only on service descriptions to reduce coupling with the context. The example here after illustrates a simplified presence detection service. The service is specified as a Java interface, annotated with the @ContextService marker. In this case, the interface proposes a single method (presenceInZone) to get the current detection status, in a zone associated with the context provider.

Java code for context service description public @ContextService interface PresenceService { public @State static final String PRESENCE_SENSED = "presence.sensed"; public @State static final String ATTACHED_ZONE = "zone.attached"; public PresenceSensing presenceInZone(); public enum PresenceSensing {YES,NO,NOT_MEASURED}} As mentioned earlier, context management services also require event notifications. To do so, we have extended service specification with declaration of context service states. Changes in states are notified to consumers with events. In the example, we have declared (using the annotation @State) two states associated with the presence service: the presence status (PRESENCE SENSED) and the detection zone (ATTACHED ZONE). Note that the context service specification is a contract between the context provider and the requiring component. It is the responsibility of the context provider to generate appropriate events when state changes.

Context Service Usage

Applications use iPOJO facilities to react to context evolution. Two kinds of context events are of interest to applications: availability/unavailability of context providers, and changes in context service state. The following code example shows how the Light Follow Me application is programmed to react to changes in the context.

Java code for dynamic context service usage @Component(name="LightFollowMeApplication") public class LightFollowMeApplication { @Bind(id="presence") public void bindPresence(PresenceService presenceService){ managelight(presenceService);} @Unbind(id="presence") public void unbindPresence(PresenceService presenceService){ Set<BinaryLight> lightInZone = getLight-InZone(presenceService); lightInZone.stream().forEach((light) ->light.turnOff()); } @Modified(id="presence") public void modifiedPresence(PresenceService presenceService){ managelight(presenceService); } private void managelight(PresenceService presenceService){ Set<BinaryLight> lightInZone = getLight-InZone(presenceService); if (presenceService.presenceInZone().equals(YES)){ lightInZone.stream().forEach((light) ->light.turnOn()); }else { lightInZone.stream().forEach((light) ->light.turnOff()); }}} Notification of providers availability is declared using the @Bind and @Unbind annotations. The annotated bind method is invoked each time a new matching provider is registered in the service registry (respectively, unbind methods are invoked when the provider is unregistered). In the simplified scenario for instance, when a new presence service provider is added to the context, the application simply turns on/off lights in the zone according to the current sensed presence status. Interest in changes of the state of the context service is declared using the @Modified annotation. The annotated method is invoked each time a state change event is triggered by the provider. The specified callback receives a reference to the source of the event and, optionally, the state that was modified.

Note again that the developer only declares interest in a given context event. All the code concerning callback registration and invocation is handled by the iCasa platform runtime. Notice also how, inside the event callbacks, the developer can directly use the injected dependency fields to transparently access the context services. The declarative nature of the DSL greatly reduces common errors and simplifies the programing model, as discussed in the evaluation section.

Context Entity

Developers implementing a context service must meet specific requirements. In general, they need to interact with physical devices; this interaction requires error-prone code for synchronization and event handling. We have developed specific DSL extensions to cope with this need. To illustrate this, the code of a component implementing the BinaryLight context service using the ZigBee protocol is presented. We assume that the code dealing with ZigBee is encapsulated a ZigbeeDriver component. As previously said, a context provider is implemented as an iPOJO component, using the @ContextEntity annotation to declare the provided context services (a single component may implement several context services). The component has to implement all methods and states declared in the context service declaration. A common implementation pattern is to maintain within the component an in-memory representation of the current state of the environment, and keep this representation synchronized. Our DSL supports this pattern using state fields. In the code example, the component implementation class ZigbeeBinaryLight declares powerStatus to keep the current lamp state (on/off). State fields are marked with the @ContextEntity.State.Field annotation, but otherwise behave as normal Java fields. For instance, the service method getPowerStatus simply returns the current field value, and methods turnOn and turnOff directly modify it. Any modification to the in-memory field must be reflected on the environment, using the corresponding ZigBee actuator. The code performing synchronization is specified with the @ContextEntity.State.Apply annotation that provides a function which is invoked each time the associated field is modified. In the example, every time powerStatus is modified (using the turnOn and turnOff methods) the setPowerStatus function is invoked, which will in turn delegate to the ZigBee driver to do the actual action.

Java code for context entity implementation

In general, environment synchronization is bi-directional. So, sensed changes in the environment must equally be reflected in the in-memory state representation. In our example, lights can be physically turned on/off using a mechanical button; this is detected by a ZigBee sensor associated with the lamp. Depending on the capabilities of the sensor and device protocol, environment information can be gathered synchronously or asynchronously.

The example shows an asynchronous update. Here, the protocol driver notifies the context entity (by invoking method deviceDataChanged) of changes in the status of the lamp, and from the raw data the component calculates the new state value by using the method pushPowerStatus. This method is declared using the annotation @ContextEntity.State.Push that associates it with a corresponding context state field. Each time the method is invoked, the return value is used to update the in-memory state representation. Synchronous updates declared with @ContextEntity.State.Pull are similar, except that the declaration specifies the periodicity used to calculate the new state value.

Using this declarative approach has two main advantages: it reduces the programming complexity and it allows autonomic adaptations at runtime. For instance, if a context entity is not used by any application at a given moment, the iCasa autonomic context manager can decide that updating the in-memory fields is not needed, avoiding unnecessary polling. A context entity can be related to other context entities. This is naturally supported in iPOJO as a service requirement. In the code example, the ZigbeeBinaryLight entity is related to a Zone context service, using the zoneAttached dependency field. This field is marked with @ContextEntity.Relation.Field to express that it can be handled by the context autonomic manager.

Context service provisioning

Context service provisioning is the process of deploying, instantiating, and relating context entities. This process is guided by external events: a device joining the network, a new application deployed in the platform, or an explicit demand by the platform administrator.

Part of this process can be automated using approaches like RoSE [START_REF] Bardin | Towards an automatic integration of heterogeneous services and devices[END_REF] and MUSIC [START_REF] Rouvoy | MUSIC: middleware support for self-adaptation in ubiquitous and service-oriented environments[END_REF] which provide a pattern to modularize and maintain the discovery of external events at runtime, but no specific support is provided for dynamic instantiation of context service providers. iPOJO runtime supports this behavior, but its establishment remains highly technical, tightly coupled to the iPOJO model and de facto become less feasible for developers.

Our middleware provides autonomic facilities regarding this issue, without cluttering the discovery code. As shown here after, discovery code emits now instantiation requests (previously it was direct instantiation) and the middleware choose to process or stock the requests according to the application contextual service requirements.

Java code for a context service dynamic provisionning private @Creator.Field Creator.Entity<ZigbeeBinaryLight> binaryLightFactory;

public void zigbeeDiscoveryEvent(Map<Parameter> param){ String id = ...; ... binaryLightFactory.create(id,param); }

Runtime support

In this work, we have extended the iPOJO runtime. Precisely, we implemented two additional handlers (see Fig. 4):

-A Synchronization Handler deals with state synchronization of entity components. It keeps the states up-to-date by managing the synchronization functions. Different strategies can be specified to do so. For example, the handler can periodically call pull functions or just wait for push callbacks to keep the state up-to-date. Additionally, the handler is in charge of publishing states as service properties. This publication has two main interests: it allows the processing of more advanced filters and state updates can be reported to the application without the burden of an Observer pattern, by relying on iPOJO notification mechanism. -A Relation Handler is in charge of the dynamic service binding of relations. To cope with changing runtime condition, we implemented autonomic behavior at two levels. First, local autonomic loops are executed in the component container. Their goal is to locally modify the topology of the context graph by using service substitutability and late binding. This behavior is interesting for abstract context entities. It can help to increase measurement relevance by correlating new low level context sources. The global autonomic loop is implemented in the context manager. Its goal is to dynamically adapt the global topology of the context graph and the configuration parameter exposed by our DSL in order to satisfy, in a best effort way, the application provisioning. To do so, we assume that applications are developed following the iPOJO model. It involves that applications specify their needs in terms of context service dependency. The context manager can adapt the running context graph to fit applications needs. Currently, it is possible to dynamically realize the following changes:

-Enable or disable context entity provisioning; -Modify specific synchronization parameters; -Replace context providers.

All of this adaption logic is hard coded in our context manager. We are currently investigating integration with dynamic deployment to provide finer grained context management.

Validation

For evaluation purposes, we defined two scenarios that have been implemented with traditional SOCM and with our DSL. The evaluation focused on design time activities. Specifically, we used the following metrics: number of lines of code, cyclomatic complexity, and technical debt (evaluation of the effort needed to fix all issues). These metrics are computed and provided by the SonarQube [10] management tool. The first scenario deals with the iCasa platform and its associated simulator. Precisely, the following functionalities are provided:

-A set of abstraction for devices, location, user, and their implementations; -A web interface acting as a dashboard; -A script language allowing to dynamically instantiate simulated device, location, and user.

In the reference development, contextual information was computed in an ad hoc way. It was coded without any specific strategy in a non-modular way (to be fair, we reused an existing implementation). It turned out to be difficult to extend and evolve. We then redesigned the code, using our DSL, and compared the two versions (see figure see Fig. 5). Thanks to annotations, the number of lines of code decreased. By clearly identifying synchronization functions and limiting their number, cyclomatic complexity has been reduced too. We also noticed that the restructured implementation presents a high percentage of duplicated lines (approach 7%, reference 3%) due to iPOJO technical limitations: it doesnt support inheritance. The number of lines could therefore be reduced more. Our approach notably lightens the context layer development. It offers non-functional technical facilities. The context is modularized, extensible, and autonomic. The whole software is more consistent, testable, and maintainable.

The second evaluation compares two versions of the Light Follow Me application build upon the reference and the new platform (Fig. 6). This application is simple, yet it encompasses all requirements presented before. It is a typical home pervasive application that does not need complex reasoning algorithm but has to face the dynamism of the environment and directly influences the user environment. In the reference implementation, the application processes information like the presence per zone by directly reasoning over the sensors and their location. In the new implementation, we decided to externalize this processing with a dedicated presence per zone context service (blue part on Fig. 6). This presence-per-zone service can be shared between applications and evolves independently of the business code of applications. Modularizing the presence service brings an overhead in terms of lines of code and complexity. This is due to the fact that service provisioning must be implemented in our solution. However, this overhead can be shared between several applications. So, if we analyze only the application business code (orange part on Fig. 6), it is approximately divided by 2 and de facto becomes easy to test, maintain, and evolve.

As a conclusion, externalizing context requires an additional development task and the resulting architecture is more complicated, but this cost can be mutualized and shared among several applications. Moreover, new applications can be develop on top of more abstract services, which facilitates their implementation.

Related Work

Many surveys [1][3][11][12][13] about context middleware have been proposed. We compare our approach to those whose architecture can be adapted to a fog computing environment and its specific constraints.

The Context Toolkit [START_REF] Dey | Understanding and using context[END_REF] promotes code-reuse through the composition of distinct artifact called widgets to build the context. These widgets are used to hide the complexity of sensors and abstract context information. These reusable blocks are explicitly linked at design time, each block deciding which blocks to use. Our approach is similar in the sense that we divide the context in individual small pieces. However, we delegate composition at runtime with more variability expressed at design time. Moreover, Entity-Relation-like model offers more flexibility to design complex contexts.

COSMOS, COntext entitieS coMpositiOn and Sharing [START_REF] Conan | Scalable processing of context information with COSMOS[END_REF], is a component based context middleware. Each pieces of context is reified as a component called Context Node organized in a hierarchical structure. This approach provides separation of concerns by offering several built-in mechanisms like push/pull notifications. However, the strictly hierarchical approach of COSMOS context makes it difficult to model horizontal relations. Moreover, component specifications are strictly defined at design time, so runtime extensibility is hard to achieve.

DiaSuite [START_REF] Bertran | Diasuite: A tool suite to develop sense/compute/control applications[END_REF] is a component based tool suite using a DSL, DiaSpec. DiaSuite, following the Sense/Compute/Control pattern, defines three primitive types of component: resource, context, and controller. DiaSpec is used to describe the structure of each component, and through an additional build time step, to generate the component skeleton. DiaSuite is similar to our approach in the sense that its main goal is to help developers. However, many things remain on developer side like programming of runtime component binding, and there is no support for synchronization. We believe that this behavior must be specified and not programmed in order to ease runtime reconfiguration. Also, java based annotations seem to be better accepted by developers.

ACoMS, Autonomic Context Management System [START_REF] Hu | An autonomic context management system for pervasive computing[END_REF] promotes a work dealing with fault-tolerance as regards to the dynamism of context provisioning by using autonomic behavior. Applications describe their needs in terms of context fact, and ACoMS can autonomously configure and reconfigure its context acquisition and pre-processing functionality. ACoMS promotes autonomous behavior, but context sources are at a sensor level and no clear guidelines are provided to construct more abstract concepts. Moreover, we think that by infusing autonomic touch points at a finer granularity, more advanced autonomic behavior can be brought to context management.

[18] work deals with proactive adaptation and context management based on a SOCM architecture. It underlines the fact that context interactivity is not just about providing the most powerful modeling and reasoning engine. Indeed, applications also can deal with context in a proactive manner, with the ability to change the context through actuators. Our approach, in this sense, is very similar. To do so, a specific query language is provided, with the issue of a steep learning curve.

Conclusion

In this paper, we have presented a service-based architecture to design contextaware applications. We have also described a Domain-Specific Language facilitating the development of a context module in iPOJO. These facilities are seamlessly integrated in the iCasa platform and tested on real-size applications with the Orange Labs.

We are now working in two complementary directions. First, we are trying to model more complex contextual entities. In particular, we believe it will be soon necessary to include IoT and other pervasive platforms in the context since these artifacts will be more and more present in smart environments. Second, we are seeking to better formalize the application possible adaptations as a function of the available contextual information and associated quality.

Fig. 1 .

 1 Fig. 1. Pervasive applications architecture.

Fig. 2 .

 2 Fig. 2. Separation of context and applications.

Fig. 3 .

 3 Fig. 3. Overall approach.

Fig. 4 .

 4 Fig. 4. Service-oriented component view of context model.

Fig. 5 .

 5 Fig. 5. Evaluation on iCasa platform and simulator.

Fig. 6 .

 6 Fig. 6. Evaluation on Light Follow Me application.


Colin Aygalinc

Eva Gerbert-Gaillard

German Vega

Philippe Lalanda

Stéphanie Chollet
email: stephanie.chollet@lcis.grenoble-inp.fr

A Model-Based Approach to Context Management in Pervasive Platforms

Keywords: context, software engineering, service-oriented components, pervasive computing. I

Pervasive computing envisions environments where computers are blended into everyday objects in order to provide added-value services to people. This new form of computing gives rise to huge economical and societal expectations. However, pervasive applications raise major challenges in term of software engineering and remain hard to develop, deploy, execute and maintain. Context-awareness, in particular, is a salient and difficult property that must be met by pervasive applications. In this paper, we propose a service-oriented framework facilitating the design and execution of a context management module in pervasive platforms. Our approach is illustrated with a smart home example and implemented on top of iPOJO, the Service-Oriented Component Model of our pervasive platform iCasa.

INTRODUCTION

Pervasive computing envisions environments where smart devices are blended into everyday objects in order to provide added-value services to people [START_REF] Weiser | The computer for the 21st century[END_REF] [2] [3] [START_REF] Atzori | The Internet of things: a survey[END_REF]. These devices are communication-enabled and can cooperate with each other in order to build up advanced applications (services). This new form of computing is set to become reality and is raising huge economical and societal expectations in domains like home, office, transportation, shopping, or even healthcare. Pervasive applications are designed to be invisible and non-obstructive. To provide the expected added-value services to users, they must rely on information extracted from the environment. Such information is called context.

Context-awareness is indeed a salient property of pervasive applications. It means that an application is able to adapt its operations according to changes in its environment. In the first days of pervasive computing, context was essentially limited to location-awareness. Since then, it has evolved towards more elaborate models. Context represents any information that can be used to characterize an entity that is relevant to the interaction between a user and an application [START_REF] Dey | Understanding and using context[END_REF]. Building and maintaining context for one or several applications is very challenging. This is partly due to the fact that smart sensors used to capture information are heterogeneous, dynamic, unreliable and sometimes mobile (like a phone for instance).

Current solutions are mostly ad hoc and do not exceed vertical, proprietary solutions very limited in terms of provided services. In particular, they are based on a closed world assumption and cannot deal gracefully with evolutions. We believe that advanced software engineering support is crucially needed here. Dealing with device heterogeneity and volatility, and continuous context evolution, is just too hard without adapted tooling. It demands too many hard-to-find technical skills, leading to difficult maintenance and error-prone code.

We believe that developing pervasive applications must be based upon specific software environments hiding most of the complexity presented here before. A well-established solution is to delegate some technical features to an execution platform, also called middleware [START_REF] Issarny | A perspective on the future of middleware-based software engineering[END_REF]. Middleware forms an abstraction layer that encompasses a set of common features and services, allowing developers to focus on the development of the addedvalue service logic of the application. This approach can be applied to context management [START_REF] Dey | Understanding and using context[END_REF] [7] [8] [START_REF] Vansyckel | Extending context management for proactive adaptation in pervasive environments[END_REF]. Here, some context management operations are handled by the execution platform, and not by the application developers. Specifically, context middleware provides ways to support the development of context-aware applications, emphasizing the fundamental concerns of gathering, modeling, processing, and disseminating environmental information. However, we believe that some limitations remain in terms of usability, extensibility and degree of assistance.

In this paper, we propose a service-oriented framework integrated on top of our pervasive platform, iCasa. This framework allows the straightforward definition of a context module and, at runtime, the dynamic construction of synchronized and observable entities. It also comes with architectural guidelines to ease development.

This paper is divided into seven sections. We provide background about pervasive platforms and a motivating example in section II and III. Our approach and proposition are developed in sections IV and V. Section VI focuses on the implementation of our example. Finally, we conclude in section VII and VIII with related works, limitations of our approach and envisioned future work.

II. PERVASIVE PLATFORMS AND CONTEXT

An execution platform provides a development model and a set of non-functional services that can be used (often through annotations) by the applications. Generally, execution platforms handle a limited number of such services like, for instance, persistence, security or remote management, on behalf of the applications. Making the distinction between the execution platform and the hosted applications simplifies the complexity of development, debugging and administration. Pervasive platforms are usually based on the principles of Service-Oriented Computing (SOC) paradigm [START_REF] Papazouglou | Service-oriented computing[END_REF] where loose coupling between components enables dynamic adaptation and runtime evolution. This architecture level adaptability is crucial in pervasive computing in order to drive seamless adaptations when the environment changes.

Current platforms are today able to provide very effective technical services. For instance, GatorTech [START_REF]The gator tech smart house: a programmable pervasive space[END_REF] extends the OSGi framework with heterogeneous device access services. This is also the case of for PCOM/Base [START_REF] Becker | PCOM -a component system for pervasive computing[END_REF] or RoSe [START_REF] Bardin | Towards an automatic integration of heterogeneous services and devices[END_REF]. Other platforms introduced autonomic features. For instance, AMUSE [START_REF] Lupu | AMUSE: Autonomic management of ubiquitous e-health systems[END_REF] and ACCORD [START_REF] Liu | A component-based programming model for autonomic applications[END_REF] propose specific component models to build autonomic applications.

Integrating context management in pervasive platforms is a crucial and challenging task. Context can be defined as "any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application." [START_REF] Dey | Understanding and using context[END_REF]. Entities are generally classified in the following categories:

• Computing environment, including available memory, network, connectivity, devices, etc. However, implementing these facilities involves highly error-prone technical code from low-level synchronization to high-level mediation or enrichment operations.

III. MOTIVATING SCENARIO

Let us introduce our motivating scenario, based on iCasa1 [START_REF] Lalanda | Servicebased architecture and frameworks for pervasive health application[END_REF]. The iCasa environment is made of three tools:

• An Integrated Development Environment based on an eclipse plug-in. It supports the development of iPOJObased application. • An execution platform, based on OSGi and RoSe, running on a home gateway, which hosts several applications and offers dynamic deployment facilities. • A smart home simulator (see Fig. 1) that supports the execution of predefined scenario, in order to quickly test pervasive applications. In this environment, several applications belonging to domains like safety, comfort or healthcare have been developed. These applications vary a lot in terms of technical requirements and needed context. For example, iCasa hosts part of a home care application called actimetrics which measures and analyses the motor activity of elderly. Its purpose is to track behavioral changes to early diagnosis degenerative diseases like Alzheimer [START_REF] Lalanda | Servicebased architecture and frameworks for pervasive health application[END_REF].

For our motivating scenario, we will consider an application which runs only on the home gateway in order to focus on the capabilities delivered by the platform itself. We designed a simple Light Follow Me application: for each room of a house, it turns the lights off and on depending on the presence of a user, and adjusts light intensity as a function of the moment of the day (morning, afternoon, evening or night).

The context needs of the Light Follow Me can be decomposed as it follows. First, the application relies on appropriate abstractions of lightning devices, spatial zones and time (modeling). Such abstractions must be synchronized with the physical devices (gathering). Then, the application requires knowing which device is in which zone (enrichment). The application computes physical parameters: presence and illumination per zone (processing). Finally, the application necessitates retrieving all this information (disseminating) and applying its business logic to affect the environment.

In this paper, we show how to clearly separate context and application during development and execution phase. We also demonstrate how our tool helps the definition, deployment, and execution of a context program module on top of iCasa.

IV. PROPOSAL OVERVIEW

We have defined and implemented a context management framework on top of iCasa, our operational pervasive platform. Its purpose is twofold. First, it provides assistance to developers for context definition through a well-defined set of abstractions and associated code. Second, it supports the execution of this context in dynamic environments. Most nonfunctional aspects are kept hidden from application developers to help them focus on business code. Generic technical details of implementation, like synchronization, are simply specified with annotations and corresponding code is integrated at build time.

In our approach, a context is a dynamic program module provided by the pervasive platform and used through API by the applications running on top of the platform. This is in contrast with the "database vision" of context where all possible information is collected and kept in a storage facility and made available through queries.

As illustrated by Fig. 2, we are defending a two-step approach. First, domain engineers define a context that can be used by a set of applications that are expected to run on a same platform. Applications developers use this context in order to simplify their code and concentrate on business logic. Specific tooling based on model-driven engineering [START_REF] Seidewitz | What models mean[END_REF] is provided for that purpose. Second, context is transformed into an iCasa program module and is dynamically executed. This module relies on service-oriented computing, enhancing flexibility. The execution platform relies on a domain-specific serviceoriented component model, iPOJO [START_REF] Escoffier | iPOJO: an extensible serviceoriented component framework[END_REF]. Context entities and relations are modeled as components. Properties of components represent the state of the associated entity. Code in charge of gathering information from the environment, and keeping the corresponding model synchronized, is encapsulated in each component. Each component can be exposed as a service, allowing easy dissemination of context information to applications. Context relations are represented as links between entities.

V. PROPOSAL DETAILS

A. Design-time support

Context is a representation of the surrounding environment. As such, it can be regarded as a model [START_REF] Seidewitz | What models mean[END_REF] of the environment used by the pervasive applications. In our approach, context runtime management is delegated to the pervasive platform. The context model must then be made explicit, and kept separated from the application business code.

Context is defined by domain experts. It must conform to a meta-model defining the different elements of a context and their possible relationships. This meta-model (presented in Fig. 3) encompasses the different concerns (as depicted by the enclosed areas in the figure) that must be handled by the platform.

Specifically, the core of the meta-model concerns context modeling, and is based on two main concepts: After designing the conceptual model, made of entities and relations, a domain expert has to specify how this model has to be synchronized with the real environment. This is achieved by associating synchronization functions to the properties of the defined entities (as shown in the left part of the meta-model in Fig. 3). Synchronization functions are programmed in Java, and encapsulated in the code of the component corresponding to the entity.

•
To support these design-time activities, our approach is based on a domain-specific specialization of the iPOJO component model [START_REF] Escoffier | iPOJO: an extensible serviceoriented component framework[END_REF]. Our proposed meta-model is in fact an extension (see the top right part of Fig. 3) of the iPOJO metamodel, with the specific concepts required to deal with context.

The concrete language used in iPOJO to define components is based on plain Java classes marked with annotations to declare non-functional aspects handled by the platform, see for illustration the component definition in Fig. 4. We have enhanced the iPOJO design-time tools to handle the specific annotations required to declare specialized context concepts (for example, annotation @ContextEntity in Fig. 4 allows specifying a context entity with a set of state properties).

Sensors/actuators are represented as services. This is transparently managed by iPOJO and RoSe [START_REF] Bardin | Towards an automatic integration of heterogeneous services and devices[END_REF], as we will see in the implementation section. These facilities, along with the use of annotations to declaratively define the components, enable to keep the code at an abstract level, close to the conceptual problem space. Moreover, because context entities are themselves components, they can provide business services that can be easily discovered and consumed by the applications, thus facilitating context utilization.

Notice that facilities to actually instantiate the component, publish the provided service in the service registry, discover and select the required services are automatically provided by the iPOJO framework at runtime, without cluttering the application code.

Let us illustrate this on the Light Follow Me scenario. To model a lighting device, we can define an entity characterized, in particular, by a serial number and a property indicating the current state (on or off).

Fig. 4. Java code for a context entity component

The corresponding iPOJO component is shown in Fig. 4: the component is implemented by class BinaryLightContextEntityImpl (marked as a @Component, and concretely a @ContextEntity) that provides (line 2) and requires (line 15-18) services (in this case, we require a reference to the physical actuator that allows to control the light). The example also shows a @Pull synchronization function (line 20-23) that will be invoked periodically (every 30 seconds) to keep the context property BINARY_LIGHT_POWER_STATUS updated with the last value from the physical sensor. Similarly, it shows a @Set function (line 25-30) that will be invoked each time an application changes the value of the state property, to propagate it to the environment, using the appropriate physical actuator.

Likewise, spatial zones can be represented by another entity. These entities can further be enriched by adding relations. For example, relating a light with a room will provide an additional location state for the light. The main interest of clearly separating entity and relation is to enhance the extensibility of our system. At runtime, the platform will dynamically build a graph of instances of the defined components to represent the current state of the environment.

B. Runtime support

Our framework has been designed to be integrated in the operational pervasive platform iCasa [START_REF] Lalanda | Servicebased architecture and frameworks for pervasive health application[END_REF]. iCasa supports the execution of dynamic Java applications, on top of the OSGi service platform and the iPOJO service-oriented component model [START_REF] Escoffier | iPOJO: an extensible serviceoriented component framework[END_REF]. The iCasa infrastructure offers various technical services necessary to develop pervasive applications, like task scheduling, event management or autonomic managers. However, iCasa currently focuses only on developing pervasive applications, and does not provide specific tools to handle dynamic and extensible context management. Because context components are iPOJO components, they can be directly packaged and deployed to the iCasa platform. However, the iPOJO runtime must be extended to handle the newly added context-related functions. The iPOJO framework is based on the concept of runtime containers, in charge of the life-cycle of components, as depicted in Fig. 5. Containers use bytecode instrumentation to take full control of the execution of the component: they can, for example, instantiate objects, intercept method invocations or field accesses.

Component containers can be extended by iPOJO modules, called handers. The framework provides a number of off-theshelf handlers in charge of global aspects of the platform, like service publishing or dependency injection. More importantly, as shown in Fig. 5, it is possible to develop new iPOJO handlers to take charge at runtime of particular concerns.

We implemented two new iPOJO handlers dealing with specific context concerns. The handlers are described as follow:

• Synchronization Handler: It is in charge of dealing with the state synchronization of entity components. It keeps the state properties up-to-date by managing the synchronization functions. Different strategies can be specified to do so. For example, the handler can periodically call pull functions or just wait for push callbacks to keep the state up-to-date. Additionally, the handler is in charge of publishing state properties as service properties. This publication has two main interests. It allows processing of more advanced filters and state updates can be reported to the application without the burden of an Observer pattern, by relying on iPOJO notification mechanism. • Relation Handler: It is in charge of dealing with relations and extending properly the state of an entity. It tracks and filters all the relations targeting its attached entity component. If an instance of entity disappears (e.g. a light is removed from a house), associated relations and linked state extensions are automatically invalidated and deleted.

VI. IMPLEMENTATION AND APPLICATION

In order to validate the framework, we developed the Light Follow Me application; it corresponds to the scenario previously described in part III. Fig. 6 shows an overview of the application on the iCasa simulator. This is a typical pervasive scenario in which the light must "follow" the user (simulation shown in the left part of Fig. 6). The idea is simple but the implementation fulfilling pervasive needs is complex. Indeed, it is not an easy task to model the relevant concepts as a whole and not independently. I). Inevitably, formally building the context adds an additional development task and the resulting architecture is more complicated. However, it's easier to implement applications on top of it. The context is shared among applications, is extensible, and can be adjusted to fit new needs. The whole software is more consistent, testable and maintainable.

VII. RELATED WORK

Developing context-aware applications is one of the hot research topics for the last decade. Naturally many software architectures emerged to reach this goal. We compare our proposed architecture to the existing ones: The Context Toolkit [START_REF] Dey | Understanding and using context[END_REF], COSMOS [START_REF] Conan | Scalable processing of context information with COSMOS[END_REF], SOCAM [START_REF] Gu | A service-oriented middleware for building context-aware services[END_REF] and another SOC-based context model [START_REF] Vansyckel | Extending context management for proactive adaptation in pervasive environments[END_REF]. Many more architectures are available, but these ones are representative of the global trend.

The Context Toolkit promotes code-reuse through the composition of distinct artifact called widgets to build the context. These widgets are used to hide the complexity of sensors and abstract context information in a suitable way to fit applications need. These reusable blocks are explicitly linked at design-time, each block deciding which blocks to use. Our approach is similar in the sense that we divide the context in individual small pieces. The key differences with our work are that we delegate the composition at runtime with more variability expressed at design-time thanks to SOCM properties. Moreover our entity relation like model offers more flexibility to design complex context. COSMOS, COntext entitieS coMpositiOn and Sharing, is a component based context middleware. Each pieces of context is reified as a component called Context Node organized in a hierarchical structure. This approach and ours address the separation of concerns by offering several built-in mechanisms like push/pull notifications and reduce the developer's work. However, the strictly hierarchical approach of COSMOS context makes difficult to model it with horizontal relation. Moreover, component specifications are strictly defined at design-time, so runtime extensibility proposed by our system of relation will be hard to achieve.

The Service-Oriented Context Aware Middleware (SOCAM) is an ontology based context middleware. SOCAM architectures relying on several components: Context Providers (extracting context from internal and external data sources, and converting them in ontological instance), Context Interpreter (reasoning engine performing inference to extract high-level context and store it in knowledge base), Context-aware Mobile Service (application that consume context), and Service Locating Service (a registry where provider and interpreter are registered, where other components can search specific providers or interpreters to fit their needs). SOCAM envisions a highly structured context model with ontology in order to benefit from all the powerful processing tools induced by this approach, like reasoning engine. So it generates a programming model through a query language and rules, contrary to our programming model that relies on Java services specifications that we consider more adapted to develop addedvalue services.

In [START_REF] Vansyckel | Extending context management for proactive adaptation in pervasive environments[END_REF], a work dealing with proactive adaptation and context management based on a SOCM architecture is presented. It underlines the fact that context interactivity is not just about providing the most powerful modeling and reasoning engine. Indeed, applications also can deal with context in a proactive manner, with the ability to change the context through actuators. Our approach, in this sense, is very similar because previous works say little about how to influence context. However, to achieve this goal, a specific query language that generates a cost on the learning curve is provided, whereas we prefer a traditional Java programming model.

VIII. CONCLUSION

In this paper we presented a comprehensive approach to build and run context that specifically addresses fundamental concerns like gathering, modeling, processing and disseminating information. This solution can be integrated in an enriched execution platform as demonstrated. Our work focuses on providing tools to build and execute a runtime extensible model of context. This model is synchronized with external entities and can be enriched dynamically by new relations or entities. Applications developed using SOC paradigm upon this model can also dynamically add new elements in the context in order to better fit their needs.

So far, we have focused on feasibility of the approach, so a number of limitations remain, especially at the implementation level. While the model is extensible at runtime, applications can only access extended entities using a generic API, losing all usability advantages of Java strong typing. Moreover, our runtime implementation currently maintains a possibly large, in-memory, representation of context. Additional performance optimizations are required to cope with the needs of realistic applications, in terms of memory scalability and footprint.

Further perspectives of our work include extensions to handle more complex synchronization scenarios. Particularly, the platform should support developers to handle automatic creation of application-specific entities and relations. We argue that the usage of software engineering tools, like the proposed domain-specific context language, can provide an adapted support for this case.

Fig. 1 .

 1 Fig. 1. iCasa simulator

Fig. 2 .

 2 Fig. 2. Overall apporachThe first step, called Domain Engineering, can actually be complex and may involve several persons with different skills. The tasks to be performed are the following:• Identify and determine the necessary concepts to be included in the context. • Define the context per se (entities and relations between them) in conformance with a meta-model. • Select and integrate the communication drivers to access real devices at runtime.

  Entity represents a concept of the context, characterized by a finite set of state properties. • Relation represents a binary relationship between entities in the context. This relation allows the context to be navigated by applications. It also enables to extend the definition of an entity through the extraction of state property values from a related entity.

Fig. 3 .

 3 Fig. 3. Context metamodel

Fig. 5 .

 5 Fig. 5. Simplified example of context model -Component and service view

Fig. 6 .

 6 Fig. 6. Light Follow Me application -iCasa simulator overviewOur framework gives an understandable representation of the global context. The bottom right corner of Fig.6presents the graph of the model displayed on the iCasa simulator: devices are gathered by location, each room is enhanced with a physical parameter aggregating and synthesizing presence status, and an independent entity provides the moment of the day. In addition of the graph view, the simulator can display state properties and state extensions of an entity. This functionality is shown on Fig.7with light_A. Both reflect data at runtime.

Fig. 7 .

 7 Fig. 7. Light Follow Me application -zoom on the kitchen Our framework gives significant results from application development perspective (see TABLEI). Inevitably, formally building the context adds an additional development task and the resulting architecture is more complicated. However, it's easier to implement applications on top of it. The context is shared among applications, is extensible, and can be adjusted to fit new needs. The whole software is more consistent, testable and maintainable.

have identified the main concerns that context middleware must handle and current techniques: • Context gathering: There are varieties of data sources to be exploited with specific acquisition

	• User environment, including current location, needs,
	situation, activity, preferences, etc.
	• Physical	environment,	including	temperature,
	luminosity, ambient noise, humidity, etc.
	Entities are domain specific. Indeed, context is developed
	for a unique purpose: building applications. Previous works
	[16] [17] [18] processes
	(single/double way) and synchronization mechanisms.
	• Context modeling: Context is primarily a model of the
	environment. Many methods can be used to represent
	knowledge such as Key-Value, OO model, logic based
	model ontology or hybrid approach that combine
	precedent previous approaches.
	• Context processing: To ease application development,
	low-level entities like device state are not sufficient.
	Operations like inference, mediation, aggregation, or
	enrichment are needed to get higher-level information.
	• Context dissemination: Applications need to retrieve
	and interact with context information through queries
	or programming APIs for instance.

TABLE I .

 I LIGHT FOLLOW ME APPLICATION IMPLEMENTATION STATISTICS

Implementation Statistics Application impl. Number of LOC a for the moment of the day impl. Total number of LOC a Number of LOC a per component

	Initial impl.	829	581	95
	Impl. with our framework	623	217	107
	Framework improvement	25%	62%	-13%

a. LOC: Lines Of Code

http://self-star.imag.fr