Bogdan Robu

Lucie Baudouin

Christophe Prieur

A controlled

A controlled distributed parameter model for a fluid-flexible structure system: numerical simulations and experiment validations Bogdan Robu; Lucie Baudouin and Christophe Prieur

Abstract-We consider the problem of active reduction of vibrations in a fluid-flexible structure system. In the aerospace domain, we are actually interested in the system that couples the deflection of a plane wing and the sloshing of the fuel inside the wing's tank. The control is performed using piezoelectric patches and the main difficulty comes from the complex coupling between the flexible modes of the wing and the sloshing modes of the fuel. We establish an infinite-dimensional model for the global system and then a finite-dimensional approximation calculated using the first modes and validated on the experimental setup. A feedback controller is used to show the effectiveness of the closed loop in attenuating vibrations.

Index Terms-PDE experiment, fluid-flexible structure, pole placement

I. INTRODUCTION

Smart structures occupied a major place in the control research area during the last two decades. They are now used for their capability of attenuating the vibrations and measuring the deformation of structure. For instance consider recent feedback control techniques devoted to the active vibration reduction of flexible structures see [START_REF] Bhikkaji | Multivariable integral control of resonant structures[END_REF], [START_REF] Fleming | Optimal impedance design for piezoelectric vibration control[END_REF].

In the applicative domain of aerospace, we study the general problem of the suppression of a plane wing's vibration considering that the wing is in interaction with the movement of the fuel inside the wing's tank. Recent developments in the aerospace applications lead to more and more flexible wings.

The actual system we study (see Figure 1) is an example of a coupled fluid-flexible structure system. Some studies investigate the use of piezoelectric patches to effectively suppress the vibrations. However, only a few results are already available in the literature for fluid-structure systems. One can see e.g. [START_REF] Lasiecka | Boundary feedback control in fluidstructure interactions[END_REF] for a recent theoretical result and [START_REF] Terasawa | Adaptive identification of MR damper for vibration control[END_REF] for a validation of the method by means of experimental results. There are less studies of fluid-structure system dedicated to aerospace applications but one can read [START_REF] Pommier-Budinger | Fractional robust control with iso-damping property[END_REF] where controllers are designed using a numerical model.

The first aim of this paper is to derive an infinite dimensional model of the specific fluid-(flexible)structure system. The distribution of entries and the number of degrees of freedom of possible applications motivate us to consider a model written using partial differential equations. The difficulties that we have to manage are twofold. On the one hand the flexible structure is comparable to a plate, and we have two independent space variables (in contrast to the classical cantilever beam which does not have any width). CNRS ; LAAS ; 7 avenue du colonel Roche, F-31077 Toulouse, France Université de Toulouse ; UPS, INSA, INP, ISAE ; LAAS ; F-31077 Toulouse, France brobu@laas.fr, baudouin@laas.fr, cprieur@laas.fr The study of flexible plates has been already considered in the literature (see [START_REF] Lee | Vibration control experiments on a piezoelectric laminate plate using spatial feedforward control approach[END_REF]) but they are usually based on finitedimensional model. On the other hand, the interaction of the flexible plate with the fluid asks to introduce a dynamical fluid model which is also an infinite-dimensional equation and which is coupled with the plate equation.

The first contribution of this paper is therefore the computation of an infinite-dimensional model for the fluid-structure system. Then we compute a stabilizing controller which is based on a pole-placement feedback. We check up on simulations that there is no spillover effect when closing the loop. Finally we present some experiments on a real setup.

The paper is organized as follows. We present in Section II the plant under consideration. The plate is equipped with piezoelectric patches (sensors and actuators). Then in Section III we establish the fluid-structure model of our system. We compute in Section IV a simple stabilizing controller which is a pole-placement feedback control law. Section IV is also devoted to numerical simulations and to experiments on the real setup.

II. PLANT DESCRIPTION

The system we want to control is located at ISAE-ENSICA, Toulouse, France and has been constructed to have the vibration frequencies of a real plane wing with fuel [START_REF] Pommier-Budinger | Fractional robust control with iso-damping property[END_REF]. Our goal is to build a pole placement controller that will attenuate the vibrations of a plate despite the shaking of a tank filled with liquid and inserted at the end of the plate.

The device is composed of an aluminium rectangular plate and a plexiglas horizontal cylindrical tank filled with liquid (see Figure 1).

The plate has the length along the horizontal axis and the width along the vertical one; it is clamped on one side and free on the three others. The characteristics of the aluminium plate are given in Table I. The tank is located at about 0.05% length of the plate's free side and is symetrically spread along the horizontal axis. Due to the configuration of the total system (cf Figures 1 and2) we infer that the tank undergoes a longitudinal movement when the plate has a flexion movement and a pitch movement when the plate has a torsion movement. It has the dimensions given in Table III and it can be filled with water or ice up to an arbitrary level. If the tank is filled with ice we can easily model it by a steady mass.When the tank is filled with water but the water level is close to 0 or close to the cylinder diameter (tank empty or tank completely filled), as there is no sloshing behaviour, the modeling process is similar.

III. MODELING OF THE SYSTEM

In this section we compute the mathematical model of the system previously presented. We first present an infinitedimensional model using operator matrices and then a finitedimensional model considering only some of the system's modes.

A. Infinite-dimensional model

On the one hand, considering the plate, we assume the kinematic hypothesis given by [START_REF] Blevins | Formulas for natural frequency and mode shape[END_REF]Chapter 11.1]. This allows us to calculate the kinetic and potential energies as well as the mass and stiffness matrices. More details for calculations are given in [START_REF] Géradin | Mechanical Vibrations: theory and application to structural dynamics[END_REF]Chapter 4.6]. Using the mass and stiffness matrices one can infer the partial derivative equation of the plate:

m s ∂ 2 w ∂t 2 + ζ(w) ∂w ∂t + Y I s ∆ 2 w = ∂ 2 m y ∂y 2 + ∂ 2 m z ∂z 2 (1)
where ζ(w) is an operator quantifying the damping, w = w(y, z, t) is the displacement, m s mass per unit plate area, Y the Young modulus and I s =

h 3 12(1-ν 2 ) the moment of inertia of the plate. ∆ is the Laplace operator with ∆ 2 being equal to ∂ 2 ∂y 2 + ∂ 2 ∂z 2 2
. The m z , m y are external moments, along the z and y -axis, delivered to the plate by the actuators (see [START_REF] Dimitriadis | Piezoelectric actuators for distributed vibration excitation of thin plates[END_REF] or [START_REF] Crépeau | Control of a clamped-free beam by a piezoelectric actuator[END_REF]) and by the sloshing modes. Further on (1) is to be solved using the boundary conditions given in [2, Chapter 8.1.1] or [START_REF] Crépeau | Control of a clamped-free beam by a piezoelectric actuator[END_REF].

Later in our study we are using the homogeneous partial derivative equation in the absence of external forces:

m s Y I s ∂ 2 w ∂t 2 + ∆ 2 w = 0 (2)
The displacement w will then be expressed in a Hilbertian base using Ritz functions:

w(y, z, t) = ∞ k=1 η k (y, z)q k (t) = ∞ k=1 Y i k (y)Z j k (z)q k (t) (3)
where Y i k (y) and Z j k (z) are the Ritz functions of two beams along the y-axis and z-axis. For a more detailled description of the choice of Ritz functions see [START_REF] Géradin | Mechanical Vibrations: theory and application to structural dynamics[END_REF]Chapter 5.2].

On the other hand, we now consider the longitudinal movement of the liquid along the x-axis. Because the liquid motion is starting from rest, there is a velocity potential φ(x, y, z, t) such that (see [START_REF] Sir | Hydrodynamics[END_REF]Chapter 1.12]) the equation of liquid continuity is written

∂ 2 φ ∂x 2 + ∂ 2 φ ∂y 2 + ∂ 2 φ ∂z 2 = 0 (4)
and the linearized equation of liquid motion is

∂φ ∂t + p ρ + g(z -h) -C 0 x = 0 (5)
where C 0 stands for the acceleration along the x-axis, g for the gravitational acceleration and h for the liquid height in the container at rest position; ρ and p are the density and the pressure of the liquid. Further on (4) and ( 5) are to be solved using the boundary conditions detailled in [12, Chapter 1.9].

As in [5, Chapter 1.2], we can give the expression of the oscillating free surface z as:

z = h + δ(x, y, t) (6)
where δ(x, y, t) is the small displacement of the free surface above the undisturbed level z = h. One can notice from [9, Chapters 1 and 2] that the solution of the sloshing problem depends on the geometry of the tank. In the case of horizontal cylindrical tank, as it is our case, the difficulty resides in the fact that the shape of the horizontal cylinder does not fit into any standard coordinate system and thus the velocity potential, which is quantifying the sloshing, cannot be derived using separation variable method. In our case (horizontal cylindrical tank that undergoes longitudinal movement) the longitudinal mode frequencies are simply curves faired through experimental data as are no analytical results available (see [START_REF] Dodge | The new "dynamic behavior of liquids in moving containers[END_REF]Chapter 1.6]).

The solution we propose to overcome this difficulty is to make a geometrical approximation, the cylindrical tank being approximated by a rectangular one with the same sloshing frequencies but for which there are analytical results for the calculation of modes and forces/moments. In order to calculate the parameters of the rectangular "virtual" tank we use the following approach: we choose the length of the rectangular tank equal to the one of the cylindrical one, the width of the rectangular tank equal to the width of the free surface of the liquid and the height of the rectangular tank so that the liquid volume in both containers is the same. After comparing the sloshing frequencies of the rectangular tank to the ones calculated from the experimental data we observe that the difference is only 10 -2 Hz.

Further on φ(x, y, z, t) and δ(x, y, t) are calculated by solving (4), ( 5) and ( 6) with proper boundary conditions (see [START_REF] Khandelwal | A mechanical model for liquid sloshing in a rectangular container[END_REF] for a rectangular tank of length a along the x-axis and width b along the y-axis). As the movement of the liquid is along the x-axis it can be proven that the free surface displacement and the velocity potential are not depending on y:

δ(x, y, t) = δ(x, t) = ∞ i=0 r i (t) cos(Ξix) (7) φ(x, y, z, t) = φ(x, z, t) = ∞ i=0 ṙi (t) cosh(Ξiz) Ξi sinh(kih) cos(Ξix) (8)
where Ξi = π i a and ṙi = dri dt . By replacing ( 6), ( 7) and ( 8) in [START_REF] Dodge | The new "dynamic behavior of liquids in moving containers[END_REF] we get a differential equation of r i which is to be solved for the free surface. This allow us to compute the r i functions. After tedious calculations we have the total moment exerted by the liquid sloshing:

m y = -2ρb ∞ i=1,3,5,... ri (t) Ξi 3 1 tanh(Ξih) + 2 sinh(Ξih) + ρC 0 a 3 b 12 + 2ρb ∞ i=1,3,5,... ri (t) Ξi 3 hΞi 2 (9)
Further on, for the coupling, ( 9) is used in the moment expression m y of (1) along with the moment delivered by the actuators. More explanations are given for the finitedimensional case in paragraph III-B.3.

B. Finite-dimensional approximation

Knowing that the influence of system's modes is inversely proportional to the mode's frequency we legitimate that we may approximate the displacement by the first N modes of the system. We are detailing in this subsection the calculation of the finite-dimensional approximation of our model. We aim at describing a state space model where the state vector should gather the first N vibration modes of the plate and the first N sloshing modes of the tank.

1) Plate model: In this section we are calculating the finite-dimensional approximation of (1) for the rectangular plate.

We write the finite-dimensional approximation for the clamped-free-free-free plate in the absence of the tank using equation [START_REF] Bhikkaji | Multivariable integral control of resonant structures[END_REF]. The approximation of the effect of the tank will be considered in Section III-B.3.b. We write

Ẋp (t) = A p X p (t) + B p u(t) y(t) = C p X p (t) (10)
where

X p = q1 ω 1 q 1 • • • q N ω N q N
-the q k being the same as in (3) -is the state space vector, and the dynamic matrix A p is written as:

A p =     A p1 0 • • • 0 0 A p2 • • • 0 • • • 0 0 • • • A pN     (11)
with

A p k = -2ζ k ω k -ω k ω k 0 for every k from 1 to N .
The frequency of the k th mode is ω k in [rad s -1 ] given in [2, Chapter 11] and ζ p k is the damping. The experiments have proved that the damping is not constant for every vibration mode but it depends on the quality factor which is different for every structure mode. The value of the quality vector is obtained by measurements on the structure for a given input voltage.

For the control matrix B p , [START_REF] Dimitriadis | Piezoelectric actuators for distributed vibration excitation of thin plates[END_REF] or [START_REF] Kim | Influence of piezo-actuator thickness on the active vibration control of a cantilever beam[END_REF] can be consulted for the main steps regarding the modeling of the piezoelectric patches. As our experimental setup is not symmetric with respect to the x-axis -actuators only on one side of the plate -the position of the neutral fiber needs to be recalculated using [START_REF] Kim | Influence of piezo-actuator thickness on the active vibration control of a cantilever beam[END_REF]. The control matrix is then written as:

B p = (b p1 , 0, ..., b p k , 0, ..., b pN , 0) T (12)
where

b p k = K b (Y ′ i (y a2 ) -Y ′ i (y a1 )) za2 za1 Z j (z)dz +K b (Z ′ j (z a2 ) -Z ′ j (z a1 )) ya2 ya1
Y i (y)dy (y a1 , z a1 ), (y a2 , z a2 ) are the coordinates of the actuator and K b is a parameter depending on the actuator/plate geometry and on the position of the neutral fiber. In [START_REF] Khandelwal | A mechanical model for liquid sloshing in a rectangular container[END_REF], u(t) stands for the voltage applied to the piezoelectric patch.

The output matrix C p is calculated with the new position of the neutral fiber:

C p = (0, c p1 , ..., 0, c p k , ..., 0, c pN ) (13)
where

c p k = Kc ωp k Ca (Y ′ i (y c2 ) -Y ′ i (y c1 )) zc2 zc1 Z j (z)dz +(Z ′ j (z c2 ) -Z ′ j (z c1 )) yc2 yc1 Y i (y)dy
and C a is the capacity of the charge amplifier we use to measure the voltage in the output of the piezoelectric sensor and K c is a parameter depending on the sensor/plate geometry and on the position of the neutral fiber. The coordinates of the sensor patch are (y c1 , z c1 ), (y c2 , z c2 ). For a more detailled calculation of the matrices B p and C p see [START_REF] Tliba | Active vibration damping of a smart flexible structure using piezoelectric transducers: H∞ design and experimental results[END_REF].

2) Liquid model: In this section we calculate the finitedimensional approximation of the tank's sloshing.

Having the geometrical parameters of the rectangular tank one can use [START_REF] Sir | Hydrodynamics[END_REF]Chapter 17] to calculate the movement equations and the boundary conditions. We then use the approximation given by [START_REF] Khandelwal | A mechanical model for liquid sloshing in a rectangular container[END_REF] to model the sloshing. We are using a finite number of mass pendulums systems -each corresponding to a sloshing mode -that is to say for the k th odd integer i of the series [START_REF] Ibrahim | Liquid sloshing dynamics[END_REF], it corresponds a masspendulum system denoted k.

The state-space representation is then easily obtained using the pendulum equation under external acceleration:

zk + 2ξ z g l k żk + g l k z k = - 1 l k C 0 ( 14
)
where z k is the angle of the kth pendulum compared to its equilibrium position, l k its length and ξ z is the value of pendulum damping and it is fixed at 0.01 for all masspendulum systems. By choosing the state space vector for the liquid sloshing equal to X z = żk

g l k z k T
, the dynamic equation is

Ẋz = A z X z + B z u acc ( 15
)
where the matrix A z computed from ( 14) is:

A z =     A z1 0 • • • 0 0 A z2 • • • 0 • • • 0 0 • • • A zN     (16)
with

A z k =   -2ξ z g l k -g l k g l k 0   .
In the case of the control matrix B z the construction is also direct by considering from ( 14) u acc = C 0 as the control variable:

B z = (b z1 , 0, ..., b z k , 0, ..., b zN , 0) T ( 17
)
where

b z k = -1 l k 0 .
3) Model coupling: The crucial and the most difficult part in the modeling of this experimental setup is the interaction between the plate and the cylinder. In the following subsection the calculations are done assuming that the liquid movement is approximated by only one mass pendulum system and the plate movement by only one Ritz function. The generalization to more mass pendulum systems and more Ritz functions is direct.

In order to quantify the interaction between the plate and the tank we have to study the plate's influence on the tank and vice versa.

a) Plate's influence on the liquid filling the rectangular tank: The movement of the pendulum mass system under external acceleration is described by [START_REF] Lee | Vibration control experiments on a piezoelectric laminate plate using spatial feedforward control approach[END_REF], where C 0 is the acceleration delivered by the movement of the plate. We first use (3) to express the movement of the plate and the acceleration is then obtained by derivations according to time. In the case of one mass-pendulum and one Ritz function the acceleration becomes:

C 0 = ẅ(y, z, t) = Y 1 (y)Z 1 (z) q1 (t) (18)
where Y 1 (y) and Z 1 (z) are the first Ritz functions along y-axis and z-axis.

As in [START_REF] Khandelwal | A mechanical model for liquid sloshing in a rectangular container[END_REF], the external acceleration C 0 can be calculated in the gravity center G = (y G , z G ) of the tank for steady motion. Thus (18) becomes:

ẅ(y G , z G , t) = Y 1 (y G )Z 1 (z G ) q1 (t) = C 0
and this allow us to write C 0 as:

C 0 = Y 1 (y G )Z 1 (z G ) 0 q1 (t) ω 1 q1 (t) T . ( 19
)
From this last equation one can see q1 (t) ω 1 q1 (t)

T is the derivative of the state space vector of the rectangular plate Ẋp . By taking

K G = Y 1 (y G )Z 1 (z G ) 0 , (19) becomes:
C 0 = K G A p X p + K G B p u (20)
where Ẋp was replaced with the expression from [START_REF] Khandelwal | A mechanical model for liquid sloshing in a rectangular container[END_REF]. Using (20), ( 16) and ( 17), equation ( 15) becomes:

Ẋz = A z X z + B z (K G A p X p + K G B p u) (21)
This equation describes the fact that the movement of the plate generates a movement of the pendulum mass systems, that is to say a movement of the liquid in the tank.

b) Tank's influence on the rectangular plate: The liquid sloshing is sensed by the plate as a perturbation that comes into the state space representation by means of a matrix B zp :

Ẋp = A p X p + B p u + B zp X z y = C p X p (22)
see (paragraph III-B.1). For the calculation of the perturbation matrix B zp we are using the same approach as in the case of the control matrix B p . The external moment applied to the tank due to the movement of the fluid is computed in [START_REF] Ibrahim | Liquid sloshing dynamics[END_REF]. By our choice of the physical parameters of the pendulum, the moment due to the liquid sloshing is equal to the moment due to the movement of all mass-pendulum systems. The external moment written for only one mass-pendulum is

M zp = m 1 L 1 (C 0 + l 1 z1 )
where C 0 + l 1 z1 is the total acceleration due to pendulum oscillations and plate movement. Using (20) and ( 21), the expression of M zp can be rewritten as:

M zp = m 1 l 1 L 1 0   -2ξ z g l1 -g l1 g l1 0   X z (23)
From this last equation we can infer that the total momentum of the pendulums does not depend on the external acceleration C 0 but only on the liquid movement.

For the calculation of B zp we are then assuming that the total momentum is concentrated in a small square around the tank center of gravity G, with edges of coordinates (y 1G , z 1G ), (y 2G , z 2G ). The total bending moment is:

Γ zp = y2G y1G z2G z1G ∂ 2 M zp ∂y 2 + ∂ 2 M zp ∂z 2 wdydz. (24)
Using ( 23) and ( 3) into (24) we obtain

B zp = b zp1 0 (25)
where:

b zp1 = K zp (Y ′ i (y 2G ) -Y ′ i (y 1G )) z2G z1G Z j (z)dz +(Z ′ j (z 2G ) -Z ′ j (z 1G )) y2G y1G Y i (y)dy and K zp = m 1 l 1 L 1 0 A z .

C. Complete Model

From ( 21) and ( 22) one can write the complete state-space model of the experimental setup. For the sake of clarity of the presentation of the complete model we consider the case of one Ritz function and one mass-pendulum.

For the complete system we choose as state space vector:

X = X p X z = q1 ω 1 q 1 ż1 g l1 z 1 T .
Combining all the matrices leads to the following finitedimensional approximation using the state-space representation:

   Ẋ = A p B zp A pz A z X + B p B pz u y = C p 0 X (26)
where

A pz = -1 l1 K G A p 0 , B pz = -1 l1 K G B p 0 and
0 denotes the null matrix of appropriate dimensions.

IV. CONTROLLER SYNTHESIS

In this section we calculate a controller for our experimental setup using the finite-dimensional approximation of our model.

Using the state space representation (26) we can use the pole allocation method to compute a controller K that will minimize the response time of the closed-loop in comparison to the open-loop.

The controller K is first tested in simulation under Matlab and then on the experimental setup at ISAE. In our case the voltage delivered by K will be the input of the system and the voltage delivered by the piezoelectric sensor will be the system's output. The tank is filled up to an arbitrary level of 0.7. The initial condition considered is a plate displacement of 2cm from its initial equilibrium position. In choosing the closed-loop poles, we have to take into account the limitations of the piezoelectric actuators [-130V, 130V ].

A. Simulations

The controller is calculated using the first three modes of the plate and the two modes of the liquid sloshing, that is to say (26) is used with X p ∈ R 6 and X z ∈ R 4 .

The closed-loop system is then simulated using the first four modes of the plate and the first three modes of the liquid sloshing (therefore it is simulated on a system of larger dimension). The voltage delivered by the piezoelectric sensors in the open-loop and the closed-loop case are presented in Figure 3. The real part of the closed-loop poles was chosen up to 10 times the real part of the open-loop ones. The state estimator is a Luenberger observer with the same dimension as the system. The real part of the observer poles is up to 10 times bigger than the real part of the poles. From Figure 3 one can notice the absence of the spillover effect on the fourth mode (i.e. the first one which has been neglected in the design on the controller). Although it is a common problem when working with infinite-dimensional systems we did not observe it. Even though some techniques to cancel it exist, e.g. by prefiltering the piezoelectric sensor signals with a low-pas filter, see [START_REF] Hwang | Robust LQG control of an all-clamped thin plate with piezoelectric actuators/sensors[END_REF].

B. Experiments

The results are then tested on the experimental setup. The controller previously calculated is implemented under the same initial conditions (plate displacement of 2cm from its initial position). The voltage delivered by the system's sensors, in the open-loop and the closed-loop case, is given in Figure 5. The response time (settling time) is measured considering a 10% tolerance band. We can see that the closed-loop response is better that the open-loop one, even though we considered only a few modes for the plate/liquid.

V. CONCLUSION

After settling an infinite-dimensional model we have computed a finite-dimension approximation for the experimental setup by using Ritz method. Tests and simulations are made with only three modes for the plate and two modes for the liquid. Due to the closeness in open-loop response time between the model and the experimental setup we infer the validity of the model. However the response time of the closed loop systems is not so close in both cases. It is probably due to the uncertainty that was not taken into consideration while calculating the controller.

Further investigations are necessary in some areas and are studied now such as: 1. Damping modeling. We considered the damping of the structure being constant for each mode. In reality we observed that the damping depends not only on the mode but also on the input voltage of the structure. 2. H ∞ controller. Constructed with a large number of plate/liquid modes, it will make the system robust to exterior perturbations. Also the use of uncertainty in modeling the system and in the synthesis of the controller will improve the closeness between the closed loop response time. 3. Non linear modeling of the actuators.

Fig. 1 .

 1 Fig. 1. Plant description: the rectangular plate and the horizontal cylinder

  Fig. 2. Deformation of the rectangular plate

Fig. 3 .Fig. 4 .

 34 Fig. 3. Response of the closed-loop system (in plain line) and of the open-loop system (in dotted line) on numerical simulations

Fig. 5 .Figure 6

 56 Fig. 5. Response of the closed-loop system (in plain line) and of the open-loop system (in dotted line) on experiments

Fig. 6 .

 6 Fig. 6. Voltage applied to the actuators on experiments

ACKNOWLEDGEMENTS

The authors would like to thank Valérie Pommier-Budinger, ISAE, Toulouse (France) for fruitful discussions on the experimental setup.


G L J A Rikken

B A Van Tiggelen

Observation of the intrinsic Abraham force in time-varying magnetic and electric fields

The Abraham force exerted by a time-dependent electromagnetic field on neutral, polarizable matter has two contributions. The one induced by a time-varying magnetic field and a static electric field is reported here for the first time. We discuss our results in the context of the radiative momentum in matter. Our observations are consistent with Abraham's and Nelson's versions for radiative momentum.

The Abraham force is the force exerted by a time-dependent electromagnetic field on neutral, polarizable matter, and has been debated for over a hundred years. The macroscopic Maxwell's equations provide a continuity equation for electromagnetic momentum that takes the general form

∂ t G + ∇ • T = f 1 (1)
with G "some" electromagnetic momentum density, f 1 "some" force density exerted on the radition, and T "some" stress tensor. The apparent arbitrariness in assigning expressions for G, T and f 1 is known as the Abraham-Minkowski (AM) controversy.(for reviews see e.g. [1] and [2]). In the Minkowski version one adopts G = G M = D × B and Maxwell's equations lead to f 1 (M ) = ε 0 (∇ε r ) E 2 + µ -1 0 ∇µ -1 r B 2 , i.e. there is no force proportional to both electric and magnetic field. The Abraham version insists on a momentum proportional to the energy flow so that G = G A = ε 0 µ 0 E×H in which case the Abraham force density takes the form

f 1 (A) = f 1 (M )-ε 0 (ε r -1/µ r )∂ t (E×B).
The second term on the right hand side will be referred to as the "Abraham force density". Other versions can be found in literature such as Peierls' proposition f

1 (P ) = ε 0 (ε r -1)(∂ t E × B -1 5 E × ∂ t B
) in which case the full time derivative of the Abraham version has disappeared [3]. In the Einstein-Laub version the force f 1 achieves a gradient, i.e. a part of ∇ • T. For the homogenous case, which we will consider for the remainder, the Einstein-Laub version is equivalent to the Abraham version.

In this work we will measure explicitly the force exerted on matter by a combination of a time-dependent electric field E(t) and a time-dependent magnetic field B(t). The Newton-Lorentz force on an object with mass density ρ is unambiguously given by ρ∂ t v = ρ q E + J q × B, with ρ q the charge density, J q the charge current density and v the velocity. Under the assumption of macroscopic fields and in the absence of free charges and currents [START_REF] Jackson | Classical Electrodynamics[END_REF] it can be cast in the form [START_REF] Van Tiggelen | [END_REF]

ρ∂ t v + ∇ • W = f 2 .
(

) 2
with W another stress tensor and

f 2 = -f 1 (M ) + ε 0 (ε r -1)∂ t (E × B).
Since W vanishes outside the object one identifies F = f 2 dV as the force exerted by the electromagnetic field on the matter. From Newton's third law one expects that f 1 = -f 2 . This is not valid for neither the Minkowski nor the Peierls version, and true only for the Abraham version if µ r = 1. The version for which Newton's third law strictly holds is the Nelson version [6], in which the radiative momentum density is chosen as G = G N = ε 0 E × B, i.e. equal to the expression in vacuum.

When taking a quantum-mechanical approach to the problem, new controversies seem to appear. It is well-known that the presence of magnetic fields makes the kinetic momentum P kin = i m i ṙi different from the conjugated momentum P = P kin + 1 2 i q i B × r i . This difference was recently put forward as a solution to the AM controversy [7]. However, in quantum mechanics a third "pseudo-momentum" K = P kin + i q i B × r i appears that is conserved in time [8], and clearly different from the other two. It is easy to verify that the validity of the Nelson version is directly related to the conservation of K. A second controversy was initiated by Feigel. [9], arguing that the quantum vacuum provides an additional contribution to the Abraham force. This proposition was refuted theoretically [8] and experimentally [10].

The experimental observation of the Abraham force induced by an oscillating electric field and a static magnetic field was reported by James [START_REF] James | Force on Permeable Matter in Time-varying Fields[END_REF] and by Walker et al [START_REF] Walker | [END_REF]13] in solid dielectrics, and recently by Rikken and Van Tiggelen in gazes [10]. These observations clearly invalidated the Minkowski version for f 1 although modifications of the Minkowsi energy-momentum tensor have been proposed to make it consistent with these results [14,15]. However, the Abraham force due to an oscillating magnetic field and a static electric field has so far never been observed and was even reported unobservable in a specifically designed experiment [16,17]. The two cases clearly correspond to physically different situations. A time-dependent electric field creates moving charges (J q = ∂ t P) that are subject to the Lorentz force. A time-varying magnetic field induces a rotational electric field that acts on the polarization charges. Walker et al suggested an explanation for their failure to observe the E×∂ t B component [18], involving the compensation of this bulk component by a surface contribution. The current experimental situation around the AM controversy for low-frequency electromagnetic fields is therefore unsatisfactory as not a single prediction for the Abraham force is experimentally confirmed. At optical frequencies the situation is even less clear. Here, the Abraham force cannot be observed directly, as it averages to zero over one cycle, and one has to resort to the observation of momentum transfer from light to matter, with the aforementioned conceptual difficulty which type of momentum to consider. For recent discussions, see the two comments [19] on the work of She et al [20].

In this Letter we report the first observation of the intrinsic Abraham force on a dielectric induced by a timevarying magnetic field. Our observations reveal the symmetry between electric and magnetic variations, i.e we confirm f ∝ ∂ t (E × B), excluding the Peierls' version of radiative momentum, and in particular confirming the Abraham and Nelson versions. We cannot discriminate between the latter two, as µ = 1 in our case. On the theoretical side, our finding supports the dominant role of pseudo-momentum in the controversy on radiative momentum, and not the one of kinetic or conjugated momentum as was suggested by other work [7].

A schematic view of our experiment is shown in Fig. 1. The sample consists of a slab of Y5V dielectric recovered from a ceramic capacitor [START_REF]Multicomp, part no[END_REF] (measured ε r = 1, 7 10 5 ). It is covered on both faces by a silverpaint electrode and mounted by means of an insulating spacer on a piezoelectric bimorph cantilever [22]. The sensitivity of the cantilever was determined by applying a known force to the sample and measuring the charge generated by the cantilever with an electrometer. An oscillating magnetic field B cos ω B t is applied perpendicular to the electric field E cos ω E t inside the slab. The cantilever signal is phase sensitively detected at ω B + ω E and corresponds therefore to a force on the sample proportional to E(t) × B(t). All other possible forces that would result from field gradients give a net zero contribution because of the symmetry of our experimental geometry and appear at other frequencies (see Eq. 1).

A typical result is shown in Fig. 2. A clearly linear electric and magnetic field field dependence of this force is observed, which we therefore identify as the Abraham force. The linear dependence of F A = f A V , where V is the sample volume, on the frequency of the electric field, crossed with a static magnetic field, was explicitly verified by Rikken and Van Tiggelen [10], i.e. F A ∝ ∂ t E × B. To investigate the dependence of F A on the magnetic field variation in time, we have varied ω B whilst keeping ω B + ω E constant. This guarantees that the sensitivity of our cantilever remains constant. The result is shown in Fig. 3, and shows clearly a strictly linear dependence on the electric field frequency. So we find quantitative agreement with a prediction f A = ε 0 (ε r -1) ∂ t E × B (dashed line) and not at all with the predicted f A = ε 0 (ε r -1) ∂ t (E × B) (dot-dashed line) (µ = 1 for Y5V). From this, one could infer the absence of a contribution to F A of the form E × ∂ t B. This concurs with the findings by Walker et al [16]. The explanation for the apparent absence of such a contribution is the almost complete compensation of this contribution by an additional force on the electrodes. Walker et al [18] have proposed a description for such a compensation in terms of the Maxwell stress tensor. We propose a simpler explanation, based on the different space charges present in the sample-electrode system, as illustrated in Fig. field E ind that obeys

S E ind • dl = ∂ t B • dS (3)
The Abraham force on the dielectric due to a time varying magnetic field corresponds to the force exerted by E ind on σ 2 and σ 3 but it will be almost completely compensated by the force exerted by E ind on σ 1 and σ 4 i.e. on the electrodes. It follows that the force due to a time varying magnetic field on the ensemble of electrodes plus dielectric is only 1/ (ε -1) of this force on the dielectric alone. It is therefore very difficult to observe the E × ∂ t B contibution to the Abraham force when the electric field is supplied by electrodes that are fixed to the dielectric. In order to observe the intrinsic Abraham force on the dielectric, including the E × ∂ t B contribution, we have used a configuration, where the electrodes are no longer rigidly connected to the dielectric (Fig. 5). The electrodes are fixed in the laboratory frame, and the sample is fixed to the cantilever, but otherwise free to move. The electrical contact between sample and electrodes is provided by an ionic liquid [START_REF]Sigma-Aldrich, 1-butyl-3-methyl imidazolium tetrafluoroborate[END_REF]. Now the ionic surface charges on the liquid side of the liquid-sample interface (i.e. the equivalents of σ 1 and σ 4 ) that almost balance the surface charges on the sample, can move freely in the liquid along the interface under the influence of E ind . They would therefore in the ideal case not exert any force on the sample. In practice such ionic movement will partially be transferred to the sample by the inevitable viscous drag of the liquid on the sample. Therefore partial compensation of the Abraham force on the sample may still occur in this configuration, but it should be much weaker than for the case of fixed electrodes. Such a drag could also transfer a part of the Lorentz force F L, experienced by the ionic current in the liquid, to the sample. It can be easily shown that this Lorentz force is given by F L = IBl = 2πf E CV Bl, where I is the current passing through the liquid, l is the total thickness of the two liquid layers, C the capacitance and V the applied voltage.

The result of the measurement of the Abraham force with the liquid contacts is shown in Fig. 6 as a function of the electric field frequency f E , where f E + f B is kept constant. We clearly observe an Abraham force that does not vanish for low f E as in Fig. 3. The full symbols are the raw data, the open symbols are the data when corrected for the measured resistive losses in the ionic liquid, which somewhat reduce the electric field on the Y5V slab. Currently we do not have a conclusive explanation for the small remaining negative slope. Combined with the earlier result that F A ∝ f E for a constant magnetic field [10], Fig. 6

proves that F

A ∝ f E + f B ∝ ∂ t (E × B).
For our parameters, the Lorentz force on the liquid is F L = 1, 5 nN at f E = 100 Hz and it has the same sign as F A . Its contribution to the observed force on the sample can therefore be neglected at low f E . In the liquid contact configuration, it is difficult to accurately determine the size of the contacted area of the sample and thereby of the absolute value of the driving Abraham force density. From the measured capacitance value we deduce a contacted area that would result in an Abraham force of 15 nN , in reasonable agreement with the observed value.

In conclusion, we have confirmed the suggestion by Walker et al. [16,17] that in solidly contacted dielectrics, the only measurable contribution to the Abraham force is of the form ∂ t E × B. We have provided a simple explanation for this apparent absence of a E × ∂ t B contribution in terms of the compensating surface charge in the electrodes.

For a dielectric that is contacted by means of a conducting liquid, we have observed the intrinsic Abraham force, which we find to be proportional to ∂ t (E × B), thereby explicitly verifying the Abraham and Nelson predictions of the mechanical force density of electromagnetic fields in dielectrics. This result greatly limits the arbitrariness in Eq. 1, leaving only the possibility to assign terms derived from Maxwell's equations to either the momentum or the stress tensor, but not to the force. In particular, our results invalidate the Minkowski and Peierls versions of electromagnetic momentum. In the solution proposed by Ref [7] the Abraham version was associated with kinetic momentum, and Minkowski version with canonical momentum. We have argued that the Nelson version is intimately related to a third pseudo momentum. To finally discriminate between the two remaining candidates, the Abraham and Nelson versions, one would have to discriminate between (ε r -1/µ r ) and (ε r -1) as pre-factor, which will be the subject of future work.

FIG. 1 :

 1 FIG.1: Schematic setup of the experiment. A magnetic field B is applied perpendicular to the drawing at frequence ωB, and high voltage at frequency ωE is applied to the electrodes of the sample. The cantilever signal is phase sensitively detected at the sum frequency ωB + ωE. Typical sample size is 9 x 2 x 0,35 mm 3 .

4 .

 4 FIG. 2: Abraham force exerted on a slab of Y5V dielectric by crossed oscillating electric and magnetic fields (fi = ωi/2π). Straight lines are linear fits to the data.

FIG. 6 :

 6 FIG.6: Abraham force measured on a Y5V slab, contacted by an ionic liquid as illustrated in Fig.5. fE + fB = 690 Hz. Solid line is a linear fit to the raw data (closed symbols). Dashed line is a linear fit to the corrected data (see text).

We gratefully acknowledge Julien Billette for coil construction. This work was supported by the ANR contract PHOTONIMPULS ANR-09-BLAN-0088-01.


Marco Danelutto
email: marcod@di.unipi.it

Roberto Di Cosmo
email: roberto@dicosmo.org

A "minimal disruption" skeleton experiment: seamless map & reduce embedding in OCaml

Keywords: structured parallel programming, algorithmic skeletons, map, reduce

We discuss the implementation of a minimalist parallel library in OCaml. The library provides parallel map and fold (reduce) higher order functions and targets standard cache coherent shared memory multi-cores. Our Parmap.parmap and Parmap.parfold functions may be used to seamlessly replace OCaml List map and fold standard functions preserving their full functional semantics while achieving nearly optimal speedup on standard multi-core architectures. We discuss the design of the Parmap module, the main implementation features and we present some experimental results assessing the efficiency of the Parmap parallel functions. Overall, Parmap represents a perfect incarnation of the "propagate the concept with minimal disruption" principle introduced in Cole's algorithmic skeleton manifesto.

Introduction

Multi-cores with some kind of shared memory subsystem constitute the de facto standard computing elements in a wide range of systems, from mobile phones and tablets to workstations and servers, up to high end parallel computer systems. However, the development of efficient applications for these inherently parallel systems still requires a consistent design and programming effort. Classical programming techniques exploiting threads and the associated cooperation and synchronization machinery represent a kind of "assembly level parallel language" for multi-cores, and inherit all the problems of low level languages: writing efficient multithreaded code is difficult and error prone, debugging and maintenance are even more problematic. The adoption of slightly higher level programming paradigms such as OpenMP improves programmer productivity with respect to plain Pthreads, but still requires a consistent expertise to tune all the available parameters in such a way that good efficiency is achieved.

Several authors suggested to fill the evident gap between programmability and available parallelism in multi-cores with different kinds of structured programming models: parallel design patterns [START_REF] Mattson | Patterns for parallel programming[END_REF] as in [START_REF] Asanovic | A view of the parallel computing landscape[END_REF][START_REF] Goswami | From design patterns to parallel architecture skeletons[END_REF] or algorithmic skeletons [START_REF] Cole | Bringing skeletons out of the closet: A pragmatic manifesto for skeletal parallel programming[END_REF] as in [START_REF] Aldinucci | Muskel: an expandable skeleton environment[END_REF][START_REF] Ciechanowicz | Enhancing Muesli's Data Parallel Skeletons for Multi-Core Computer Architectures[END_REF][START_REF] Di Cosmo | Skeletal parallel programming with ocamlp3l 2.0[END_REF][START_REF] Enmyren | SkePU: A Multi-Backend Skeleton Programming Library for Multi-GPU Systems[END_REF][START_REF] Leyton | Skandium: Multi-core programming with algorithmic skeletons[END_REF], just to name a few examples. Algorithmic skeletons, in particular, promise to raise the level of abstraction provided to parallel application programmers by making available mechanisms-language constructs, objects, components or plain library calls-that completely encapsulate and manage a parallelism exploitation pattern. The application programmer writing a parallel application is therefore only left with the duty of picking up and instantiating the proper (composition of) skeletons modelling the parallelism at hand from a library of predefined, optimized and, possibly, portable algorithmic skeletons.

The price to pay with algorithmic skeletons is the necessity for the programmers to "learn" new concepts-the algorithmic skeleton (parallel) semantics-in order to be able to write parallel applications.

Actually, the "four principles which we believe should guide the future design and the development of skeletal programming systems" stated in Cole's "skeleton manifesto" [START_REF] Cole | Bringing skeletons out of the closet: A pragmatic manifesto for skeletal parallel programming[END_REF] included the principle stated as "propagate the concept with minimal conceptual disruption". In other words, the principle states algorithmic skeletons should be introduced in such a way that programmers are not required to do things far from their normal programming activity or requiring brand new knowledge and competences.

In this work, we present an experiment aiming at providing parallel algorithmic skeletons to OCaml programmers fully respecting Cole's minimal disruption principle: we provide a lightweight OCaml library that presents to the OCaml programmer a simple replacement of the basic operations on lists provided by the standard library, namely List.map and List.fold right/ List.fold left that implement the now well known map and reduce paradigm1 . Our replacement functions implement the map and fold operations in parallel, using the existing cores of the processor at hand, in a very efficient and clean way.

The advantage is twofold: on the one hand, OCaml programs with heavyweight map, reduce, and map-reduce computations may be seamlessly improved by just changing the name of the library calls used, e.g. invoking our Parmap.parmap instead of the classic List.map one; on the other hand, a simple speedup model is exposed to the OCaml programmers-use Parmap calls any time you want to improve independent data parallel or reduce style computation execution times-that may be taken into account when designing new complex and time consuming applications with many items to be processed independently.

The rest of this paper outlines the Parmap design issues and choices (Sec. 2), provides a detailed description of its current implementation (Sec. 3), reports several experimental results assessing its feasibility and efficiency (Sec. 4) and finally discusses the relevant related work (Sec. 5).

Parmap design

Suitable strategies for the parallel computation of map and reduce are well known. The computation of a map requires applying the same function to all the elements in a list:

map f [x 1 ; . . . ; x k ] = [f x 1 ; . . . ; f x k ]
In a pure map, all the (f x i ) computations are independent and therefore any partition of the result list may be computed in parallel. The result of a reduce ⊕ applied to a list is

reduce ⊕ [x 1 ; . . . ; x k ] = x 1 ⊕ . . . ⊕ x k
The ⊕ function is required to be associative and commutative. If we imagine the reduce computation as a tree of ⊕ applications, any sub tree rooted at a node at level j may be computed in parallel and the partial results of the computations of the sub trees may be then "summed up" with a sequential application of ⊕ to compute the final reduce result.

The idea of Parmap is to exploit the cores available on modern architectures to compute in parallel maps and reduces (folds) using the following steps:

Step 1 The input list is split into a number of partitions which may be specified by the programmer or default to the number of available cores.

Step 2 Each partition is independently computed. In case of a map, each element x i is transformed using the "worker" function f into (f x i ). In case of a reduce, the partition elements x j , . . . , x j+k are summed up using the worker function ⊕ into x j ⊕ . . . ⊕ x j+k .

Step 3 The partial results are combined into the final result. This happens sequentially. In case of a map, the sub lists are appended; in case of a reduce, the partial results are summed up using again the ⊕ function.

As far as reduce is concerned, this computing schema corresponds to first computing in parallel all the y j defined as

y 1 = x 1 ⊕. . .⊕x n1 y 2 = x n1+1 ⊕. . .⊕x n2 . . . y k-1 = x n k +1 ⊕. . .⊕x n
that is the reduces computed on the k different partitions, and then computing sequentially the final result

y 1 ⊕ y 2 ⊕ . . . ⊕ y k-1
Therefore steps 1 and 3 should be performed as fast as possible as they represent the "serial fraction" of the algorithm and it is their duration that will eventually limit the final speedup according to the well known Amdahl law. Sec. 3 will detail the steps performed in these two phases to minimize the overheads.

As far as the user interface of Parmap is concerned, we chose to implement the "minimal disruption" principle by providing a Parmap through a standard OCaml module with an interface as close as possible to that of the List module. The List module provides the map and fold_right functions with the following signatures:

L i s t . map : ( ' a -> ' b ) -> ' a l i s t -> ' b l i s t L i s t . f o l d r i g h t : ( ' a -> ' b -> ' b ) -> ' a l i s t -> ' b -> ' b
The signature of the corresponding Parmap functions is instead: type ' a s e q u e n c e = L o f ' a l i s t | A o f ' a a r r a y v a l parmap : ? n c o r e s : i n t -> ? c h u n k s i z e : i n t -> ( ' a -> ' b ) -> ' a s e q u e n c e -> ' b l i s t v a l p a r f o l d : ? n c o r e s : i n t -> ? c h u n k s i z e : i n t ->

( ' a -> ' b -> ' b ) -> ' a s e q u e n c e -> ' b -> ( ' b->'b ->'b ) -> ' b
If we disregard the optional parameters, the signature of the List.map is the same of the signature of Parmap.parmap, but for the fact the "collection" processed is not an 'a list but rather it is an 'a sequence. We used the 'a sequence to uniformly support the possibility to process both lists and arrays. The optional parameter ncores has been included to control the number of cores to be used, while the chunksize parameter has been included to control the parallelism grain. In order to get a parallel version on n cores of a program with a computationally expensive l e t r e s = L i s t . map f l it is therefore sufficient to change the code into l e t r e s = Parmap . parmap ˜n c o r e s : n f ( Parmap . L l )

This will run achieving a speedup very close to the number of cores on the target architecture2 (see Sec. 4).

The Parmap.parfold has a signature which is the same one of the List.fold right but for: i) the optional parameters (that can be obviously omitted), ii) the 'a sequence used instead of the 'a list, for the very same reasons discussed for the map, and iii) the additional "combine" operator with type 'b -> 'b -> 'b. This last parameter is the only one real, significant difference with the List.fold right. It has been introduced to be able to specify two different ⊕ operators: one for the reduce computed in parallel on the different partitions (this is the first 'a -> 'b -> 'b parameter) and one for the reduce operator needed to accumulate sequentially the final parfold result out of the partial reduce results computed on the different partitions (the last 'b -> 'b -> 'b) parameter). This may be useful in some particular cases. However, if the user wants to parallelize an expression such as

( L i s t . f o l d r i g h t o p l u s l i s t o p l u s z e r o )
it is sufficient to substitute it by the expression It's worth mentioning that when it is used without the load balancing optimization described in section 3.1, Parmap.parfold actually does not require that the ⊕ operator(s) be commutative: in that case, the fold computed in parallel on the different partitions are internally sequential, and composed in the same order, so commutativity is not used (lines 25-29 of Figure 1).

When the load balancing optimization is used, however, commutativity is required, as usual in the implementations of fold operations that seek to achive performance using asynchronous mechanisms that force out-of-order evaluation on the elements of the input data.

Parmap implementation

The first choice we had to make when implementing Parmap was between the two main mechanisms available to run in parallel the workers of the second step: processes or threads. Although threads are normally the standard choice on multi-core architectures, we were forced to use processes because in the current implementation of OCaml, all threads are run concurrently on the same core, so no speedup can be achieved using threads.

Our process-based implementation requires some additional effort for step 1 and 3, but also provides an interesting encapsulation of side effects: they are not propagated to the global state when the results are built after computing a map, thus enforcing the embarrassingly parallel pattern modelled by this kind of map.

Having chosen processes as the way of implementing step 2, we moved on to implement step 1 and 3, trying to minimize their overhead to maximize speedup. Figure 1 shows the essential parts of the OCaml code used for the simplest form of implementation of our library.

Step 1 In step 1, (lines 3 to 9 in the code) a number of processes is forked according to a user provided parameter3 .

Step 2 After the fork, each child process (lines 11 to 16 in the code) inherits the state of the parent automatically, so it can determine the interval lo...hi of the data it must handle, by using the local value of the i index (lines 11 to 13). The computation is then performed in line 14 on the specified segments using the function compute that is built out of the user function according to the operation to perform (map, reduce or map/reduce). Finally, in line 15, the result is marshalled into a shared memory area associated to a file descriptor indexed by i.

Step 3 After all the children have finished (line 21), the parent collects the list of the results from the children by unmarshaling the data contained in the shared memory areas associated to each child (lines 25-17), and combines them in line 29 using a function combine that is also built out of the user function according to the operation to perform (map, reduce or map/reduce). This schema allows to provide Parmap functions processing either lists or arrays, and this is the reason why in Sec. 2 the Parmap signature exports the 'a sequence type definition and all generic Parmap entries accept 'a sequences.

As already stated, step 1 and step 3 represent the serial parts of our implementation, and they should be carefully optimized in order to be able to achieve suitable speedups. Step 1 mainly relies on the fact that the fork is very efficient and in modern operating system manages to copy on demand the pages that are written to by the child process. This means that in our case-child process read their own data partition and actually only write the results of the computation on the input partition-the overhead paid is fairly negligible. We made some experiments aimed at measuring the overhead incurred in the fork phase of the child processes. The time in between the start of the Parmam.parmap call and the start of the activities of the forked child processes is of the order of milliseconds (5-25 msecs). It's worth to point out that this time includes all the setup activities needed to prepare the communication channels in between the forking process and the forked child processes, which includes quite a number of system calls. We also measured the time between the end of the parallel partition processing and the end of the Parmap.parmap call, that is the time needed to implement Step 3 in the schema detailed above. In our experiments, using the machines detailed in Sec. 4, we verified that Step 3 takes milliseconds to complete too (2-3 msecs). At the end of Sec. 4 we will comment more on the impact of such "serial fraction" times.

Load balancing and other optimizations

The simple implementation described above has one major drawback: it does not allow the grain of the parallel computation to be specified. Indeed, we can only use it with a number of chunks equal to the number of cores (the chunksize is computed in line 4 from the length of the sequence). If the chunks are big and their computation cost is non homogeneous, this can severely hinder performance. This is why the library also contains a more sophisticated implementation that refines simplemapper using a bidirectional channel between the main process and the children. Each child requests (the index of) a chunk, performs the computation and accumulates the result locally, and repeats this cycle until the parent signals that the computation is complete; at that point, it returns the result in the shared memory area, exactly as in the case of the simplemapper function above. This algorithm corresponds to the well known on demand schema for process farms, that achieves automatic load balancing [START_REF] Aldinucci | Muskel: an expandable skeleton environment[END_REF]. It is used whenever the chunksize specified by the user forces more than one chunk on a core.

The implementation of the Parmap exported functions can then be written as follows, where mapper calls either the simplemapper shown above, or the on-demand implementation we just described, according to the value of chunksize We also considered the issue of the kernel scheduler moving some of the processes in charge of computing in parallel Parmap chunks from one core to another. As different core groups usually share cache levels, if the process is moved to a different group of cores cache usage turns out to be inefficient. Parmap therefore implements process pinning. The processes created to process Parmap partitions are forced to be executed on exactly one core among those available. This mechanisms lowers the number of cache faults, and therefore improves the general efficiency of Parmap (see Sec. 4).

Special optimizations for manipulating arrays of floats

Another performance bottleneck comes from the need to perform marshaling and unmarshaling of the results between the parent and the children processes: when using a strongly and statically typed programming language, like OCaml, this operation is unavoidable unless one knows the precise type of the return data, and its exact size.

But there is one important situation in which we actually know the size and the type of the result: the mapping of a floating point operation on large arrays of floats. This particular configuration is common enough in numerical code to deserve a special treatment, and our library provides a highly optimised function array float parmap that avoids the marshalling overhead completely. We highlight here these optimisations.

To understand the efficiency issues involved when parallelizing a map computation on a large array of floats, it is useful to examine the different steps that an implementation of a parallel map function may need to perform.

1. create an array to hold the result of the computation. This operation involves an initialisation phase and can be expensive: on an Intel i7, creating an array of 10 million floats takes 50 milliseconds;

2. create a shared memory area for returning the result; Steps 1, 2 and 4 are unavoidable: the return array and the a shared memory area for returning the result must be created (one might merge these two operations into one, but without a significant cost saving), and of course one needs to perform the required computation. On the other side, steps 3 and/or 5 may be omitted depending on what the user wants to do with the result:

• using precise knowledge on the layout of arrays of floats in OCaml, one can access the shared memory area as if it was an array of floats, without need to copy the result array into this area (this is what our code does);

• it may be safe to leave the result in the shared memory area, to be reused by later calls, but for this one needs to give up the benefit of automatic garbage collection on the result array, as the content of the shared memory area is not garbage collected (we decided agains this solution in our code).

The array float parmap function in our library performs only the steps 1, 2, 4 and 5. These optimizations allow to reduce the overhead of the parallel map operation quite significantly with respect to the stock implementation of parmap on arrays.

It is also possible for the user to share the steps 1, 2 among subsequent calls to array float parmap by preallocating the result array and the shared memory buffer, and passing them as optional parameters; this may save a significant amount of time if the array is very large and the operation is repeated frequently.

Experiments

We run a number of experiments aimed at validating the Parmap design. Actually, these experiments contributed to understanding the reason of different overheads in the first Parmap versions and to understanding which were the most effective ways to get rid of them. It's worth pointing out that our Parmap library has been published quite early as open source: as a consequence, we received comments and suggestions from different OCaml parallel programmers that helped improve the efficiency of Parmap.

The experiments have been run on several different architectures, including Intel i3 and i7 CPUs and more aggressive dual Xeon E5520 (8 cores in total) and dual AMD Opteron 6176 (24 cores in total) CPUs. All the results reported in this Section have been achieved using synthetic applications. Fig. 2 shows speedups achieved when computing a map with a simple synthetic worker function on integers in an application made of a single map call. The plot on the left shows speedup obtained just by changing a map f l with a Parmap.map f (Parmap.L l). The plot on the right shows slightly better results in the execution of the same application on the AMD Opteron. It is related to the very same application where we manually specified a chunksize for the Parmap. As evidenced by the different curves, however, finding the correct chunksize value is not in general an easy task.

Typical speedups do not change significantly in case computations performed floating point operations are considered, although in this case hyper threading on Xeon is less effective, due to the scarce duplication of floating point resources. Fig. 3 left shows the speedup of an application with the same structure of the one used in Fig. 2 but using a floating point number crunching worker function.

The amount of computation performed on the single item is anyway significant, as shown in Fig. 3 computation of the single element, the better the speedup, as expected. In this case the processing of the whole list (20K elements) requires a sequential time as shown in the legend. Therefore the time spent in computing the single element is in the three cases 27.5µsecs, 270.5µsecs and 2.75msecs, respectively. This latter value leads to almost linear speedup. These performance figures may be better appreciated if we take into account the overheads measured for the Parmap.parmap serial fraction discussed in Sec. 3. With times spent in the serial fraction of the algorithm in the range of milliseconds, it is clear that we can only obtain good speedups when the overall amount of time spent in the sequential computation makes these milliseconds negligible. Amdahl law states the maximum speedup we can achieve is 1 f , with f representing the serial fraction of the algorithm. Therefore, to achieve a speedup of n-the parallelism degree of our architecture-we should have a serial fraction smaller than 1 n . In our case, this means that when our sequential time is in the range of half a second (T seq = 0.55secs in the right plot of Fig. 3) and considered the serial overhead (Step 1 plus Step 3) exceeds the tens of milliseconds, we will definitely not be able to achieve the expected speedup values on the 24 core architecture.

Parmap.parfold behaviour is not different from the one demonstrated by the Parmap. Fig. 4 (left) shows the speedups achieved on the AMD 6176 Opteron architecture when parallelizing a program made of a single fold call by substituting the List.fold right with a Parmap.parfold without any optional parameters. Speedups do not change when using Parmap functions operating on arrays, instead of lists (see Fig. 4 right), as expected.

Fig. 5 shows the effects of thread pinning. The left plot is relative to the application running sequentially in 55 secs. These application scales pretty decently on the 24 core architecture. In this case the effect of pinning is evident. The right plot is instead relative to the synthetic application running sequentially in about 5.5 seconds. In that case, as evidenced also in Fig. 3 the application efficiency is much lower. In these cases pinning actually do not add any kind of benefit, although it does not even introduce any sensible additional overhead.

Since we are proposing a "minimalistic" parallel skeleton library for Ocaml, we were more interested in demonstrating the different features of the library rather than showing speedups achieved in real applications, that almost never turn out to be just a single call to a map or to a reduce function. This is why all the experiments whose results have been discussed in this Section are relative to execution of synthetic benchmarks, and not real applications.

The actual speedup measured running real applications with calls to Parmap functions will be greatly affected by the particular mix of Parmap and non Parmap code and could be hardly used to evaluate the efficiency of the Parmap implementation. Nevertheless, based on the feedback we received from actual users of the library, we can say that real applications actually benefit from the usage of Parmap proportionally to the amount of time spent in the map or fold call in the sequential execution, as expected.

Related work

Several attempts have been made to provide parallel libraries according to the "minimal disruption" principle. SkeTo [START_REF] Tanno | Parallel skeletons for variable-length lists in sketo skeleton library[END_REF] implements a data parallel only skeleton library in C/C++. The data parallel skeletons are implemented through library functions that are seamlessly called within user sequential code, much in the style of our Parmap. This framework can be hardly compared with Parmap, due to the fact the programs are written in imperative style. STAPL [START_REF] Thomas | A framework for adaptive algorithm selection in stapl[END_REF] is a C++ library providing "parallel containers" with adaptive implementation of standard parallel algorithms that can be used on both multi-cores and distributed architectures. The "minimal disruption" problem is addressed here by providing container classes and algorithms as much as possible close to the one in the standard C++ library.

Other functional programming frameworks based on the concept of algorithmic skeletons have been designed in the past. OCamlP3l [START_REF] Danelutto | Parallel functional programming with skeletons: the OCamlP3L experiment[END_REF] used a quite different template based implementation and targets TPC/IP POSIX distributed architectures. It requires a substantially different programming style with respect to the one guaranteed by Parmap. The same remark apply to the Functory system [START_REF] Filliâtre | Functory: A Distributed Computing Library for Objective Caml[END_REF], which is quite similar in spirit to OCamlP3l. Parallel Haskell [START_REF] Trinder | Parallel and distributed Haskells[END_REF] and Erlang [START_REF] Cesarini | Erlang programming: a concurrent approach to software development[END_REF] both provide nice parallel programming frameworks targeting multi-cores and distributed architectures. Parallel Haskell, in particular, provides suitable ways to define skeletons by specifying parallel evaluation strategies for higher order functions modelling the skeleton functional semantics. Although specifying a parallel evaluation strategy only requires minimal syntactic modifications to the sequential code, it actually requires some extra knowledge from the programmer with respect to the kind of knowledge required to the Parmap programmer. In particular, the Haskell programmers are required to figure out which is the better parallel strategy to use among the ones available, whereas the Parmap programmer is just required to substitute a function call and all the details related to the parallel implementation are transparently handled by the Parmap implementation. While the Haskell approach may support more general parallel patterns, our approach supports a smoother integration within the "normal" (sequential) programming style of programmers. Map and reduce have been considered as convenient structured parallel programming constructs since a very long time. Backus individuated them as convenient higher order functions in his Turing award lecture [START_REF] Backus | Can programming be liberated from the von neumann style? a functional style and its algebra of programs[END_REF]. Although not explicitly targeting parallel execution, the algebra of programs defined in Backus's masterpiece have been used by a number of researchers to support development of frameworks providing parallel map and reduce. Bird and Meertens elaborated a complete theory supporting concepts related to parallel execution of map and reduce in the '80 [START_REF] Skillicorn | The Bird-Meertens formalism as a parallel model[END_REF]. This theory has been used in SkeTo to apply automatic program transformations improving program performance and, although never mentioned in their papers, is the reason of the success of Google's mapreduce [START_REF] Dean | Mapreduce: simplified data processing on large clusters[END_REF].

Conclusions

Parmap is a minimalistic library allowing to exploit multi-core architecture for OCaml programs. It has been designed with the goal of providing parallel map and reduce to OCaml programmers in a fairly natural way, such that the "minimal disruption" principle stated by Cole in his skeleton manifesto paper is enforced. In fact, in order to use Parmap, it is sufficient to substitute the calls to List functions with calls to the equivalent Parmap functions. The clean and efficient implementation of Parmap is such that nearly optimal speedups are achieved on state-of-the-art multi-core architectures when suitable grain computations are parallelized. The full source code of the Parmap library is available under the LGPL licence from http://gitorious.org/parmap, and is now also incorporated in the GODI installation system for OCaml librairies.

(

  Parmap . p a r f o l d o p l u s ( Parmap . L l i s t ) o p l u s z e r o o p l u s )

1 2 ( 5 ( 7 ( * spawn c h i l d r e n * ) 8 f o r i = 0 t o n c o r e s -1 do 9 match 11 ( l e t l o=i * c h u n k s i z e i n 12 l 16 e x i t 0 ) 17 | - 1 - 18 | 20 ((Figure 1 :

 2578911121617118201 Figure 1: Simple implementation of the distribution, fork, and recollection phases in Parmap

  l e t parmap ? n c o r e s ? c h u n k s i z e ( f : ' a -> ' b ) ( s : ' a s e q u e n c e ) : ' b l i s t = l e t a l = match s with A a l -> a l | L l -> Array . o f l i s t l i n l e t compute a l l o h i p r e v i o u s e x c h a n d l e r = l e t f ' j = f ( Array . u n s a f e g e t a l ( l o+j ) ) i n l e t r e c aux a c c = f u n c t i o n 0 -> ( f ' 0 ) : : a c c | n -> aux ( ( f ' n ) : : a c c ) ( n-1) i n aux p r e v i o u s ( hi-l o ) i n mapper n c o r e s ˜c h u n k s i z e compute [ ] a l ( fun r -> L i s t . c o n c a t r )

Figure 2 :

 2 Figure 2: Sample Parmap speedup (left: Parmap with no optional parameters, right: with different chunksize values)

Figure 3 :

 3 Figure 3: Parmap speedup (int vs floating point computations on Intel Xeon E5520) (left) and effect of grain (on AMD Opteron) (right)

  right: the higher the amount of time spent in the

Figure 4 :

 4 Figure 4: Sample parfold speedup (left) and comparison lists vs. arrays (right) (AMD Opteron 6176 x2)

  Effect of pinning: speedup in case of coarse grain/scalable (left) vs. finer grain/non scalable (right) applications (AMD Opteron 6176 x2)

	24								24
		Pinned									Pinned
	22	Unpinned Ideal							22		Unpinned Ideal
	20								20
	18								18
	16								16
	14								14
	12								12
	10								10
	8								8
	6								6
	8	10	12	14	16	18	20	22	24	8	10	12	14	16	18	20	22	24
					#cores									#cores
	Figure 5:

this is the reason why we'll use the terms fold and reduce basically as synonyms from now on

Of course, this is true if the whole computation of the program is represented by the res map. If more computations are performed, these will be not affected by the Parmap and therefore the overall speedup will be smaller according to the Amdhal law.

In the real implementation, this defaults to the number of cores in the target architecture (derived through proper library calls).

The authors would like to thank Paul Vernaza, François Berenger and Pierre Chambart for stimulating discussions about Parmap, Jérôme Vouillon for his contributions to the code that greatly improved its efficiency, Pietro Abate for help with the build system, and Jérôme Maloberti for creating the package for the GODI OCaml distribution system.

 [START_REF] Mattson | Patterns for parallel programming[END_REF]This work has been partially supported by EU FP7 STREP Project ParaPhrase, and partially performed at IRILL, http://www.irill.org.


Denis Carvin
email: carvin@laas.fr

Philippe Owezarski

Pascal Berthou
email: berthou@laas.fr

Pascal Berthou Managing

Managing The Upcoming Ubiquitous Computing

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

The IoT still misses its so necessary "killer application" which would provide us both a cheaper technology and an uncharacterized traffic. To trigger the popularity of the IoT while keeping an eye on what it could turn into, we introduce the UCSM use case. One can say that it is a monitoring and management application for the IoT which takes advantages from the tiniest nodes while considering their capabilities. This paper promotes a communication architecture dedicated to this use case. Therefore, the next section exposes the state of the art of three main concepts while the third section gives an outlook of the UCSM paradigm which intends to make them converge. The section four presents our first research initiatives and our conclusion mentions future research steps.

II. A BRIEF REVIEW OF THREE PROMISING CONCEPTS

The novelty of our approach comes from the intersection of three main research fields. This section briefly presents their concepts and problematics.

A. Ubiquitous Computing And The IoT

IoT is the generalization of Internet to objects and can be seen as the participation of wireless sensor and actuator networks (WSAN) and Radio-frequency identification (RFID) to the IPv6 network. We distinguish WSAN which organize objects specifically designed to give intelligence to the environment, from RFID which most of the time only identifies basic objects. This distinction is illustrated by the classical vision in the Figure 1. WSAN offers new solutions for a variety of areas from environmental monitoring, to smart museum or gym [START_REF]The internet of things: A survey[END_REF]. Despite the fact that each of these areas has its own concerns and relies on specific solutions, alliances and workgroups pursue their efforts to suggest some standards that offer compromises. The main trade-off is between performance and longevity. RFID is a much more mature technology which favors longevity and benefits from a myriad of standards. It has the functionality of a small writable memory used as an electronic bar-code (tag) to identify anything. The interrogated tag is passive and scavenges the energy from the radio wave of its reader to transmit the requested information [START_REF] Finkenzeller | RFID Handbook: Fundamentals and Applications in Contactless Smart Cards and Identification[END_REF]. The range can be reduced for privacy purposes in the case of Near Field Communication (NFC). We can infer from trade journal that this latter technology attracts leading companies and that a rapid convergence of standard will enable a worldwide usage of RFID. Apple already owns a patent to integrate RFID reader into their Touchscreen (US Patent 20090167699). On its side, Google recently acquired Motorola Mobility and is working on a NFC API for Android using state of the art NXP integrated circuits for their phones. This new type of communication and the way people will use it will definitely impact on the way to manage network equipments.

B. System Monitoring And Management

To reach a certain level of quality, complex system require tools that measure, monitor, and manage them. These tools are crucial to better understand and improve the global behavior of a system by identifying its internal mechanisms. When a system is managed or monitored, the common cycle is (1) measure and observe, [START_REF] Finkenzeller | RFID Handbook: Fundamentals and Applications in Contactless Smart Cards and Identification[END_REF] analyze to build a new set of knowledge, (3) make a decision. Social systems and communication networks are systems we both try to measure, understand and manage, their evolutions are co-dependent. In fact, there is only one step between them and it is called reality mining. This recent paradigm studies social systems thanks to communication networks [START_REF] Altshuler | Incremental learning with accuracy prediction of social and individual properties from mobile-phone data[END_REF] and it just misses its counterpart which will make our future networks match our social systems and lifestyles. In the field of wired networking, some measurement and observation methods have emerged and are used by network operators [START_REF] Larrieu | Metrology of internet networks[END_REF]. The analysis task is even more and more efficiently automated to anticipate anomalies, attacks, events and their trends [START_REF] Mazel | Sub-space clustering, inter-clustering results association & anomaly correlation for unsupervised network anomaly detection[END_REF]. On the other hand for the upcoming IoT and its wireless communications, we still need knowledges and tools [START_REF]The internet of things: A survey[END_REF], [START_REF] Dujovne | A taxonomy of ieee 802.11 wireless parameters and open source measurement tools[END_REF].

C. The Cognitive Radio Paradigm

When Mitola introduced this paradigm ten years ago, he demonstrated by simulation the functioning of a cognitive software defined radio (SDR) [START_REF] Mitola | Cognitive Radio -An Integrated Agent Architecture for Software Defined Radio[END_REF]. In SDR, radio signals are processed by software running on CPU or reconfigurable devices. This approach has revolutionized radio-communications since the whole communication stack could be adaptive and not frozen by the hardware. Mitola also designed the Radio Knowledge Representation Language which formalizes the communication context. Based on this formalization he set up a cognition cycle to be implemented by nodes to improve their services. This concept opened an appealing field of research which is not yet realizable for average standards. Actually, the Achilles' heel is that the hardware chain limits software to low data rate protocols on reduced bandwidth. State of the art SDR are still experimental or integrate intermediate solutions with configurable devices [START_REF] Nafkha | Software defined radio platform for cognitive radio: Design and hierarchical management, recent advances[END_REF]. Today, this lack of platform insinuate that cognitive radio is an old vision of the network technology's distant future that needs to be up to date.

III. UBIQUITOUS COGNITIVE SYSTEMS MANAGEMENT.

A. Making The Environment Chatty.

The UCSM oddness is to integrate contextual knowledges from "average" things in the unsupervised management of our futures systems. The Internet of average things is often left aside because the added value for an average thing (furniture, mug, magazine) to be "connected" is not obvious. This common misconception is due to the literature which forces us to think that a thing would communicate only to improve its own services and functionalities. On the contrary, it can make sense if a thing also exchanges information to assist its neighbors. Thus, we can set forth the notion of chatty thing. When a thing is given a piece of information or context, it can adapt its behavior but it will mostly store then share appropriately this asset. Exchanging and inferring on the context gives to things the possibility (1) to best serve humans and (2) to improve their communication (including the context sharing itself) accordingly to their situation. This last point is our matter of concern. Context formalization should be evolutive and generic enough to take into account any kind of information from users (preferences, daily routines, interactions), to objects (resources and capabilities) to environment (time, place, communication protocols, waves propagation, regulation and standard).

As far as we know, nothing has been done to take into account the limitations of average things while exploiting the amount of information they could provide to network management. Given that an active protocol will suffer from battery problem for decades, we suggest to adopt a passive technology as the minimum universal way required to share contextual information. Our paradigm merge every objects in the IoT, from average things to complex nodes (sensors, electronic devices or personal computer). Like illustrated in the Figure 1 it provides them a framework to manage contextual information, "Average" things relay this information and make the environment chatty. This walk should both improve the functionality of products and their communication. Because improving the functionality of systems relatively to their context remains to their designers, our concern is to improve the communication in the upcoming IoT and adopt a cognitive Fig. 1: Here are two outlooks of the IoT. On the top, the classic one dissociates WSAN and passive RFID. Average things are left aside and no effort is made to manage systems relatively to their context. At the bottom, our vision involves average things that use an universal framework to manage contextual information making the environment obliging. radio approach. The value-added of ubiquity is that the cognitive work done by nodes is accumulated and kept by average things. Like Mark Weiser said in [START_REF] Weiser | The computer for the twenty-first century[END_REF], information is everywhere. People does not always cogitate to get an information, they sometimes just read and communicate. Before dealing with intelligent things, let's make them chatty. Maybe some of the equipments, the most complex (gateway, computer and next smart-phones) will integrate cognitive engine with SDR one day, but not all of them, and at first they will be only configurable. For instance, many cognitive radio research work try to compute whole frequency spectrum, whereas it could be pertinent to ask the nearest object. This approach is used for Wifi and Bluetooth pairing using NFC. Thus, this kind of architecture should considerably improve Mitola cognition cycle since it allows evolved equipments to let some footprints of their work and help the less capable ones optimizing their communication.

B. Taking Benefit From The Environment.

When we are strolling in the street we are informed just by looking at traffic signs, promotional material, reminder etc, so our smart-phone can do the same by reading passive RFID tag and start to put Weiser's word into action. Because the objects that surround us are most of the time the reflects of our lifes, observing them should give us interesting benefits. The outcomes of UCSM are double. First it provides the necessary architecture to monitor and manage our future networks and second it offers our everyday life object the contextual information they need to behave as we want. The next three points give an insight into UCSM possible outcomes. communication protocol stacks, local channel propagation, design for programmable hardware).

• Traffic prediction and resource provisioning: People generate different types of network traffic depending on their context and personality. Observing the context mutation for each user will allow operators and gateway to anticipate and predict the upcoming traffic but also forecast social trends.

• Improve and multiply software assistants: Cookies, preferences, history and localization had made their proof to improve information retrieval and intelligent software assistant like Siri and are usable by general electronic equipments. By simply scanning the surrounding objects a new dimension of context is given, furthermore this dimension would drastically augment the reality mining concept.

C. Setting Up a Management Cycle.

The presented concept refers to a complex management system. It can be split in several problematics which are of increasing difficulty : (a) Management primitives in the IoT : Assuming that a universal chatty framework is set up to monitor, manage and improve our communication network, the minimal requirement for this framework is to be at least configurable. Thus, this first problematic deals with the integration of atomic management commands in the existing standards for passive communications to reconfigure chatty things. (b) Context formalization and its storage : This second part deals with the possibilities to structure knowledge on the communication context in such a way that it could be safely spread and shared among chatty objects. The mains concern are to make the link between passive node capabilities (in terms of storage, and communication), context representation, users privacy and existing data standard for the IoT. (c) Contextual machine learning system : This third part studies the communication improvements that could emerge from the processing of such contextual information. A knowledge discovery process will enrich the structure specified in (b) with inferences emphasizing the relationship between the contextual situation, network behavior and their impacts on the network performances. These relationship will then train a machine learning aiming to choose the network behavior that best matches the contextual situation with regard to the expected network performances. This predictive management approach would be applicable to any context sensitive system. As a result, our first step has been to work on the integration of atomic management commands in current RFID standards, enabling the reconfiguration of the tiniest IoT nodes.

IV. INTEGRATE MANAGEMENT PRIMITIVES IN THE IOT.

A. RFID Standardization.

Classical RFID systems are basically composed of three segments which are tags (chatty things), readers (upcoming smart-phones) and a back-end information system to process the retrieved data (smart network equipments). Normative organizations like EPCGlobal, ISO/IEC and NFC Forum have fulfilled RFID systems with standards from radio signals to services discovery. The EPCGlobal structures them in Data standards and Interfaces standards, but we can also divide them into "ontological" standards and "technical" ones. The first will be considered later, to introduce the contextual formalization of UCSM in the IoT. The latter refer to the way manufacturers design their chips, and will induce the reconfiguration possibilities of chatty things. If standardization organisms tend to adopt a unique technology, industrials choice will mostly determine the de-facto standard, specifically in the case of the air Interface, where the ISO/IEC 15693 is a worldwide alternative for the 13,56Mhz ISM band and serves as a basis for other standards. We have then considered this standard to integrate management primitives in RFID.

B. Adaptation of an Air Interface Standard.

The ISO/IEC 15693 standard scope covers the nature of the electromagnetic field for power and communications, the physical characteristic of tags, and the medium access protocol (commands, anticollision methods). The communication is half-duplex and based on the exchange of a request from the reader and response(s) from tag(s). Each request or response are framed. A request consists of flags, commands, application data fields and CRC. Flags field determines the communication parameters of the responses (e.g. single/dual subcarrier, data rate), while the command fields details the action to perform (e.g. read, write, stay quiet). A response consists of flags, parameters depending on the command, application data and CRC. A simplified common procedure follows the next scheme:

1) The reader starts an inventory round.

2) Tags send-back their id following an anticollision procedure.

3) The reader has inventoried all reachable tags 4) The reader can send a request to a particular tag The two mandatory commands are inventory and stay quiet, other command (read, write, lock ...) are optional or proprietary. This protocol encourages manufacturer to part their tag design in three blocks which are respectively responsible for the analog interface and power management, the digital controller, and the user memory blocks (see fig 2). Thus, without manufacturer innovation, the tag communication is monolithic and gain few flexibility from the request's flags field few command like the mandatory quiet command or the optional command Write AFI (Application Family Identifier).

C. The RFID Atomic Management Commands.

To offer a minimal management of the IoT tiniest node, we suggest to make them not smart, but obedient and configurable. We argue that the first step toward ambient intelligence is ambient obedience. Thereby, a solution to manage tag communication is to introduce horizontal cross-layering. This means to remotely configure communication layer from the reader because it has a better visibility of its neighborhood, and also the ability to compute and make pertinent decision. We have to admit that this strategy is near to be employed thanks to the flag field and the command cited above. This initiative needs improvement that goes through the use of optional commands, additional commands and specific tag design. We aim to offers readers the possibility to have management primitives or atomic management command to set and get (1) tag communication control registers, (2) tag communication status registers or (3) tag programmable logic design. Table I summarizes the required modification of [START_REF](all parts), Identification cards Contactless integrated circuit(s) cards Vicinity cards[END_REF] to enable our management primitive, while the figure 2 highlight the differences between a common design and a manageable design. Coupling this set of management primitives with a configurable design make the use of other optional commands such as Lock, Write AFI or Get System information obsolete since they can be modeled by read or write access to tag state. As illustrated in the figure 2, a configurable design let the reader access its state (assuming that locks are properly configured) because its state is included in the memory plan. The term state covers both functional registers of the tag (determining its behavior like a flag does) and configurable logic units which can be compared to configurable logic blocks in programmable devices (e.g. Field Programmable Gate/Analog Array). For instance in the case of RFID, these primitive could allow readers to organize a deterministic TDMA between tags only by handling the register they use to determine their time slot. The use of these simple management primitives simplify the high level protocol implementation since its reduces the number of commands, in return the circuitry complexity increases because it involves programmable logic and nonvolatile memory to configure the device. Nevertheless, we believe that our approach offers a feasible trade-off between read only tag and software defined radio.

V. CONCLUSION AND FUTURES WORKS

In order to enable and control a rapid growth of the IoT, we introduced the UCSM transversal use case which takes part from three promising domains of research. This paradigm makes the environment chatty, leveraging contextual information to manage the IoT. After having exposed the main problematics of our concept, we have introduced the starting point of our ongoing research which is to adapt existing air Fig. 2: Here are two simplified diagram block. On the left is a common RFID tag design. Its communication is driver by the flags field of the request and by others few specific command. On the right, the behavior of a chatty object is configurable from the reader by accessing internal register or configuring programmable units. interface protocol standards for HF RFID. The following step will be to handle the context formalization, by updating RKRL of [START_REF] Mitola | Cognitive Radio -An Integrated Agent Architecture for Software Defined Radio[END_REF] and offer to average things a tailored version. Finally one of the trickiest difficulty will come from the last problematic. It can be referred as a "bootstrapping" problem in which we have to consider network behaviors that do not exist yet and the associated issues. We intend to solve this starting by emulating the known behaviors in the IoT (ie: existing network behaviors and new behaviors to be introduced by our management framework).

TABLE I :

 I Management Primitives RFID Commmands

• Behavioral guidelines: Give advices and tips to devices on their system or network configuration (ie: silent mode,