Brice Morin

Olivier Barais

Grégory Nain

Jean-Marc Jézéquel

Taming Dynamically Adaptive Systems Using Models and Aspects *

Since software systems need to be continuously available under varying conditions, their ability to evolve at runtime is increasingly seen as one key issue. Modern programming frameworks already provide support for dynamic adaptations. However the high-variability of features in Dynamic Adaptive Systems (DAS) introduces an explosion of possible runtime system configurations (often called modes) and mode transitions. Designing these configurations and their transitions is tedious and error-prone, making the system feature evolution difficult. While Aspect-Oriented Modeling (AOM) was introduced to improve the modularity of software, this paper presents how an AOM approach can be used to tame the combinatorial explosion of DAS modes. Using AOM techniques, we derive a wide range of modes by weaving aspects into an explicit model reflecting the runtime system. We use these generated modes to automatically adapt the system. We validate our approach on an adaptive middleware for homeautomation currently deployed in Rennes metropolis.

Introduction

Society's increasing dependence on softwareintensive systems is driving the need for dependable, robust, continuously available adaptive systems. Such systems often propose many variability dimensions with many possible variants, leading to a wide number of possible configurations that is difficult to integrally check at design-time because of time and resource constraints. For example, associations and public institutions of the metropolis of Rennes are working together on a project which aims at allowing dependent people to stay at home as long as possible. Due to the large scale of the project, and the diversity of disabilities that have to be considered, the deployment context will be different for each equipped house. Furthermore each deployment context is going to continuously evolve along with the evolution of the person's disabilities.

This ability to evolve a system at runtime is one critical aspect of achieving continuously availability. Many popular programming frameworks such as OSGI [START_REF]OSGi Service Platform Core Specification, Release 4.1[END_REF] or Fractal [START_REF] Bruneton | The FRACTAL Component Model and its Support in Java. Software Practice and Experience, Special Issue on Experiences with Auto-adaptive and Reconfigurable Systems[END_REF] now provide support for dynamic adaptation through extension mechanism such as plugins or variability mechanism through introspection and reconfiguration API. However the high variability of crosscutting and non-crosscutting features in adaptive systems introduces an explosion of possible runtime system configurations (often called modes). When new features are introduced at deployment time (vs. design time), we also have to make sure that they do not lead the system into unwanted modes. Besides, due to the fact that features are often partially independent, the (implicit) state-machine representing the path between modes is highly connected, leading to a nearly quadratic explosion of transitions between modes [START_REF] Bencomo | Genie: Supporting the Model Driven Development of Reflective, Component-based Adaptive Systems[END_REF][START_REF] Zhang | Model-based Development of Dynamically Adaptive Software[END_REF]. The inefficacy of the variability and extension mechanisms to tame the high-number of modes transitions might lead to several undesirable consequences related to Dynamically Adaptive System maintainability, including partial duplication of reconfiguration scripts or the noncover of all the modes transition, etc.

Aspect-Oriented Modeling (AOM) was initially introduced to improve the modularity of software [START_REF] Figueiredo | Evolving software product lines with aspects: an empirical study on design stability[END_REF][START_REF] Mezini | Variability Management with Feature-Oriented Programming and Aspects[END_REF], complementary to Model Driven Engineering (MDE) to link models to the real world [START_REF] Jézéquel | Model Driven Design and Aspect Weaving[END_REF]. In [START_REF] Morin | An Aspect-Oriented and Model-Driven Approach for Managing Dynamic Variability[END_REF], we have proposed a first approach that leverages AOM and MDE to manage variability at runtime. It relies on the notion of aspect models, that can be woven into an explicit model of the runtime configuration seating on top of the running system. Actual mode switches between runtime configurations are then triggered by reconfiguration scripts automatically generated based on the differences between the initial model and the newly woven one. The result of this approach is that modes becomes somehow implicit from the point of view of the system designer, and new modes can appear when new aspects are introduced during the life of the system. It is thus no longer possible to statically validate every accessible mode and each mode transition.

In this paper, we show how aspects can help designers determine interactions between dynamic variants and how runtime models can be used to validate new configurations on the fly, before committing them on the running system (making it easy to roll-back when a configuration is not valid). Indeed, once the system has been deployed, new variability dimensions and variants that have not been foreseen may appear while the system is running and cannot be stopped. In this case, it is very useful to validate configurations on the fly before actually adapting the running system.

The reminder of this paper is organized as follows. Section 2 describes the general process for managing dynamic variability. Section 3 presents how we leverage AOM and MDE techniques and tools to determine interactions and validate configurations on the fly. Section 4 outlines how our approach was validated in a home-automation context deployed in the metropolis of Rennes. Section 5 discusses related work and section 6 concludes by presenting a set of open research problems based on our experience.

Process Overview

This Section presents our approach for managing variability at runtime [START_REF] Morin | An Aspect-Oriented and Model-Driven Approach for Managing Dynamic Variability[END_REF]. The overall process is described in Figure 1.

Maintaining a High-Level Representation of the Running System

Maintaining a model at runtime [START_REF] Bencomo | Models@run.time[END_REF] representing the running system (Figure 1, step 1) allows us to reason on the model and manipulate the model independently from the running system. Using high-level abstractions, we can discard all the platform-specific runtime information we do not need and reason more easily and more efficiently in the next steps of the process.

Figure 1. MDE and AOM for Dynamic Adaptation

Recent component-based middleware platforms like OSGi [START_REF]OSGi Service Platform Core Specification, Release 4.1[END_REF] propose introspection APIs that allows discovering the architecture of a running system. We use these APIs to collect and format relevant information in the form of a platform-independent and high-level model. In the case of large systems, using introspection in order to generate a reference model from scratch may be time-consuming especially when only small changes appear. To tackle this issue, we observe the architectural reconfigurations appearing in the running system in order to update the model. This limits the flow of data manipulated in the system. Moreover, recent middleware platforms already propose this kind of observers or propose mechanisms to easily implement such kind of observers [START_REF] Blair | Opencom v2: A component model for building systems software[END_REF][START_REF] Bruneton | The FRACTAL Component Model and its Support in Java. Software Practice and Experience, Special Issue on Experiences with Auto-adaptive and Reconfigurable Systems[END_REF]. Note that the changes that may affect the source model are not directly reflected to the running system.

On-demand Construction of Configurations with Aspects

In order to manage variability and avoid the combinatorial explosion of artifacts needed to support this variability, we propose to focus on variation points and variants instead of focusing on whole configurations. A variability dimension is a particular concern that may be realized in different ways. We use as-pects to represent the different variants of a variation point. Using Aspect-Oriented weavers, whole configurations can be built on-demand by selecting a set of aspects as illustrated in Figure 1, step 2. In practice, we use SmartAdapters [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF][START_REF] Morin | Managing Variability Complexity in Aspect-Oriented Modeling[END_REF] an Aspect-Oriented Modeling (AOM) tool for weaving aspects at a model level. However, the approach presented in this paper is not dependent from SmartAdapters and other AOM tools like MATA [START_REF] Jayaraman | Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis[END_REF] could also be used. Components present in all the configurations constitute a base model where aspects are woven.

SmartAdapters has formerly been applied to Java programs and UML class diagrams [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF]. More recently, we have generalized this approach to any domainspecific modeling language [START_REF] Morin | Towards a Generic Aspect-Oriented Modeling Framework[END_REF]. This allows us to leverage the notion of aspect for runtime models representing at a high level of abstraction the architecture of a system at runtime. SmartAdapters automatically generates an extensible Aspect-Oriented Modeling framework specific to our metamodel.

In SmartAdapters, an aspect is composed of three parts: i) an advice model, representing what we want to weave, ii) a pointcut model, representing where we want to weave the aspect and iii) weaving directives specifying how to weave the advice model at the join points matching the pointcut model. The advice model is a model fragment representing a given concern. In our case, it represents a pre-assemby of components that may not be fully specified. The pointcut model is also a model fragment that is parameterized by roles (See [START_REF] Ramos | Matching Model Snippets[END_REF]), equivalent to wildcards in AspectJ pointcuts [START_REF] Kiczales | An Overview of AspectJ[END_REF][START_REF] Kiczales | Aspect-Oriented Programming[END_REF]. Both the advice model and the pointcut model are defined using the concrete syntax of the domain. Finally, weaving directives specify how to integrate the advice model into the target model, using a generated domain-specific action language [START_REF] Morin | Towards a Generic Aspect-Oriented Modeling Framework[END_REF].

We (optionally) extend each aspect with a context describing when to trigger the weaving of aspects. A context is a slice of the environment describing when the aspect is useful and its impact on QoS properties. For example, a buffering aspect can optimize the bandwidth of the network if the system has enough free memory (e.g. > 512 Mb) and if the bandwidth is saturated (e.g. > 90%). Aspects with a context are chosen according to the execution context and the QoS properties to optimize [START_REF] Fleurey | Modeling and Validating Dynamic Adaptation[END_REF]. Aspects with no context can be manually triggered by the user.

Figure 2 illustrates an internalization (I18N for short) aspect. The pilot of the case study is currently deployed in Rennes. Rennes is an international city hosting many students from different countries where lots of different languages are spoken. Within a single day, people from different countries may transit in the home. Systematically translating all the information in all the possible languages may cause an information overhead that could make information difficult to catch. This is why internationalization should be handled dynamically.

In order to design this aspect, we leverage the ability of SmartAdapters to integrate variability into aspects [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF]. Indeed, each language (EN, FR, DE in Figure 2) is considered as a variant. The behavior of the advice can be described as follows. The I18N interface provides a set of methods responsible for translating a pre-defined set of labels. It also provides a lookup method get(String myString): String that returns, if possible, the translation of myString for a given language. In a component (e.g., FR), if the lookup method cannot translate a word, the component ask the dispatcher to find a translation for this word. The dispatcher will ask the components according to a predefined policy (e.g., EN first if available). If the word exists in the local database, it is translated (e.g., from English to French) thanks to the translator that sends a request to a website dedicated to translation. Note that in the advice, all the components and bindings are unique (depicted with a '1' in the Figure ). This means that even if there exist multiple join points and/or even if the aspect is applied several times, these elements will only be woven once in the base model. In the composition protocol, the bindings are not unique and will be introduced for all the identified join points. The pointcut simply identifies any component that requires the I18N interface, with no more assumption. The weaving process has 2 steps: matching (or join point detection) [START_REF] Ramos | Matching Model Snippets[END_REF] and composition. In our example, the matching step detects all the components that require the I18N interface. Then, the composition step binds the I18N server interface provided by the advice to the client interfaces of the join points. When an aspect is being composed, the inverse composition protocol is automatically generated. It allows us to easily unweave an aspect when it is not longer adapted to the context.

After some aspects have been woven into the source model, the target model we obtain is validated, as illustrated in Figure 1, step 3. We will present in more details this validation step in Section 3.

On-the-fly Generation of Reconfiguration Scripts

As mentioned by Zhang and Cheng in [START_REF] Zhang | Model-based Development of Dynamically Adaptive Software[END_REF], if there exists N possible configurations, this may lead to N(N-1) possible transitions. If N is large, it rapidly becomes difficult to handle these transitions by hand.

Figure 2. I18N aspect

In a traditional model-driven development, models are refined and transformed step by step down to source code. If some changes appears in the requirements, it is possible to propagate these changes to the models and regenerate the source code in order to rapidly propose a new version of the system. In the context of adaptive systems, it is not possible to adopt this schema. Indeed, such systems should offer continuous services and cannot be stopped, regenerated and restarted. The system should keep executing while being reconfigured from one configuration to another.

Once a target model (representing the system we want to reach) is created and validated, it is compared with the source model (representing the actual architecture of the running system). In the current implementation of our tool, we use EMF Compare 1 in order to compare models. It produces a diff and a match model that specifies the differences and the similarities between the source and the target models, as illustrated in Figure 1, step 4. The comparison engine is generic, so it is possible to compare any kind of models. The algorithm is quite similar to the algorithm proposed by Nejati et al. in the context of statechart specifications [START_REF] Nejati | Matching and Merging of Statecharts Specifications[END_REF]. It considers the properties of each model element as well as its neighbors in order to compute a similarity degree. Note that it is possible to customize the comparison engine to consider the specificity of a given domain metamodel. However, the generic engine provides sensible results for our metamodel describing runtime architecture, with no customization.

Then, we automatically analyse both diff and match models to obtain the relevant changes between the source model and the target model e.g., addition/removal of components/bindings, changes of attribute 1 See http://www.eclipse.org/modeling/emft/ values, etc. However, it is not possible to adapt the running system during this analysis. For example, if the model comparison detects a component removal before a binding removal, directly adapting the system would lead to a dangling binding that might not be allowed by the underlying execution platform.

In order to tackle this issue, we reify each significant modification as a reconfiguration command during the analysis (Figure 1, step 4). Each command implements an atomic platform-specific reconfiguration (adding and/or removing bindings and/or components, etc.) and declares a priority. We first stop the components that have to be stopped and then remove bindings before removing components. We add components before adding bindings and finally restart the components that should be restarted. When the analysis of the model comparison is achieved, we execute the ordered sequence of commands to actually adapt the running system in a safe way (Figure 1, step 5). This set of commands is the transition that transforms the source system into the target system. Depending on the execution platform we use (e.g., OSGi, Fractal or OpenCOM) a factory will instantiate the corresponding commands.

Validating Target Configurations

In Section 2, we showed how we can obtain configurations by weaving some aspects into a base configuration. Using aspect models, instead of directly adapting the running system using low-level reconfiguration scripts [START_REF] David | An Aspect-Oriented Approach for Developing Self-Adaptive Fractal Components[END_REF] allows us to reason more easily and help designers in identifying interactions between aspects [START_REF] Jayaraman | Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis[END_REF]. More details about aspect interaction detection are given in Section 3.1.

Then, we showed how to generate reconfiguration scripts to make the running system evolve from a source configuration (the current configuration), to a target configuration. However, in the context of adaptive systems, we should ensure that the target configuration we want to reach makes sense. This is why we do not directly reflect the changes appearing in the source model to the running system. When the number of configurations is limited, for example in the case of critical embedded systems, it is possible to validate at design time all the possible configurations [START_REF] Zhang | Model-based Development of Dynamically Adaptive Software[END_REF]. However, in larger-scale adaptive systems, this systematic validation may become too time and resource consuming to be realistic. Moreover, once the system has been deployed, new variation points that have not been foreseen may appear while the system is running and cannot be stopped. In this case, it is very useful to validate configurations on the fly before actually adapting the running system. This is detailed in Section 3.2.

Detecting Aspect Interactions

In Section 2 we introduced an internationalization aspect. Most of the aspects of our case study (see Section 4) and most of the components of the base system (for example, GUI) also needed this aspect. Weaving the I18N aspect before the other aspects may cause some important messages not to be translated. Using techniques like Critical Pair Analysis (CPA) allows us to detect interaction between aspects [START_REF] Jayaraman | Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis[END_REF]. Basically, if the pointcut of an aspect A1 can be matched in the advice of another aspect A2 it means that A2 introduces some join points for A1. In other words, A1 should be woven after A2 in order to be able to consider newly introduced join points.

For example, let us introduce a second aspect responsible for preventing devices deployed in the house (lights, electric shutters, etc) to be damaged due to too many successive transitional regimes. This aspect, called event filter, will ignore all the antagonist actions that appears in a too short period. All the events sent to the unstable device controller by the device proxy are derived into the event filter component. These events are cached during a given period that depends on the type of the device. Events are delegated to the device if no antagonist events appeared during the cache period. These filters cannot be systematically deployed as they make devices less reactive in standard conditions. This is why filters should be dynamically and locally deployed and undeployed. Every canceled actions has to be logged and displayed in a language the user understand, using the I18N interface. As the event filter aspect introduces a component that requires the I18N interface, it introduces a new join point for the internationalization aspect. Consequently the I18N aspect should be woven after the event filter aspect.

Figure 3. Event Filter aspect

This kind of basic analysis can help designers in identifying interactions that cannot easily be detected when directly working with low-level reconfiguration scripts. However, CPA has limitations. For example, this kind analysis is not associative. If no interaction exists between A1 and A2 and no interaction exists between A1 and A3, nothing ensures that there exists no interaction in the triplet {A1, A2, A3}, depending on the weaving order. Determining the interactions that may exist in all the possible subsets of aspects is very complex as the number of combinations grows rapidly.

Validating Target Configurations

As explained in the introduction of this section, it is not always possible to check all the possible configurations of an adaptive system a priori, for time and resource issues. Moreover, the apparition of unforeseen adaptation while the system is already deployed makes it impossible to perform all the validation process at runtime. However, in the context of high-insurance adaptive systems [START_REF] Mckinley | Harnessing digital evolution[END_REF] any configuration we wanted to reach should be validated.

In order to validate target configurations (Figure 1, step 3), we propose to define some invariants on the metamodel we use to represent runtime architecture and check these invariants for every constructed (by aspect weaving) target configuration. These invariants are expressed as Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF] meta-aspects that are woven into the metamodel we are using for representing runtime architecture. Kermeta meta-aspects can be used to refine existing meta-classes by integrating contracts (pre/post-conditions, invariants), attributes and references, operations and super-classes. The invariant illustrated in Figure 4 specifies that all the client and non optional ports defined in the component type of the component should be bound. In other words, it detects if mandatory bindings are missing. It uses an OCL-like syntax2 which provides high-level operators for navigating and querying models: select, exist and forall in our example. Another invariant checks that the server interface of a binding is a sub-type of the client interface. Currently, six invariants are woven into our metamodel. Note that end-user can define more specific invariants to ensure the validity of the configurations.

Invariant checking, as well as the steps related to aspect weaving and aspect interaction detection, can be performed on a tiers system, independent from the running system itself. Indeed, all the models (metamodel, configurations and aspects) can be serialized in XML and transmitted to other systems.

Figure 4. Checking mandatory bindings

Another possible solution to validate target configuration before actually adapting the running system would be to simulate models. This can be done by describing the behavior of each configurations, for example using state machines or Petri nets [START_REF] Zhang | Model-based Development of Dynamically Adaptive Software[END_REF]. Then, it would be possible to use Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF] to execute these models and perform the simulation and detect deadlocks, for example. However, in order to manage the explosion of variants, this behavior should be associated to each aspect and should be composable in order to obtain the behavior of whole configurations. SmartAdapters is well adapted to compose structural aspects, in class or component diagrams. However, to consider the semantic of behavioral models, it has to be customized by hand. Another solution would be to use a specific aspect weaver dedicated to the composition of behavioral models. Such an approach is presented in Section 5 and its integration with our approach is discussed in perspectives.

If the target configuration we want to reach is valid, then the process continues, as illustrated in Figure 1, step 4, in order to actually adapt the running system. If the target configuration is not valid, then our rollback mechanism simply consists in discarding this target configuration and do not submit it to the following steps of the process. Indeed, as the modification on the model are not directly reflected to the running system, we do not have to cancel platform-level reconfigurations. An error report is automatically raised by Kermeta [START_REF] Muller | Weaving Executability into Object-Oriented Meta-languages[END_REF], specifying which invariants are violated by the target configuration. This helps the system or the user in understanding why the configuration is not valid. For example, if we consider that the I18N client port is mandatory, then we are able to detect the cases where the I18N has been woven before (or not at all) other aspects, without using the preliminary critical pair analysis. Indeed, the invariant illustrated in Figure 4 detects missing mandatory bindings. This case

Application to Home-Automation

EnTiMid to help people to stay at home

Industrials, associations and public institutions of the metropolis of Rennes, are working together on a project which aims to allow dependent people to stay at home as long as possible. Due to the large scale of the project, and the diversity of disabilities that have to be considered, the deployment context will be different for each equipped house. The technologies used will vary, in order to compensate handicaps or because a technology is already installed, and people do not want it to be removed. Moreover, the system installed in these houses will have to provide a remote access to the devices of the house, and transmit all the necessary information from the sensors of the house to a control center where information will be treated. Those access and transmissions can be realized through various ways (Internet, POTS, SMS) and the medium used will vary according to the availabilities.

An abstraction layer over all these devices has been developed in the form of a multi-facet middleware called EntiMid [START_REF] Nain | Using MDE to Build a Schizonfrenic Middleware for Home/Building Automation[END_REF]. Based on an OSGi platform [START_REF]OSGi Service Platform Core Specification, Release 4.1[END_REF], EnTiMid is composed of different components (called bundles), that can be dynamically added, removed, started or stopped, with no need to restart the entire system. Each of them can offer or require services to/from other ones, but such services can disappear at any time. One of those services, identified as Tech-Provider, aims at translating the information caught from a device network protocol, into EnTiMid standard event messages, and vice versa. By this way, high level services can manage devices through unified messages, whatever the underlying technology is. EntiMid allows engineers to prescribe the most adapted technology, with no regard to the communication technology it uses. Then high level services can be developed to offer different kind of services to inhabitants and health professionals. For example, automatic energy, heating, access or light management to ease the everyday life; remote control and alert transmissions, to allow professionals to intervene on the house, in a short time, according to the information collected.

A show apartment will soon be available, and En-TiMid will be deployed in order to test its functionalities with devices installed by industrials. Those real conditions will have for consequence an identification of new needs of development and variability.

Designing Variability Dimensions

We now introduce and justify the need for dynamic variability in our case study. Each variability dimension is represented by a set of aspects designed with SmartAdapters.

Device Management. Physical devices are managed by EnTiMid. Most of the devices are installed when the system is deployed. However, new physical devices may be installed after the initial deployment and consequently, they should be managed dynamically while maintaining the functionalities offered by already deployed devices. In our case study, we have to manage 6 lights, 4 heaters, 3 mixing valves (controlling water temperature) and 3 electric shutters. Moreover, depending on the evolution of the patient, devices should be managed in different ways. For example, in the case the patient becomes visually impaired, the power of the lights should be increased by 10%. Another focus can be the evolution of a mobility handicap. In a first stage, the patient can move alone in the house, allowing him to manually close the shutters. Then the evolution of the disease makes it difficult for the patient to get out of his bed. A remote control will then be offered to this person to ease his everyday life, and the control system of the house have to adapt to this situation.

Each low-level protocol (KNX 3 , X10, X2D 4 , etc) manages devices in an ad-hoc way. Consequently, we would have to define a variability dimension for each protocol. For the sake of clarity, we present one generic variability dimension that harmonizes the concepts present in each low-level protocol. It is illustrated in Figure 6. In order to represent this variability dimension, we leverage the ability of SmartAdapters to integrate variability into aspects [START_REF] Lahire | Introducing Variability into Aspect-Oriented Modeling Approaches[END_REF]. Each type of device controller (Light, Heater, Shutter and Mixing 3 http://www.knx.org/ 4 http://www.english.deltadore.com Valve) is a variant. Each type of component can be instantiated several times. Each device also offers an interface for loading pre-defined scenarios. All the device controllers are connected to a device proxy that receives messages from the EnTiMid platform and dispatches these messages to the appropriate device.

Figure 6. Device Management aspect

Permission Management. All the physical devices in the house are supposed to be potentially controlled by EnTiMid. However, doctors can choose for each device whether it is controlled by the system or by the patient, according to the degree of autonomy of the patient. If the device has no permission manager, the patient can interact with the device. With a permission manager, the patient cannot interact with the device that only follows a pre-defined scenario.

The permission management aspect illustrated in Figure 7. In order to control the access from the user, an aspectual component [START_REF] Pessemier | A Component-Based and Aspect-Oriented Model for Software Evolution[END_REF] intercepts, using an AspectJ-like pointcut, every call to the services of the controller, log each attempt and does not proceed. The device will simply execute its pre-defined scenario without being interrupted.

Figure 7. Permission Management aspect

Two other aspects (internationalization and event filter) have already been introduced in previous sections.

Constructing a Configuration by Aspect Weaving

We are now going to propose to illustrate the weaving process with some of the aspects we have identified in the previous sub-section into our motivating example (Figure 8). The top of the figure illustrates a snippet of the base configuration. It allows to access low-level devices using two high-level protocols: UPnP5 and DPWS6 , via the EnTiMid component. In the bottom part of the figure three aspects have be woven: a filter aspect that filters the events send to Light1 ; two permission managers that restrict the heater and the shutter to their pre-defined scenarios. Finally, the internationalization aspect is woven. The interaction between the aspects can be observed in the example: the event filter and the permission manager aspects uses the internationalization aspects.

With the five variability dimensions we have defined earlier in this section, we can obtain a wide range of possible configurations. If we consider the three aspects that directly impact devices (device management, permission management and event filter), we obtain five possible modes for each device, as shown in Table 2, where 0 indicate that the aspect is not active for the device. As the devices are managed independently, this leads to 5 16 ≈ 15 • 10 10 possible configurations. This number is even greater if we consider the internationalization aspect.

If we consider the 15 • 10 10 possible configurations, we obtain approximately 225 • 10 20 possible transitions from one configuration to another. The configurations are obtained on-demand: the weaving of some aspects can be triggered by hand depending on the choices of a human operator (doctor or technician), while some other aspects (e.g., event filter) are triggered by the context. Before adapting the system, all the invariants

Related Work

In [START_REF] Zhang | Model-based Development of Dynamically Adaptive Software[END_REF], Zhang and Cheng propose to adopt a modeldriven approach for designing and validating dynamically adaptive software systems. This approach focus on the behavior of adaptive systems whereas we mainly focus on the architecture of running systems. In [START_REF] Zhang | Model-based Development of Dynamically Adaptive Software[END_REF], the behavior is modeled with state-based diagrams like Petri nets. Zhang and Cheng define an adaptive system as a set of simple adaptive systems. A simple adaptive system is defined by three entities: a source system, a target system and transitions responsible for moving the source system to the target system. All the source systems, target systems and transitions should be explicitly modeled, leading to an explosion of artifacts needed to manage an adaptive system. However, this exhaustive representation allows validating intensively the system at design time. Finally, using code generation, adaptive programs are derived from the models. In our approach, configurations are constructed on demand by selecting and weaving a set of aspects. Once composed, it is possible to check the target configurations we want to reach. Then, the transitions needed to adapt the system is automatically generated using model comparison.

In [START_REF] David | An Aspect-Oriented Approach for Developing Self-Adaptive Fractal Components[END_REF], David et al. present SAFRAN (Self-Adaptive FRActal compoNents) an Aspect-Oriented approach for implementing self-adaptive system on the Fractal [START_REF] Bruneton | The FRACTAL Component Model and its Support in Java. Software Practice and Experience, Special Issue on Experiences with Auto-adaptive and Reconfigurable Systems[END_REF] platform. In order to adapt the system, they define adaptation policies, separately from the business logic, which follow this pattern: when <event> if <condition> do <action> where actions are lowlevel reconfiguration scripts. Batista et al. [START_REF] Batista | Managing Dynamic Reconfiguration in Component-Based Systems[END_REF] propose the same kind of approach for the OpenCOM [START_REF] Blair | Opencom v2: A component model for building systems software[END_REF] execution platform. These approaches do not propose an explicit representation of the target configurations. Consequently, it is not possible to easily visualize the system nor to perform validation, simulation before actual adaptation. In our approach, configurations are obtained by weaving aspects into a model representing the current system. Woven configurations are checked against invariants. We then generate all the adaptation logic needed to adapt the system while these approach have to specify low-level reconfiguration scripts. Moreover, our approach is not specific to a given ex-ecution platform. Finally, script-based approach do no offer support for easily determining interactions between reconfiguration scripts while Aspect-Orientation provides some mechanisms [START_REF] Jayaraman | Model Composition in Product Lines and Feature Interaction Detection Using Critical Pair Analysis[END_REF].

Ensuring software correctness is an important issue and this is amplified when dealing with software variation . Correctness is even more important in Dynamically adaptive System where variation is handled at runtime. This issue has been addressed by the software product lines community [START_REF] Pohl | Software Product Line Testing[END_REF][START_REF] Svahnberg | Issues Concerning Variability in Software Product Lines[END_REF]. One of the main concerns for correctness in product lines is about the methods to be used in order to limit the number of tests to be performed for a family of products. Two issues are especially considered: the increase of work for the programmer and the time spent to perform them [START_REF] Cohen | Coverage and Adequacy in Software Product Line Testing[END_REF][START_REF] Mannion | Theorem Proving for Product Line Model Verification[END_REF]. These contributions mainly introduce formal methods in order to exploit the commonalities of a software family in order to achieve these issues. They rely on SAT solver [START_REF] Czarnecki | Verifying Feature-Based Model Templates Against Well-Formedness OCL Constraints[END_REF] or more generally on model-checking [START_REF] Kishi | Design Verification for Product Line Development[END_REF] techniques in order to verify those tests. In our case, the main difference is the fact that verifications can only be done at runtime. New aspect can be designed and integrated, consequently unanticipated evolution can occur. Using MDE techniques allows software developer to apply his aspect on an abstraction of its runtime system to check its correctness.

In [START_REF] Morin | An Aspect-Oriented and Model-Driven Approach for Managing Dynamic Variability[END_REF], we present a first approach that combines AOM and MDE in order to manage variability at runtime. In this paper, we show how aspects can help designer in determining interactions between dynamic variants and how models allows to validate new configurations independently from the running system and easily roll-back when a configuration is not valid.

In [START_REF] Wolfinger | Supporting runtime system adaptation through product line engineering and plug-in techniques[END_REF], Wolfinger et al. demonstrate the benefits of integrating Software Product Line techniques to manage the runtime reconfiguration and adaptation mechanisms on the .NET platform. Automatic runtime adaptations are attained by using the knowledge documented in variability models. As many authors [START_REF] Alves | Extracting and Evolving Code in Product Lines with Aspect-Oriented Programming[END_REF][START_REF] Apel | Aspectual mixin layers: aspects and features in concert[END_REF][START_REF] Mezini | Variability management with feature-oriented programming and aspects[END_REF] advocate that aspect-oriented software development (AOSD) is an effective technique to support feature variability, this approach is close to ours. Automatic runtime adaptations are attained by using the knowledge documented in variability models. However, they do not propose to do a preview of the running system at the model level to check its correctness.

In the domain of Aspect-Oriented Modeling, Nejati et al. [START_REF] Nejati | Matching and Merging of Statecharts Specifications[END_REF] propose an approach for matching and merging statechart specifications. This approach would be useful for extending our approach with behavior, as mentioned in Section 3.2. If we describe the behavior of our aspects it would possible to merge this behavior with the base model in order to obtain the complete be-havior. Describing the behavior of our aspects mainly consists in modeling the behavior of the interfaces of each component and compose these behavioral models when components are assembled. Once we obtain the global behavior, it is possible to reuse the concepts proposed by Zhang and Cheng [START_REF] Zhang | Model-based Development of Dynamically Adaptive Software[END_REF] for validating the behavior of adaptive systems.

Conclusion

In this paper, we have presented our approach for managing the complexity of dynamically adaptive systems. This approach combines aspect-oriented and model-driven techniques in order to limit the number of artifacts needed to realize dynamic variability. Our aspect model weaver allows us to construct configurations on-demand by selecting, by hand or according to predefined conditions, a set of aspects. Using the woven configuration, it is possible to validate this configuration before actually adapting the running system. Using aspects instead of low-level reconfiguration scripts allows us to detect some interactions that can provide assistance when selecting the set of aspects to be woven. Then, target configurations obtained after aspect weaving are checked with respect to the invariant we have defined into our metamodel. If a target configuration is not valid, the roll-back mechanism simply consists in not submitting this target configuration to the sub-sequent steps of the adaptation process. If the configuration is valid, we generate the adaptation logic using model comparison. This allows us to automatically determine a safe transition to make the system evolve from a its current configuration to the target configuration.

In future works, we plan to extend our approach following different axis. Currently, we describe our systems according to their runtime architecture (components, bindings, etc). We will also consider the behavior of dynamically adaptive systems. This can be realized if we can modularize and compose the behavior of components. Thus, it would be possible to decompose the system behavior into aspects, as we do for the architecture. We plan to reuse the approach we have presented in the related work section to consider the behavior. Another axis is about the validation of target configurations. Currently, we ensure that the target configurations ensure the invariants defined in our metamodel. With the definition of the behavior, we would be able to perform simulation in order to detect some deadlocks, for example.

Figure 5 .

 5 Figure 5. Invariant violated

Figure 8 .

 8 Figure 8. Base and woven configurations

Table 1 . Number of aspects per variability di- mension

 1 Table 1 summarizes the number of aspects we really need for each variability dimension to implement our case study.

	Dimensions	Aspects	Aspect variants
	Device Mgmt	3 (KNX, X10, X2D) 4 (1 per device type)
	Permission Mgmt	1	0
	Event Filter	3	4
	I18N	1	10
	Total	8	18

Table 2 . Five Operating Modes per Device

 2

	defined in the metamodel are checked on the woven
	target model. This allows us to determine whether the
	target model is well-formed or not. If the configura-
	tion is valid, the transition toward the target model is
	automatically computed using model comparison. If
	we consider the internationalization aspect, we should
	multiply the number of configurations by 2 10 as we
	should handle at least one language among 10. Table 3
	summarizes the number of dimensions we have defined,
	the total number of aspects we need, the number of
	configurations we obtain on-demand by aspect weaving
	and the number of transitions we generate on-demand
	when moving from one configuration to another.

Table 3 . Number of configurations and transi- tions managed by aspects

 3

Kermeta now allows to define constraints using the real OCL syntax

http://www.upnp.org/

http://en.wikipedia.org/wiki/Devices Profile for Web Services

This work was partially funded by the DiVA FP7 European project (STREP) (See http://www.ict-diva.eu/) and the S-Cube European Network Of Excellence on Software Services and Systems (See http://www.s-cube-network.eu/).


Brice Morin
email: brice.morin@inria.fr

Grégory Nain
email: gregory.nain@inria.fr

Olivier Barais
email: barais@irisa.fr|jezequel@irisa.fr

Jean-Marc Jézéquel

Leveraging Models From Design-time to Runtime. A Live Demo

This paper describes a demo which leverages models at designtime and runtime in the context of adaptive system, some details about the underlying approach as well as some implementation details. Our tool allows deploying and dynamically reconguring component-based applications, in a guided and safe way, based on the OSGi platform. It combines reexive and generative programming techniques, based on models, to achieve this goal.

An Overview of the Demo

The demonstration illustrates our tool-chain on a simple HelloWorld application.

In this section, we briey present the dierent tools of the chain, as well as the scenario to be demonstrated during the workshop. More details about the tools are given in Sections 3 and 4 and in previous publications [1,2,3].

Quick Overview of the Tool-chain

Our tool leverages models at design-time but also at runtime in order to deploy and dynamically recongure component-based applications. We rely on the SCA (Service Component Architecture, see http://www.eclipse.org/stp/sca/) editor to graphically design architectural models in the Eclipse IDE. We have extended this editor with code generation capabilities. This way, we can generate at designtime all the platform-specic infrastructure we need to be able to leverage models at runtime. We currently target OSGi [4] and Fractal/FraSCAti [5] as runtime platforms.

 and is an extension of the early prototype [3], demonstrated last year at the workshop [6],

The research leading to these results has received funding from the European Community's Seventh Framework Program FP7 under grant agreements 215412 (DiVA, http://www.ict-diva.eu/) and 215483 (S-Cube, http://www.s-cube-network.eu/). for managing Fractal-based systems. Unlike pure OSGi or Spring DM (see Section 2), this tool leverages models both for the initial deployment and for subsequent dynamic recongurations, preventing programmers from writing low-level reconguration scripts.

Scenario

We now outline the scenario to be demonstrated at the workshop.

Models At design-time At design-time, we will briey introduce the SCA graphical editor and show how congurations are designed. Then, we will automatically generate all the code we need for the remainder of the demo.

Models At Runtime At runtime, we will demonstrate how the initial conguration is deployed and perform several attempts of model-driven recongurations, with valid and invalid congurations. Moreover, we will show how our tool manages unpredicted changes at runtime e.g., when a component is directly uninstalled at the platform level.

1. Start: It displays a simple GUI to be able to load congurations 2. Load the initial conguration: Using the GUI, load the initial conguration (architectural model composed of two clients and two servers). It displays the GUI associated with the two clients.

3. Say Hello: Click on the sayHello button of each client. Depending on the way clients are connected with servers, this will produce a dierent result.

4. Load another conguration and Say Hello: This conguration is valid and actually produces a reconguration of the system (e.g., one client disappear, the other uses the servers in a dierent way).

5. Load another conguration: This conguration is not valid (default port not connected). This does not produce a reconguration of the system.

6. Servers crash! The server components are manually (via the OSGi textual console) removed from the system. The tool detects this change and noties the user that the current conguration is no more consistent. 7. Load another conguration: If the conguration is valid, the system will be recongured into a consistent conguration.

Background

This section briey introduces the dierent technologies related to our tool and highlights their limitations.

OSGi

The OSGi (Open Services Gateway initiative) consortium is composed of famous companies from dierent domains: automotive industry (BMW, Volvo), mobile industry (Nokia), e-Health (Siemens), SmartHome (Philips), etc. It provides a service-oriented, component-based environment for developers and oers standardized ways to manage the software lifecycle. See http://www.osgi.org for more details about OSGi.

Typically, an OSGi bundle (component) is responsible for managing its dependencies by itself. It can try to set its dependencies when it is starting, by searching required services from the OSGi service registry, or by registering to the OSGi event mechanism to be notied when required services appear or disappear. For example, the following code fragment sets the helloworld reference when the client component starts. Spring DM does not allow the declarative updating of this XML le in order to dynamically recongure the system. On the contrary this should be done programmatically by modifying the properties of the components and calling the modifyConfiguration(ServiceReference ref, Dictionary props) method provided by the Conguration plugin, or directly calling the getters/setters provided by the components. This is a major drawback since the initial conguration and the subsequent recongurations are not handled in a consistent way. On the one hand, the initial conguration is instantiated from a declarative specication describing the overall conguration of the system. On the other hand, the dynamic recongurations are realized in an imperative style, which requires the developer to set the dependencies in a programmatic way. In the case of a large reconguration, this requires to implement a long script describing how all the properties are updated. Moreover, it is very dicult to understand or validate the new conguration a priori, since no explicit representation (model or XML le) of this new conguration exists.

An Overview of SC@rt

This section describes SC@rt (SCA at runtime), to be demonstrated (live demo) during the workshop. The main objective of our approach is to leverage models at design-time in order to support the initial deployment of the system, but also at runtime, to provide a high-level support for dynamic recongurations.

Designing Architecture with the SCA Editor

The rst step consists in designing the component types to be manipulated by the application, in the SCA editor. Here, we only manipulate two types: client and server. This diagram simply consists of non-connected components describing their provided and required ports.

Then, it is possible to dene dierent congurations of the hello world application. In practice, this consists in creating a new diagram, and copy/pasting component types from the type diagram in order to instantiate component instances. These instances can then be connected together on compatible ports.

Generating the Code of Component Types

After the type diagram has been designed, we propose to generate the code of the type components. These type components are factories responsible for instantiating component instances. We have extended the SCA editor so that the code generation is simply invoked by a right click on the diagram. The code of the factory is rather systematic and only varies on some well identied points. We use String Template (see http://www.stringtemplate.org/) to generate this code.

Leveraging Architecture Models to Deploy and Recongure the System

Figure 3 illustrates our causal connection between an architectural model and a running system, based on our previous works [START_REF] Morin | Taming Dynamically Adaptive Systems with Models and Aspects[END_REF][START_REF] Morin | An aspect-oriented and model-driven approach for managing dynamic variability[END_REF]. This section gives some implementation details of the prototype we have described.

Reconguration Commands

The dynamic reconguration process is based on the Command design pattern.

Basically, we represent a reconguration script as a list of commands, as explained in [START_REF] Morin | Taming Dynamically Adaptive Systems with Models and Aspects[END_REF][START_REF] Morin | An aspect-oriented and model-driven approach for managing dynamic variability[END_REF]. These commands are ordered according to their priority: i ) remove binding, ii ) remove component, iii ) add component and iv ) add binding.

We dene the parameter of each command as public attributes. The check method is responsible for verifying that the parameters of the command have been well initialized. The execute method actually performs an atomic reconguration on the running system (e.g. add a component). Finally, the doAck method is called when the command has successfully been executed.

1. 2

 2 Components to be Manipulated during the demo The HelloWorld application manipulates three kinds of component types: Client, Server and VoiceServer. It can be composed of any number of Client component instances and any number of (Voice)Server component instances, collaborating according to dierent schemes. The demo will manipulate up to 34 component instances and 33 bindings (connections) among these components. Server components provide the IHelloWorld interface and optionally require [0..1] a VoiceServer. Depending on their real implementation, the Server components may say hello in dierent languages: English, Spanish, etc, by returning the corresponding String and optionally ask a voice server to actually say hello, hola, etc. Client components have two required ports, both typed with the IHelloWorld interface: default: a single mandatory required port [1..1] others: a multiple optional required port [0..*] Each client component is associated with a GUI: a window composed of a button and a text area. By clicking on the button, the client component simply asks the default server to say hello and, if any, all the other servers to also say hello. The results are printed in the text area, as illustrated in Figure 1.

Fig. 1 .

 1 Fig. 1. Two clients after the initial deployment and a reconguration Using these two types of components, it is possible to dene an arbitrary number of valid and invalid congurations. For example, a conguration where a client component is not connected to a default server is invalid, since the default port is mandatory.

  the component as IClient 13 context . registerService ( IClient . class . getName () , this , null ); 14 15 // setting the helloworld reference 16 ServiceReference [] refs = context . getAllServiceReferences ( null , 17 "( objectClass =" + IHelloWorld . class . getName () +")" ); 18 helloworld = ( IHelloWorld ) context . getService ( refs [0]) ; 19 } 20 }OSGi provides very exible and powerful mechanisms for managing the lifecycle of components. However, since the dependencies should be handled inside the components themselves, it is very dicult to separate the business logic from the adaptive logic and implement complex adaptation policies involving several collaborating components.2.2 Spring DMSpring DM (Dynamic Modules) allows managing congurations of OSGi-based applications by deploying the initial conguration from a XML le, dynamically adding, removing, and updating modules in a running system. Moreover, it has the ability to deploy multiple versions of a module simultaneously. See http://www.springsource.org/osgi for more information on Spring DM.Typically, a Spring bean (component) is a POJO with getters and setters for the reference that can be accessed and setted. Unlike OSGi, components are not responsible for setting their dependencies by themselves. On the contrary, these references are set from the outside, by calling the appropriate getters/setters. For example, the following code fragment illustrates the Client component. conguration is instantiated, deployed and started by loading the XML le describing this initial conguration, similarly to an ADL (Architecture Description Language). This le mainly describes the component types (factories) needed to instantiate component instances (beans in the Spring terminology), and how beans are wired together.

Figure 2

 2 Figure 2 illustrates one possible conguration.

Fig. 2 .Fig. 3 .

 23 Fig. 2. One possible conguration of the Hello World application

  the command i.e. , update the reflection model 18 Should be overriden by concrete commands . */ public void doAck () {

4.2 OSC@rt: Models@Runtime over OSGi The current prototype does not directly use SCA models at runtime. Instead, it uses architectural models conforming to a core architecture metamodel described in [START_REF] Morin | K@rt: An aspect-oriented and model-oriented framework for dynamic software product lines[END_REF], to reduce the memory overhead at runtime implied by the causally connected model. However, we have dened a bi-directional model transformation between SCA and our metamodel, in Kermeta [START_REF] Muller | Weaving executability into object-oriented meta-languages[END_REF].

The main class of this prototype is the OSGiCausalLink class illustrated (fragment) in the following scripts. The addBinding method shows how a command is instantiated. When a new binding is detected in the model, we simply instantiate and initialize the right command. Note that, at this point, the reection model has not been updated. In other words, the new binding has not been actually added to the reection model. The binding will be added to the reection model, in the doAddBinding method, only when the command will be properly acknowledged. public void handleEvent ( Event event ) { PlatformCommand cmd = ( PlatformCommand ) event . getProperty (" command " ); i f ( event . getTopic () . startsWith (" binding / ok /" )){ TransmissionBinding b = ( TransmissionBinding ) event . getProperty (" binding "); doAddBinding (b , (( AddBindingOSGi ) cmd ) . client ) ; cmd . doAck () ; } else i f ( event . getTopic () . startsWith (" binding / nok / ")){ TransmissionBinding b = ( TransmissionBinding ) event . getProperty (" binding "); System . err . println (" Problem when binding " +b) ; } ... }

We rely on the standard EventAdmin service provided by OSGi to acknowledge commands. When a command properly execute, an event containing the command is posted on the appropriate topic e.g., binding/ok. When receiving this event (handleEvent(Event event)), we simply call the doAck method of the command and update the reection model (e.g., by calling the doAddBinding method).

When a command does not execute properly, and event is posted on another topic (e.g., on binding/nok). In this case, the command is not acknowledged and the reection model is not updated. In this case, the AckTimerTask generates a report specifying which commands have been acknowledged and which commands have

getBinding () . clear () ; removeAllDanglingBindings ( cpt ) ; } }

Our causal link implements the standard BundleListener interface specied in the OSGi standard. This way, we are automatically notied when components are stopped or uninstalled. When a component is stopped, we clear all its dependencies and clear all the dependencies of all the components using this stopped component, by calling the removeAllDanglingBindings, and remove all the associated bindings from the reection model. Then, if the component is uninstalled, we simply remove it from the reection model. This paper has presented our tool-chain, to be demonstrated at the workshop. This tool chain leverages models at design-time but also at runtime to deploy and dynamically recongure component-based applications, in a guided and safe way. At design-time, we use the SCA editor to design the architecture, and code generation techniques to produce all the infrastructure we need at runtime. At runtime, the reconguration process is totally driven by the design models. Before adaptation, we check that the target conguration is valid. In this case, we generate the corresponding reconguration script, based on the command pattern.

Our tool also handles (in a limited way) unpredicted events, and is able to update the reection model accordingly and noties the user when this model becomes invalid.

In future work, we plan to improve the adaptation process by considering more constraints during the generation of commands. Currently, commands are ordered in a very simple way in order to avoid common errors like dangling bindings.

We would like to consider other constraints, specied by the architect, such as Component A should be stopped before Component B, etc.


G Rabatel
email: gilles.rabatel@montpellier.cemagref.fr

C Guizard

Grape berry calibration by computer vision using elliptical model fitting

Keywords: vineyard, berry size, image processing, deformable templates

In the context of vineyard and wine process management, producers are looking for novel tools to estimate the growth stage and potential quality of vine grapes. Several studies show the importance of the berry size as a growing and quality indicator. This paper proposes an image processing method to estimate the berry size of vine grapes by image acquisition in the field. The goal is to recover the profile of each visible berry in the grape, including partially occluded ones. In the present approach, an elliptical contour model is used to recover the complete shape of each berry from its visible edges. This method combines a primary edge detection and cleaning process based on a watershed algorithm, and a direct least square ellipse fitting algorithm.

Introduction

Grape growers have to take into account the growing stage when scheduling treatment, irrigation or harvest operations. For instance, the farmer can pilot the growing by removing a part of the harvest, in particular during thinning process; this operation improves the harvest global quality. In the same way, the choice of the wine-making process depends on the expected quality of the product.

For these reasons, the prediction of the expected yield and quality of grapes at a former stage by in-field observation is an important requirement from grape growers. First scientific analyses on production estimation feasibility began in the 1950s [START_REF] Wurgler | Peut-on prévoir le rendement de la vigne avant le débourrement ? (Can we forecast the vine yield before bud-break ?)[END_REF]. Studies on the relation between the bunch weight and quality appear later [START_REF] Booysen | Crop forecasting for vine grapes in South-Africa[END_REF]. [START_REF] Serrano | Recherche d'une méthode simple et fiable d'estimation des rendements à la parcelle (Searching for a simple and robust method for yield estimation at parcel level)[END_REF] showed the existence of a correlation between the bunch ripening volume and its weight to the vintage by carrying out large scale tests.

Several studies also demonstrate the importance of the berry size as a growing and quality indicator [START_REF] Roby | Berry size and vine water deficits as factors in winegrape composition: Anthocyanins and tannins[END_REF]. The berry size can be correlated to water deficit. In red wine production, a small size is also an indicator of a better ratio grape-pomace /juice. Berry size heterogeneity also indicates a non-homogeneous maturation. All these data can help to produce better wine. Berry size measurement is presently done by means of calipers. This method is mainly used in technical centers for experimentation purposes, and requires a manual separation of the berries. In this context, a method based on image analysis would be very helpful, especially if it is able to work directly on entire vine grapes.

Considering these various requirements in terms of grape volume and berry size estimation, an experimental tool, named REV 1 , has been developed by Cemagref in 2005, in collaboration with the French Vine Technical Institute 2 and a cooperative of vine growers 3 . With this tool, numerical images of individual grapes in the field can easily be acquired, with correct control of target distance and light conditions. Its first objective was a nondestructive estimation of the bunch weight at an early stage, by using computer vision to estimate the grape volume from its visible area [START_REF] Serrano | Capteurs aux champs : estimation de rendement par le REV (Rendement Estimé par le Volume) (Field sensors: yield estimation by the REV (Yield estimation[END_REF]. However, more detailed information such as berry color and size are also available, if appropriate image processing algorithms could be developed.

In the present paper, the feasibility of berry size measurement on such individual grape images is considered. In this approach, a first assumption is that an analysis limited to the visible berries in front of the camera is sufficient to provide valuable agronomic information. The challenge is then to recover the exact profile of as many berries as possible, including those that are partially occluded. The segmentation of partially occluded biological objects in images usually requires deformable templates, in order to model the expected complete shape of objects [START_REF] Manh | Weed Leaf Image Segmentation by Deformable Templates[END_REF]. In the present case, an elliptical contour model is used, as being well adapted to berry profiles. This model is fitted using discrete edges resulting from a previous image preprocessing. Best model fittings are then selected using a quality criterion.

The paper is organised as following: first, the grape image acquisition tool is presented. Then the proposed image processing algorithm for berry size recovery is described, as well as the primary results obtained on a typical grape image. Finally, main issues and ways of improvement to achieve an operational system are discussed.

Image acquisition tool (REV)

The REV tool has been designed to acquire photographic images of isolated vine grapes in a way that is suitable for further image processing. Built around a digital camera with a 28 mm focal length, it includes the following features:

-an acquisition procedure using a flash synchronised with a high shutter speed

(1/2000 s), in order to minimise the influence of ambient light. -An orange colour "V"shape background. The orange colour has been chosen to facilitate the grape/background color segmentation, while the "V" shape keeps the bunch well centred. -A rigid support to facilitate the apparatus handling and to guarantee a constant distance between the lens and the grape support as well as a constant camera view angle.

Berry size recovering algorithm

A grape image consists of a set of berries with nearly identical colour properties, so that the available information for berry separation mainly rely on their contours. Thanks to the smooth 3D shape of the berries, these contours are accessible as luminance discontinuities in the image. Let us consider a typical vine grape luminance image and the corresponding gradient image (Figure 2). However, other luminance transitions are due to surface heterogeneities on berries themselves. For this reason, whatever will be the process involved to recover the berry profiles from image edges, a primary selection among these edges has to be made. These two steps will now be considered successively.

Primary edge detection and selection

Starting from a gradient image such as in Figure 2.b, image edges are usually obtained using a thresholding operation. However, in the present case, we have chosen to use a watershed algorithm (Vincent & Soille,1991), which has the advantage of directly giving edges of one pixel width, and a result that is much less dependent on the threshold value4 . Ellipse model fitting We suppose in this part that we approximately know the centre position of a given berry. The challenge is thus, starting from this centre point, to fit an ellipse model to the berry edges around it. Deformable templates can be considered as an extension of active contours or "snakes", introduced by [START_REF] Kass | Snakes : Active contour models[END_REF]. In the present case, our ellipse model consists of 5 scalar parameters5 , which have to be adjusted according to image data. Just as for snakes, deformable templates are usually fitted by using evolution "forces" that attract them to the image edges. Pressure (or "balloon") forces can also be applied to make them evolve from a starting point (Cohen,1991).

In a primary stage of our study, we have tried to use such an evolution process, i.e. to make the ellipse model evolve from the center point, and then lock on high values in the gradient image. However, image edges due to berry surface heterogeneities introduce numerous erroneous model locking. A considerable improvement has then been obtained by using the list of arcs described above for model locking, for the following reason: for a given ellipse model instance, only "compatible" arcs can be selected, based on geometrical considerations (curvature value and relative orientation according to the ellipse). However, a lot of erroneous model locks were still observed.

Finally, the following procedure has been implemented: instead of applying evolution forces, we directly fit the ellipse model to a set of compatible contour arcs, using the least square algorithm proposed by [START_REF] Fitzgibbon | Direct Least Square Fitting of Ellipses[END_REF]. The problem is here to define a pertinent set of contour arcs in each case. A combinatory procedure has been defined as following:

i) for a given ellipse center, all contour segments in the arc list that are compatible with it (in terms of distance, curvature, orientation) are selected .

ii) every possible subset of contour segments among the compatible contours found in i) are successively built. For instance, with 3 segments S1, S2, S3, 7 subsets will be built: {S1}, {S2}, {S3}, {S1 S2}, {S1 S3}, {S2 S3}, {S1 S2 S3}.

iii) the ellipse fitting algorithm of FitzGibbon is applied to every subset, and only the best fitting is kept, according to a quality criterion.

The quality criterion is defined as:

∫ ∇ = E ds I C ( 1
)
where E is the ellipse curve and I is the original image. C is directly obtained by summing the pixel-values in the gradient image for every ellipse point.

The main potential problem with such a procedure is the risk of combinatory explosion. For a set of n compatible segments, the total number of subsets is 2 n -1 (excluding the empty one). In the present case, the maximum number of segments has been set to 8 (i.e. 127 possible subsets). If this number is exceeded, shorter segments in the subset are removed .

Image scanning

In order to apply the fitting algorithm described above, a starting point inside each berry must be defined. This is presently achieved by setting arbitrary starting points in the image using a regular square grid of 10x10 pixels. Because starting points that are close to each other often generate similar or overlapping ellipses, a selecting process is applied after the scanning: ellipses that have a common portion of contour 6 are detected, and only the one with the better quality criterion is kept (see equation ( 1)). Finally, a last selection step is applied, that takes into account the ellipse dimensions.

Results and discussion

Figure 4 shows the results obtained on the image of figure 2.a, using the whole process described above. The initial edge detection is also given for analysis purpose. A total processing time of a few minutes has been necessary, using a standard Pentium 4 PC computer, and concerns essentially the image scanning phase.

b) Initial edge detection

As a first remark, these results show that the ellipse model is well-adapted to berry profiles: ellipse curves redraw the berry contours very accurately. However, about 1/3 of the visible berries on the grape vine are not detected, and some erroneous ellipses are present. Various reasons explain the non-detection of visible berries. In cases 1 to 5 (see figure 4.a), it is due to the insufficient number or quality of the initial edges (Figure 4.b), leading to erroneous ellipses that have been rejected on quality criterion. In cases 6 and 7, a detailed analysis shows that the correct ellipses have been found, though they do not appear in the results: they have been replaced by erroneous ones in the selection process (in case 7, the selected ellipse, which included two berries, has finally also be removed on dimension criteria).

This illustrates the two main critical points of the proposed method. First, the performance of the initial edge detection step is determinant. Second, a substantial improvement might be obtained using a more elaborate quality criterion in the final model fitting selection

Conclusion

A complete image processing algorithm has been proposed to recover the berry profile in vine grapes, for various agronomic purposes. The ellipse fitting approach has shown its ability to provide very satisfactory results. However, further work is still necessary to achieve an operational system. It will concern:

-The improvement of the primary edge detection process: adaptative thresholding will be included in the watershed computation step, taking into account the local grey-level distribution. -The improvement of the model fitting quality criterion: a multivariate classification will be introduced, taking into account the ellipse dimension, the gradient value distribution among the ellipse curve, etc. A learning step will thus be necessary. -The algorithm optimisation in order to reduce the processing time.

By applying this new algorithm to grape images acquired in the field with the REV device (figure 1), non destructive quality assessment will become available, and replace destructive berry size measurement operations presently made in laboratory. According to the existing protocol, a set of about 25 grape images per parcel should be sufficient. The images will be stored and post-processed.

After a first phase of validation and calibration in ITV research laboratories, expected users are mainly the wine growing cooperatives, consulting companies or large vine producers.

1

  REV : « Rendement Estimé par le Volume » (Yield estimation by volume) 2 ITV: Institut Technique du Vin . Vinnopôle -BP 22. 81310 PEYROLE -FRANCE 3 Vine growers of Rabastens: 33 road of Albi 81800 RABASTENS -FRANCE This tool is illustrated in figure 1. a b Figure 1. REV image acquisition tool a) REV first prototype b) synthetic image of the final tool

Figure 2 .

 2 Figure 2. Grape image a) Luminance image. b) Image of the gradient modulus

Figure 2 .

 2 Figure2.b shows that most of the berry contours correspond to high gradient values. However, other luminance transitions are due to surface heterogeneities on berries themselves. For this reason, whatever will be the process involved to recover the berry profiles from image edges, a primary selection among these edges has to be made. These two steps will now be considered successively.

Figure 3 Figure 3 .

 33 Figure 3.a gives the result of the watershed algorithm applied to a part of figure 2.b gradient image. Several steps are then applied to this watershed image to obtain a list of arcs: i) the entire watershed edges are analysed, looking for edge intersections, and stored as a tree structure of individual contour segments with recursive interconnections (Figure 3.b)ii) terminal segments in the tree structure with a length below a given threshold (10 pixels) are removed. The step i) is then applied again. This allows to eventually connect the remaining segments in larger ones. It results in a set of "cleaned" contours, as shown in figure3.c iii) finally, each contour segment in the cleaned tree structure is decomposed to elementary arcs of constant curvature, that are stored in an arc list.

Figure 4 .

 4 Figure 4. Example of ellipse fitting a) Algorithm output. b) Initial edge detection

A threshold value is nevertheless required to remove very low level watershed crests.

Respectively ellipse center (2 parameters), 2 ellipse radii (small and large axes), and ellipse orientation.

Acknowledgements

Eric Serrano, ITV Midi-Pyrénées Jean Luc Favarel, cave de Rabastens Sylvie Roussel , sté Ondalys, Montpellier