Laurent Pizzagalli

First principles molecular dynamics calculations of the mechanical properties of endofullerenes containing noble gas atoms or small molecules †

Introduction

Endohedral fullerenes or endofullerenes are closed shell fullerenes encapsulating atoms, molecules or clusters. They can be synthesized using several techniques, among which high pressure incorporation or molecular beam implantation. [1][START_REF] Dunk | Proc. Nat. Acad. Sci[END_REF][START_REF] Shinohara | Endohedral Metallofullerenes: Fullerenes with Metal Inside[END_REF] For instance, the former approach allowed to achieve the incorporation of noble gas atoms. [START_REF] Saunders | [END_REF][5][6][7] More recently, Kurotobi and Murata developed a molecular surgery technique to open a C 60 , insert a water molecule, and close up the carbon shell. 8 Bloodworth et al. used a related approach to trap a noble gas atom or a methane molecule into C 60 . 9,10 Studying endofullerenes is interesting and important in several ways. A first incentive would be the controlled modification of properties caused by the presence of the guest molecule or cluster. For example let us consider mechanical properties, which are nowadays satisfactorily understood for the empty C 60 , thanks to several dedicated studies. [11][12][13][14][15][16] We know that C 60 is a resilient molecule, 17 which can sustain a huge elastic deformation up to about 48%. 16 For larger compression strains, the yielding of the C 60 shell by bond breaking is observed, but a perfect or weakly defected structure can be recovered by unloading if the strain does a Institut P , CNRS UPR 3346, Université de Poitiers, SP2MI, Boulevard Marie et Pierre Curie, TSA 41123, 86073 Poitiers Cedex 9, France. E-mail: Laurent.Pizzagalli@univpoitiers.fr † Electronic Supplementary Information (ESI) available:

[details of any supplementary information available should be included here].

See DOI: 10.1039/cXCP00000x/ not exceed 75%. It is rational to assume that introducing one or several atoms inside the C 60 shell could change this picture, especially at large deformations. For instance, an endofullerene could probably be stiffer than the empty fullerene. Also, both the yield stress and the plasticity mechanisms could be affected.

A promising feature of endofullerenes is that they provide a unique mean to encapsulate and isolate a single atom or molecule, opening the way to potential applications in memory storage or quantum computations, 18 or to investigate the intrinsic properties of the trapped guest. The properties and characteristics of the latter could also be modified by applying an external perturbation on the endofullerene. For instance, on the basis of first-principles calculations, Sabirov and co-workers predicted that the dissociation of a trapped H 2 O or CH 4 molecule could be achieved by the compression of the C 60 host. 19,20 Futhermore squeezing the C 60 shell leads to a reduction of its internal volume, which could potentially put a single atom in a high pressure state.

The last decades have witnessed an impressive development of experimental apparatus allowing to probe mechanical properties of matter at the nanoscale. 21,22 For instance the controlled compression of single nanoparticles with a size equal to a few tens of nm has been achieved. [23][24][25][26][27] However, systems as small as fullerenes or endofullerenes remain out of reach of the current capabilities. Note that scanning probe techniques have been successfully used to probe the mechanical properties of C 60 , but that these investigations are restricted to a low deformation regime. 28,29 Numerical simulations are often a useful complement or substitute to experiments, and a large number of classical molecular dynamics calculations have been devoted to determine the mechanical properties of nanoparticles (for a recent review see Ref. 30 ). Critical issues are however the lack of available classical interatomic potentials for multicomponents systems or their questionable reliability at the nanoscale and for large deformations. To overcome this hurdle, we have recently developed a numerical approach allowing for the compression of nano-objects at finite temperature by combining first principles MD calculations with classical force fields. In the present study, this approach is applied to investigate the properties of X@C 60 endofullerenes under compression. Several X guests are considered: single noble gas atoms from He to Xe, clusters of He atoms, and methane and water molecules.

This paper is structured as follows. In the section 2 the setup of the simulations is described with all details provided. The section 3 is dedicated to the structure and stability of the endofullerenes at room temperature. Their mechanical properties are described in the section 4. Finally the section 5 is dedicated to the state of the atoms and molecules encapsulated into the compressed C 60 shell. Our conclusions are gathered in the final section.

Methods

First principles molecular dynamics calculations

First principles MD calculations are performed using the Car-Parrinello method 31 implemented in the Quantum Espresso package. 32 We use a timestep of 0.2 fs, an effective electron mass of 600 a.u., and an electron mass cutoff of 5 Ry. 33 Ions and electrons are thermalized, using Nose-Hoover thermostats with oscillation frequencies of 90 THz for electrons and 30 THz for ions. The thermostat targets are an electronic kinetic energy of 0.005 a.u. for electrons and a temperature of 300 K for ions, respectively. These parameters were shown to be appropriate for C 60 compression in a previous work. 15 The electronic structure is calculated using density functional theory. 34,35 A good convergence is obtained with a plane waves basis cutoff of 25 Ry, except for systems including an oxygen ion for which a larger cutoff of 40 Ry is employed. The Perdew-Burke-Ernzerhof (PBE) functional is used to compute exchangecorrelation contributions. 36 Interactions between ions and electrons are described with ultrasoft pseudopotentials. 37 All calculations are carried out using a cubic supercell with a length of 20 Å, which is large enough to prevent spurious interactions between the endofullerene and its periodic images. 15 With these parameters, carbon bond lengths of 1.401 Å and 1.451 Å are obtained when the C 60 structure is relaxed with a conjugate gradient energy minimization, in excellent agreement with the literature. 38

Uniaxial compression

Two different sets of MD calculations are carried out. In the first one, each X@C 60 system is let free to evolve at 300 K for 20 ps. The first 10 ps are long enough to achieve thermalization. Different properties can then be extracted by averaging over the last 10 ps. These simulations are useful to determine the structure and the stability at 300 K, described in section 3.

In the second set, the uniaxial compression of each endofullerene is achieved by following the methodology described in details in Ref. 15 , and only briefly reported here. Each system is orientated so that the z-axis, the compression axis by convention, passes through opposite pentagons in the C 60 shell. In the MD simulations a repulsive quadratic force field acting on ions is activated. Atoms with z-coordinates above an upper threshold value are pushed down by the force field. Similarly, atoms with zcoordinates below a lower threshold value are pushed up. The upper (lower) threshold value is decreased (increased) at each time step, thus allowing for a continuous and smooth compression of the endofullerene. The chosen increment is 1 × 10 -5 Å, yielding a compression speed of 0.1 Å/ps, which is typical of nanoparticles compression simulations. 14,30,39 The strength of the force field is set to 30 a.u., thus modeling an extremely stiff flat-punch indenter.

Both the total energy and the contact force are recorded at each MD step. The contact force is equal to half the sum of all repulsion contributions from the force field. Note that each pushed ion also experiences a friction force perpendicular to the compression axis and proportional to its mass, its velocity, and a parameter Γ equal to 500 a.u. This additional constraint hinders the free rotation of the quasi-spherical C 60 shell during the compression. 15 The engineering strain ε = δ d/d 0 is used in this work, the reference length d 0 being determined for each system during the first set of MD calculations. Because of the small dimensions involved, the strain accuracy is estimated to be at best 1%. A typical MD compression run involves 2.2 × 10 5 iterations i.e., 44 ps. This is long enough to achieve compression strains up to 60%.

Bader volume and charge analysis

We also determine the Bader volume and charge of all atoms during the compression by performing an Atom in Molecule (AIM) analysis [START_REF] Bader | Atoms in Molecules: A Quantum Theory[END_REF] using the CRITIC2 tool. [START_REF] De-La Roza | [END_REF] More precisely, the atomic structure is first extracted from the compression run for a selected configuration at a given time step. A separate self-consistent field calculation is next carried out using Quantum Espresso and the same parameters than in MD calculations. The only difference is that the ion-electron interactions are now calculated in the framework of the PAW method. 42 This allows for recovering the all-electrons density close to the nuclei, which is required for an accurate determination of the atomic basins in the AIM approach. Once this last step is achieved, per-atom quantities like the Bader volume V B and the charge are computed by integration of the pseudo-density using the Yu-Trinkle algorithm, 43 and summed for each X guest. The charge is expressed as the excess number of electrons relative to the ground state. For instance, a value of +0.19 e -for He 10 @C 60 means an excess of 0.19 electrons carried by He 10 (and then a deficit of 0.19 electrons for C 60 ). It is important to specify that the atomic volume cannot be unambiguously defined, and that AIM is only one method among others to perform a spatial decomposition. Variations of AIM-derived quantities like the atomic volume or the excess charge are useful indicators to monitor the systems during compression, but one should not put too much weight on their absolute values. We first describe and discuss the structure and energetic stability at 300 K and with no compression, for all investigated systems. In the case of a single noble gas atom, it is generally agreed in the literature [51][52][53] that (i) the deformation of the C 60 shell is negligible, (ii) the binding energy between X and C 60 is small, equal to a few hundredths of eV at most in absolute value, (iii) its sign seems to be highly dependent on the calculation method, and (iv) the most stable structure retains the I h symmetry with a centered noble gas atom. Our results are overall in accordance with these conclusions, with C 60 shell dimensions changes ∆d H and ∆d P smaller than 0.01 Å and low binding energies (Tab. 1), and a noble gas at the C 60 center. We find a negative binding energy i.e., an attractive interaction, only in the case of Xe@C 60 . We emphasize that we do not aim at the same precision than in the previously published works, based on 0 K hybrid functional calculations with corrections for zero point energy and dispersion forces. [51][52][53] In the present study our accuracy is essentially limited by the finite temperature averaging and the use of the approximate PBE exchange-correlation functional. Note that we performed additional calculations including semi-empirical dispersion contributions, 54 which show that these corrections are negligible. Furthermore, as will be detailed in the following, the strain energies associated with mechanical compression are typically 2-3 orders of magnitude larger than the binding energies. Table 1 also reports the charge transfer ∆Q between X and C 60 as estimated with the AIM approach. This charge transfer is found to be zero (He and Ne) or equivalent to a small electron deficit (Ar and Xe). The Kr case is puzzling with a transfer from X to C 60 of 0.39 e -, one order of magnitude larger than for other noble gas.

Structure and stability

Considering CH 4 , we find that the initial T d symmetry of the molecule is preserved during 20 ps at 300 K, with the carbon atom located at the C 60 center (Fig. 1-a). The C 60 deformation is negligible, which may mean that the molecule is relatively free to rotate. However, rotation is barely observed during the 20 ps run, hinting at some directional interaction between C 60 and CH 4 . Our calculated binding energy is -0.789 eV (Tab. 1), i.e. the interaction is attractive. This appears to be slightly lower than the 0 K values reported in the literature. 55,56 There is no charge transfer between CH 4 and C 60 . The C-H bond length in CH 4 is 1.098 Å in average at 300 K, in excellent agreement with previous works. 55 It is slightly lower than the computed bond length of 1.113 Å for the free CH 4 molecule, in agreement with a weak interaction with the C 60 host.

Our calculations also show that the interaction between H 2 O and C 60 is minimal, with almost no perturbation of the C 60 geometry (Tab. 1). The computed binding energy is close to zero, in agreement with results from Galano et al. 56 However, earlier investigations reported values ranging from -0.50 to -0.02 eV. 57,58 The encapsulated H 2 O molecule retains the C 2v symmetry (Fig. 1b), with a H-O bond length decrease of 0.004 Å and a HOH angle increase of 0.22 • compared to the free molecule at 300 K. Similar negligible changes are reported in the literature. 57,58 We also find that the O atom of the H 2 O molecule remains close to the C 60 center during the 300 K run, and that the molecule rotates easily as expected. 29,59 ∆Q is only -0.02 e -in agreement with previous calculations based on AIM. 58 Finally, we tested two helium clusters endofullerenes, He 6 @C 60 and He 10 @C 60 . Such systems are unlikely to exist in nature or to be synthesized, but can be used to investigate the influence on mechanical properties of the internal pressure built by helium atoms. Starting from a random configuration for He atoms, it is observed that He 6 quickly evolves towards a highly symmetric (O h ) structure (Fig. 1-c) during the calculation. For He 10 , a low symmetry compact configuration is obtained (Fig. 1-d).

Compared to a single NG atom, the binding energies are large and positive (Tab. 1), confirming that these compounds have little chances to be synthesized. Despite this large repulsion, it is remarkable that the C 60 shell expansion remains limited, with dimensions increase of 0.017-0.019 and 0.07-0.08 Å respectively. This confirms that C 60 is characterized by an outstanding structural resistance to high internal pressures. 7 Finally, we also determine excess charges of 0.13 and 0.19 e -for He 6 and He 10 , respectively.

The values of the Bader volume V B at zero strain, calculated with the AIM method, are reported in Tab. 1. The comparison with the solid phase EOS volume V 0 indicates that the available volume for accommodating a molecule or atoms in the uncompressed C 60 is about 20-22 Å 3 . In fact, V B is significantly reduced only for X with larger V 0 . Therefore, only He and H 2 O, and to a lesser extent Ne, can be considered to remain unconstrained when encapsulated into C 60 . Our estimated "free" volume value is in agreement with an earlier study. 18 It also suggests that a physically good approximation of the C 60 shell width is 3.4 Å. 60 Table 1 Vinet EOS parameters for the atom or molecule X, and data for the endofullerene X@C 60 computed at 300 K. V 0 , B 0 and B 0 are the volume, bulk modulus, and bulk modulus derivative published values for X in solid phase: He, 44 Ne, 45 Ar, 46 Kr, 47 Xe, 48 H 2 O, 49 CH 4 . 50 V 0 for He 6 and He 10 are the He value multiplied by the number of helium atoms. ∆d H and ∆d P are the length changes associated with the presence of X in C 60 relatively to the empty fullerene, averaged at 300 K, with d H (d P ) the separation between two facing hexagons (pentagons). V B and ∆Q are the volume and excess charge of guest X at zero strain calculated using the Bader AIM analysis. ∆E is the binding energy of X in X@C 60 , averaged at 300 K The energy reference is taken as the one of the uncompressed system at 300 K. The green strip lines show the strain range for which the rst CC bonds break for a bare C 60 . 16 The top inset graph is a zoomed display of energy variations in the 00.2 strain range. Energy and force curves represented in separated graphs can be found in Supplementary Material.

X Vinet EOS X@C 60 data X V 0 (Å 3 ) B 0 (GPa) B 0 ∆d H (Å) ∆d P (Å) V B (Å 3 ) ∆Q (e -) ∆E (
In this section we focus on the mechanical properties of X@C 60 compared to the known behavior for the "empty" C 60 . 16 Figure 2 shows the total energy and contact force variations during the uniaxial compression of each studied systems. Most curves share similar characteristics. At low strains, the energy increases quadratically and the force linearly, as expected for an elastic regime. The slope of the force curve then decreases as compression proceeds, indicative of non-linear elasticity, up to strains equal to 0.27-0.30. This stage corresponds to the flattening of the two C 60 azimuth caps in contact with the two repulsion force fields, in accordance with the predicted behavior for the bare C 60 . 16 The various curves also tend to separate in this strain range, because of the growing specific influence of each guest X as compression proceeds. It is particularly significant for He 10 @C 60 , for which the contact force first grows steeper than for the others, for strains in the 0.20-0.26 range, then slower. This behavior is actually caused by a modification of the helium atoms packing (Fig. 3-(b-d)), as will be discussed in the following.

At strains equal to 0.3 the two caps are flattened, and force and energy variations become more steep for greater strain values. One or several maxima can be observed on both sets of curves, with clearly more features on force curves. All these maxima mark the activation of various mechanisms decreasing stress, contact force, and energy. A thorough structural analysis during compression reveals that these mechanisms correspond to changes either in the C 60 shell or of the endohedral guest. For instance, the force maximum occurring at 0.40-0.41 strain followed by a small decrease for Xe@C 60 (Fig. 2) is due to a reorientation of C 60 relatively to the compression axis. The compression axis changes from pentagon center (Fig. 3-g) to bond center (Fig. 3-g). A different example is the force maximum at a strain of about 0.42 for CH 4 @C 60 , followed by a sharp drop (Fig. 2), which is caused by the dissociation of the CH 4 molecule.

We find that all force maxima occurring for strains in the range 0.48-0.58 are associated with the breaking of one or two carbon bonds in the equatorial part of the C 60 shell, as for the bare fullerene. 16 For Kr@C 60 , Ar@C 60 , Ne@C 60 , He 6 @C 60 and He 10 @C 60 , this is followed by the escape of one or several atoms through shell openings at slightly larger strains, leading to large force and energy drops (See Fig. 3-f,l for two examples). For the other systems, the molecule or the atom remains trapped in the defected shell. Note that in most cases, the compression simulation was stopped after the C 60 shell opening. Only in the case of He@C 60 the compression was continued up to a strain of 0.80 for which the complete C 60 shell failure was observed. This strain threshold value is close to the one determined for the bare C 60 , 16

Fig. 3 Structures extracted from molecular dynamics calculations, at dierent compression strains, for He 10 @C 60 (a-f), Xe@C 60 (g-h), and He 6 @C 60 (i-l). For He 10 @C 60 and He 6 @C 60 , the angle of view is perpendicular to the compression axis (side view), while for Xe@C 60 it is parallel (top view). For e) and k), an additional top right thumbnail picture shows a top view of the structure. Ball-and-stick representations are used for guests, while only the carbon bonds of the C 60 host are shown for clarity.

although the helium atom remains always trapped.

Table 2 Data extracted from the compression of the endofullerene X@C 60 at 300 K: Stiness S (N/m), yield strain ε y determined from forces variations, force F y (nN) and energy E y (eV) at yield strain. Data for the empty C 60 , computed with the same approach 16 , are reported in the rst line for comparison To quantify the influence of X on the mechanical properties of X@C 60 , we compute the stiffness S by fitting the energy curves with a quadratic function over a 0-0.1 strain range. We also determine the strain ε y at which the C 60 shell yields, i.e. the first carbon bond breaking, and the corresponding maximum force and energy values F y and E y . Data are reported in Table 2 and graphically in Fig. 4. In the latter, data are plotted as a function of V 0 , the Vinet EOS volume of X (given in Tab. 1), assuming the latter quantity is a fair estimate of its initial volume. This is an arbitrary but convenient choice for the data visualization.

Figure 4 suggests that the stiffness is roughly proportional to V 0 . However the increases relatively to the bare C 60 remain small. The largest value, obtained for Xe, is for instance only 12% higher than the reference (green strips in Fig. 4). Note that the magnitude of the effect is comparable to stiffness variations associated with the orientation compression of a bare C 60 . At the other end of the scale X with low V 0 such as He or H 2 O have no noticeable influence on the stiffness. Eventually the only outlier is He 10 for which S is the same than for the bare C 60 despite a large V 0 . This result might be explained by the initial dilation of He 10 @C 60 before compression (quantified by ∆d H and ∆d P in Tab. 1). For Fig. 4 Stiness S (N/m), Bader volume V B (Å 3 ), energy E y (eV) and force F y (nN) at yield, as a function of the Vinet volume V 0 (Å 3 ) for each X@C 60 system. The green strips show the range of values computed for a bare C 60 , for the same orientation. 16 small deformations, the compression reduces the initial C 60 shell expansion, thus lowering the contact force increase rate and then the stiffness. This effect is partially compensated by the influence of He 10 . Overall our observations suggest that the elastic behavior of the endofullerene is only weakly sensitive to the presence of the X guest, and depends essentially on the C 60 shell. This is not surprising if one compares for instance the large differences in elastic moduli between fullerenes 61 and noble gas. 62 We now analyze data related to the yield point, i.e. the yield strain ε y , the energy E y and force F y . ε y is not represented in Fig. 4 since this quantity is obviously not correlated to V 0 (Tab. 2). Note that there is an estimated 1-2% uncertainty in the determination of ε y , because of the sluggish breaking of the first carbon bond and the potential error in the 0% definition. Nevertheless variations remain small and in the stochastic range of values computed for the bare C 60 . 16 Also, we find that the plasticity mechanisms are the same in all cases. This means that the presence of X and its nature have little influence on the strain at which plasticity in the C 60 shell is initiated, at least for the various tested systems.

On the contrary one can see that X greatly influences both energy and contact force at the yield point, and that the variations are roughly proportional to V 0 (Fig. 4). The energy increase compared to the bare C 60 is equal to a few eV for He and H 2 O, and can be as large as 16-20 eV for He 10 . For the contact force, we determine increments of at least 4-6 nN for He, and up to 37-39 nN for He 10 i.e., more than twice the bare C 60 value. Both energy and contact force are then highly dependent on X. This is probably because the onset of plasticity occurs at high strain values where both the C 60 shell and X are compressed. The contributions of X to the energy and contact force then become significant in this strain regime. They also appear to be roughly proportional to the initial volume V 0 , although the compressibility of X might be influential as well.

5 Properties of X in compressed X@C 60

Volume, pressure, and charge transfer

Now we analyze how the properties of the atoms or of the molecule encapsulated in C 60 are modified by the compression. Figure 5 shows the variations of the volume V B for each X content, calculated with the AIM method. All curves are characterized by similar features. V B decreases slowly at low strains and with an increasing rate as compression proceeds. This behavior is in agreement with our previous statement that at low strains, the mechanical properties of X@C 60 are weakly influenced by the presence of X. The sole exception is He 10 , for which V B tends to decrease almost linearly from the start of the compression. In all cases the steep volume increase for strains greater than 0.5 is due to X or a part of X escaping through the broken C 60 shell. Examples of such processes are represented in Fig. 3-f,l.

Using the EOS for the various X systems, one can estimate the pressure variation associated with the volume decrease. Obviously, the notion of pressure in the case of a single atom or molecule is conceptual and has to be considered with caution. Furthermore, the stress inside a uniaxially compressed C 60 is likely to be not hydrostatic. We argue that this pressure estimation is nonetheless useful to get insights on the state of the C 60 guest during the compression. Computed pressure variations during compression are shown in Fig. 5. For most X@C 60 systems, the pressure first increases slowly, then faster after a given compression level. The inflection occurs at a strain value of about 0.4 for the biggest X (Kr, Xe) up to about 0.45 for the smallest ones (He, Ne, H 2 O). It corresponds to X being effectively compressed between the two flattened C 60 caps. The situation is different for He 6 , He 10 and to a lesser extent CH 4 , for which no clear inflection is obtained. This is because the structure of the clusters and of the molecule continuously changes during compression in Fig. 5 Bader volume V B (top graph, in Å 3 ), atomic pressure (middle graph, in GPa), and charge transfer ∆Q (bottom graph, in e -) of X as a function of strain during the compression of X@C 60 . V B and ∆Q are computed using the AIM approach. A positive ∆Q value corresponds to an electron transfer from C 60 to X. The pressure is derived from the computed volume using the appropriate EOS at 300 K for each X.

order to better accommodate the stress. For instance, the initial three-dimensional packing of He 10 is progressively transformed to a two-dimensional helium layer (Fig. 3-(a-e)). Similarly He 6 departs from its initial structure (Fig. 1-c) to a seemingly HCP packing at very low strain (Fig. 3-j), which is next gradually converted to a single helium layer (Fig. 3-(k)).

Maximal pressure values of 91 GPa (He 6 ), 130 GPa (He 10 ), 210 GPa (Ne), 189 GPa (Ar), 353 GPa (Kr) are determined (Fig. 5). For H 2 O and CH 4 , the maximum values for an undissociated molecule are 151 GPa and 44 GPa, respectively. Finally, we also found extremely high pressures of 985 GPa for Xe and 731 GPa for He, the later corresponding to a strain of 0.75. Although these values must be considered with caution, this suggests that single atoms or small molecules in a very high stress state could be achieved, provided of course that the controlled compression at high strain of C 60 and endofullerenes would be Fig. 6 Structures extracted from molecular dynamics calculations, at dierent strains, for H 2 O@C 60 compressed along pentagon-pentagon (a-f) and hexagon-hexagon (h-k) orientations, and for CH 4 @C 60 (l-o). The angle of view is perpendicular to the compression axis (side view). For selected strains, an additional top right thumbnail picture shows a top view of the structure. Ball-and-stick representations are used for guests, while only the carbon bonds of the C 60 host are shown for clarity. made possible in the future.

The charge variations ∆Q for each X, determined using AIM during the compression of X@C 60 , are shown in Figure 5. For strains below 0.48 i.e., before yielding of the C 60 shell, values tend to remain small and weakly dependent on strain for the smallest noble gas atoms like He, Ne and Ar. Larger charge transfers are observed for He 6 and He 10 , but they remain low with a maximum of 0.2 e -in excess in helium clusters. A surprisingly high electron deficit is determined for Kr, but it is difficult to determine a rationale for variations as a function of strain. By comparison, Xe is characterized by a low electron deficit of 0.09 at zero strain, this value increasing with the compression strain. We determine a maximum electron deficit of 2.2 e -from Xe to C 60 at ε = 0.63. For H 2 O and CH 4 molecules, the small initial electron transfer to the C 60 shell increases as compression proceeds. Hence ∆Q for H 2 O decreases to a minimum of -0.25 e -at ε = 0.51. Figure 5 shows that for higher strains ∆Q increases sharply to positive values. However it now corresponds to a dissociated molecule as will be described in the following section. In the case of CH 4 , the electron deficit in the molecule grows with the compression strain, with a value of -0.1 e -at ε = 0.41. Contrary to H 2 O, δ Q continues to decrease for larger strain values and after molecular transformation, down to a minimum value of -0.6.

Compression-assisted chemical transformations

It has been proposed that the compression of H 2 O@C 60 or CH 4 @C 60 could lead to the formation of endohedral covalent derivatives. 19,20 In this section, we examine the evolution of H 6-b). The AIM analysis shows that the two H atoms have each a deficit of 0.6 e -, and the C atom an excess of 1.0 e - in average. At ε = 0.57, one hydrogen atom separates from the oxygen and forms a C-H bond with a C 60 shell atom (Fig. 6-c). Its charge deficit is reduced to about 0.2 e -, and the O excess charge becomes 0.9 e -. It corresponds to an electron deficit of 0.1 e - in C 60 . For these compression strains, the separation between top and bottom flattened C 60 caps becomes small enough to consider that the remaining hydroxide ion interacts with the two closest top and bottom shell carbon atoms. Also, the lone hydrogen atom seems to form short lifetime bonds alternatively with a top and a bottom C atom. At ε = 0.60 -0.61, we observe the formation of an epoxide group (Fig. 6-d), followed by the separation of the second H atom from O and the formation of a C-H bond (Fig. 6-e). This H atom exhibits a charge deficit of 0. Sabirov and co-workers reported a similar dissociated H 2 O configuration at a strain of 0.58, with the formation of an epoxide group and two remote C-H bonds. 19 The excellent agreement with the present work is impressive given that our methodology for computing electronic structure and applying compression is different, and also that their simulations are done at 0 K. In the same study the authors also investigated the uniaxial compression of H 2 O@C 60 for an hexagon-hexagon orientation. They reported a full dissociation of H 2 O into an oxidoannulene structure and two single C-H bonds, at a strain of 0.57, with therefore an apparently different mechanism than for the pentagon-pentagon compression. 19 To compare with these findings, we also carried out 300 K MD simulations of the H 2 O@C 60 compression for this orientation. Our results are shown in Fig. 6-(g-k). Up to ε = 0.55, the H 2 O molecule is observed to remain in the center of C 60 , a difference with the previous case being that it is tilted relatively to the compression plane (Fig. 6-h). At this strain the O atom carries an excess charge of about 1.0 e -, and the H atoms a deficit of 0.2 e -, similar to what is obtained for the pentagon-pentagon orientation. Note that at this strain the C 60 shell is already opened with no incidence on the molecule state (Fig. 6-i). When ε = 0.56, one hydrogen atom loosens and moves to make a bond with the C 60 shell (Fig. 6-j). The remaining hydroxide ion also binds to C 60 , first with a single bond, then as an epoxide group after a few extra tenths of strain. Its charge is now approximately +0.4 e - (+1.0 e -for O and -0.6 e -for H), while the lone H atom carries a charge of -0.2 e -. When ε = 0.61 the H-O bond breaks, the hydrogen atom moving to make a bond with C 60 (Fig. 6-k). At this strain, we find a charge deficit of 0.2 e -for both hydrogen atoms, and a charge excess of 0.4 e -for the oxygen atom. Increasing the compression leads to the breaking of the bond between the two carbon atoms bonded to the oxygen atom, and then the failure of the C 60 shell. Finally the whole process is qualitatively and quantitatively similar to what we find for the pentagon-pentagon compression. This suggests that the seemingly different behaviors reported by Sabirov and co-workers 19 for the two compression orientations likely result from the use of large strain increments, preventing a detailed analysis of the structural transformations. It also confirms that it is possible to achieve a full dissociation of a single H 2 O molecule when encapsulated into a compressed fullerene.

Finally we also find that the compression of CH 4 @C 60 triggers a chemical transformation (see the Supplementary Material for a movie). Initially, the CH 4 molecule is only weakly perturbed, with C-H bond lengths of about 1.1 Å and HCH angles close to the expected value of 109.5 • (Fig. 6-l). The carbon atom carries approximately 0.4 e -in excess, whereas the hydrogen atoms are characterized by a charge deficit of 0.1 e -. As compression proceeds, the C-H bonds shorten to 1.07 Å and the HCH angles including the two top or the two bottom H atoms rise to a maximum of 133 • at ε = 0.41 (Fig. 6-m). In parallel there is a small 0.1 e -transfer from CH 4 to C 60 . At ε = 0.42, the topmost H atom separates from the molecule C atom to form a bond with C 60 , and the remaining methyl radical binds to the C 60 shell (Fig. 6n). Associated energy and force reductions of 1.7 eV and 9.3 nN are calculated (Fig. 2). This mechanism implies a 0.2 e -transfer from the molecule carbon atom to C 60 , but no appreciable charge changes for the hydrogen atoms. Increasing the strain weakly reduces the bond lengths for the lone hydrogen and the methyl group. The excess charge on C 60 and on the C atom increase to 0.55-0.6 e -, whereas for the H atoms the charge deficit rises to 0.3 e -. At ε = 0.51, the C 60 shell yields by the breaking of carbon bonds in the equatorial region (Fig. 6-o), with no clear direct relation with the presence of the methyl group and the single hydrogen atom. Finally, we note that the carbon atom in CH 3 binds to a second C 60 shell atom at approximately ε = 0.55, before we stop the compression. The process as a whole appears to be similar to an earlier prediction. 20 In this latter study, the strain at which the CH 4 →CH 3 +H transformation takes place is reported to be 0.40, therefore in excellent agreement with the present value of 0.42.

Conclusions

In this study the mechanical properties of various kinds of endofullerenes X@C 60 were investigated by performing first principles molecular dynamics simulations of uniaxial compression over a large strain range. We considered realistic and synthesizable X systems, including single noble gas atoms, H 2 O or CH 4 molecules, as well as artificial helium clusters. These calculations and the associated analyses lead to the following conclusions:

• In the absence of strain, it is confirmed that the interactions between X and C 60 are weak in most cases, with negligible modifications of structural properties and limited charge transfers. A light expansion of the C 60 shell was obtained only in the case of encapsulated helium clusters.

• In the elastic regime an increase of stiffness, proportional to the intrinsic volume of X, is predicted. However this increase is at most 12% of the C 60 stiffness.

• The presence or the nature of X has no noticeable influence on the yield strain and on the C 60 shell yielding mechanisms.

Still the variations of both the contact force and the energy clearly depend on X. For instance large increases of their values at yield are predicted.

• The estimation of the volume of X and of a derived pressure shows that single noble gas atoms and small molecules could be put in a very high stress state, with pressure values in the range 50-200 GPa, during the compression of endofullerenes.

• The simulations confirm that the uniaxial compression could trigger the dissociation of H 2 O or CH 4 when these molecules are encapsulated into C 60 .

To summarize, the uniaxial compression of X@C 60 is predicted to have a strong effect on the properties of X, but a rather limited one on the mechanical properties of C 60 . This is mainly a consequence of our choice of closed-shell atoms or molecules for X, for which electronic interactions with the C 60 shell are minimal. A natural an interesting continuation of this work would then be to consider endohedral metallofullerenes, where one or two metal atoms are enclosed in a fullerene. 1 The usually strong interaction of these atoms with the fullerene shell is likely to influence its mechanical strength and yield mechanisms, defining a research topic worth to be explored.

Conicts of interest

There are no conflicts to declare.

Fig. 1

 1 Fig. 1 Structures of a) CH 4 @C 60 , b) H 2 O@C 60 , c) He 6 @C 60 , and d) He 10 @C 60 . Ball-and-stick representations are used for guests, while only the carbon bonds of the C 60 host are shown for clarity.

Fig. 2

 2 Fig.2Total energy (top graph, in eV) and contact force (bottom graph, in nN) as a function of compression strain for all studied endofullerenes. The energy reference is taken as the one of the uncompressed system at 300 K. The green strip lines show the strain range for which the rst CC bonds break for a bare C 60 .16 The top inset graph is a zoomed display of energy variations in the 00.2 strain range. Energy and force curves represented in separated graphs can be found in Supplementary Material.

  2 O and CH 4 inside C 60 during the compression to determine whether such mechanisms occur in our calculations. Considering first H 2 O, we observe that at very low strains the molecule could rotate slowly almost freely in all directions while remaining in the C 60 center. Increasing the strain suppresses the rotation, with the molecule contained in the plane perpendicular to the compression axis (Fig. 6-a). The O-H bonds lengths and the HOH angle remain constant in average with respective values of 0.972 Å and 104.4 • until ε = 0.47. Next they increase up to maximum values of 1.078 Å and 110.0 • at ε = 0.56, while the oxygen atom gets closer to the nearest carbon atoms in the C 60 shell (Fig.

  2 e -, like for the first hydrogen atom. The epoxide group is characterized by C-O bond lengths of 1.3-1.4 Å and a C-C bond length of 1.55 Å. The charge is in excess of 1.05 e -on the O atom, and in deficit of about 0.35 e - on these two C atoms. Finally, as compression proceeds, this C-C bond progressively breaks which triggers the fracture of C 60 and the escape of the oxygen and of one hydrogen through the created hole (Fig. 6-f). A movie showing the H 2 O@C 60 compression is available in the Supplementary Material.

J o u r n a l N a me , [ y e a r ] , [ v o l . ] ,

Acknowledgements

The computer time for this work was provided by several sources: the Spin Center at the University of Poitiers, the MCIA (Mésocentre de Calcul Intensif Aquitain), and GENCI-CINES (Grant 2020-A0090912035).

Notes and references


Yulin Zhang

Christelle Urtado
email: christelle.urtado@ema.fr

Sylvain Vauttier
email: sylvain.vauttier@ema.fr

Connector-driven process for the gradual evolution of component-based software

Large, complex and long-lived software need to be upgraded at runtime. Addition, removal and replacement of a software component are the elementary evolution operations that have to be supported. Yet, dynamic changes are errorprone as it is difficult to guarantee that the new system will still work and that all functionalities and quality are preserved. Few existing work on ADLs fully support component addition, removal and substitution processes from their description to their test and validation. The main idea of this work is to have software architecture evolution dynamically driven by connectors (the software glue between components). It proposes a connector model which embeds the necessary mechanisms to do so. These connectors autonomically handle the reconfiguration of connections in architectures in order to support the addition, removal and substitution of components in a gradual, transparent and testable manner. Hence, the system has the choice to commit the evolution after a successful test phase of the software or rollback to the previous state.

Introduction

The role of software architectures in software engineering becomes increasingly important and widespread [START_REF] Garlan | Software architecture: a roadmap[END_REF]. Software architectures model the structure and behavior of systems. Architecture description languages (ADLs) [START_REF] Medvidovic | Moving architectural description from under the technology lamppost[END_REF] are not solely used during the design steps of the development process anymore, but also at runtime after deployment, to manage the evolution of application architecture. However, most ADLs do not fully support the evolution process of software systems. Software evolution is the process to change a software system from some version to a newer version to improve its functionality, performance or reliability. It consists in addition, removal and replacement software components or connectors. These operations are error-prone. Indeed, it is difficult to guarantee the preservation of the functionality and quality of the software. It is also possible that the new software version be unstable after the introduction of new components or the removal of existing components. Some validation process should secure component adding, removing and replacing to avoid errors or regressions to be introduced by new component versions or instability due to component removals. Evolution mechanisms are provided in the main representative ADLs [START_REF] Medvidovic | A language and environment for architecture-based software development and evolution[END_REF], [START_REF] Rakic | Increasing the confidence in off-the-shelf components: A software connector-based approach[END_REF], [START_REF] Roshandel | MAE-a system model and environment for managing architectural evolution[END_REF] to deal with elementary evolution operation in software architectures. However, existing works only propose limited support for evolution control that increases the chances for successful dynamic evolution. This paper considers applying an autonomic approach to manage and control evolution at runtime. A connector model is proposed which embeds the necessary mechanisms to monitor and drive architecture modifications: we talk about connector-driven architecture evolution. Connectors are internally designed as expendable and reconfigurable component assemblies, able to manage various evolution concerns, depending on the requirements. An application of these connectors is presented here: gradual evolution of assemblies in which new component versions are transparently tested before they effectively replace older ones and in which components connected to those that are going to be removed are tested without the component to be removed before it is effectively.

The remaining of this paper is organized as follows. Section 2 defines the context of this research and spans existing related work. Section 3 specifies our objectives and describes the illustrative example we use throughout the paper. Section 4 describes our autonomic connector model. Section 5 details our connector-driven gradual evolution process. Section 6 briefly describes the implementation of our model as an extension of the Julia implementation of the Fractal component model while Section 7 concludes with future work directions.

Context and related works

To develop a connector-driven gradual and dynamic evolution process requires an understanding of existing ADLs that support dynamic evolution.

Software evolution: definitions and typologies

Lehman [START_REF] Lehman | Towards a theory of software evolution -and its practical impact[END_REF] defines software evolution as the collection of all programming activities intended to generate a new version of some software from an older operational version.

If these activities can be performed at runtime without the need for system recompilation or restart, evolution is called dynamic software evolution. An explicit architectural view can enhance flexibility of software evolution. The software architecture of a program or computing system defines the structure of the system, which comprise software component types and connector types, the externally visible properties of those component types and connector types and the relationships among them [START_REF] Bass | Software Architecture in Practice[END_REF]. Architectural configurations are connected graphs of concrete components (instantiated component types) and concrete connectors (instantiated connector types) that conform to the architectural structure [START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF]. Figure 1 provides an example of both an architecture and a conforming configuration using the syntax of the C2 ADL [START_REF] Medvidovic | Formal modeling of software architectures at multiple levels of abstraction[END_REF].

Existing work propose various typologies for evolution [START_REF] Buckley | Towards a taxonomy of software change[END_REF], [START_REF] Lientz | Software Maintenance Management[END_REF], that we are going to use to precise which evolution is supported in the system defined in this paper.

Dynamic software evolution might affect component or connector types at the architecture level or component or connector instances at the configuration level [START_REF] Medvidovic | A classification and comparison framework for software architecture description languages[END_REF]. Evolution might concern the software semantics or its structure. Semantic evolution does not change the structure of the software system. It simply consists in replacing one or more components by their newer versions. Structure evolution changes the structure of the configuration by adding or removing a component that adds or removes functionalities to the system. Before evolution, the system needs to check the consistency of the new configuration by comparing component behaviors. A component's behavior protocols describe the possible orderings of (incoming and outgoing) method calls on the component's interfaces [START_REF] Plasil | Behavior protocols for software components[END_REF].

Lientz and Swanson [START_REF] Lientz | Software Maintenance Management[END_REF] provide an orthogonal classification of evolution based on the reason that motivates changes. They identify three purpose-oriented evolution categories:

• corrective evolution, where the new version corrects errors / bugs identified in the old one,

• perfective evolution where the code of a component is evolved to improve non-functional attributes of the software (such as time performance),

• adaptive evolution where components are adapted (or extended) to meet changes in their environment or in requirements on the software.

This paper deals with dynamic software evolution and covers semantic evolution (through component version substitution) as well as structure evolution (through component addition or removal) and both corrective and perfective evolution.

Dynamic evolution in existing ADLs

Few ADLs focus on supporting dynamic software evolution. Three representative approaches specify dynamic evolution in an ADL by providing a dedicated mechanism together with the original ADL: decomposition and composition in ArchWare [START_REF] Morrison | Support for evolving software architectures in the ArchWare ADL[END_REF], an Architecture Modification Language (AML) in C2 [START_REF] Oreizy | Architecturebased runtime software evolution[END_REF] or the use of multi-version connectors in MAE [START_REF] Rakic | Increasing the confidence in off-the-shelf components: A software connector-based approach[END_REF]. ArchWare uses hyper code to examine the coherence of new configuration and implements evolution by decomposing the targeted configuration and then composing the new configuration. This approach introduces additional risks during the evolution processes that makes evolution more complicate to implement. Evolution in C2 uses AML to manage the configuration evolution with a consistence examination of new configuration, and for component substitution, it uses a type theory-PL subtyping relationship [START_REF] Palsberg | Three discussions on object-oriented typing[END_REF] to check the consistency of component specification. Figure 1 shows an example of how the evolution can be implemented in the C2 AML syntax. However, this approach lacks to test the actual implementation of the new component. Cook and Dage [START_REF] Cook | Highly reliable upgrading of components[END_REF] propose to keep multiple versions of a component running and uses arbiters to present to the system the image of a single component. Furthermore, Rakic [START_REF] Rakic | Increasing the confidence in off-the-shelf components: A software connector-based approach[END_REF] introduces this approach into an ADL (MAE) and uses connectors instead of arbiters. This multiversion approach improves component substitution evolution by connecting multiple versions of components at the same time in the system. Both approaches limit the changes on new component versions: they constrain the outputs -the values returned by function executions -of new versions to remain unchanged. In these two latter approaches however, component versioning aims at keeping old versions along with newer ones in the system for downward compatibility. The system thus grows in complexity and size which is not suitable in our case where newer versions aim at replacing older ones after an intermediate test period.

The above representative ADLs contain useful insights for evolution, but they fail to account for several pertinent issues. There is:

1) no gradual process to ensure safe dynamic evolution, 2) no real test of the actual new configuration to try and detect functional problems that might be introduced by a new component or instability that might result from some component suppression, 3) no use of evolution semantics to drive the evolution process 4) no mechanism to deal with system recovery when evolution fails.

Connector semantics

Connectors bind components together and act as mediators between them [START_REF] Shaw | Abstractions and implementations for architectural connections[END_REF]. They clearly separate concerns of component computation and inter-component communication. Connector ends are typed by a set of interfaces (a set of connection points) that define the signatures of functionalities that the connector passes through. Each interface has a direction, either provided or required. A provided (resp. required) interface of a connector can connect to a required (resp. provided) interface of a component, if their types are identical (or, in a wider sense, compatible [START_REF] Arévalo | Precalculating component interface compatibility using FCA[END_REF]). If the set of interfaces at one end of the connector is the same but has opposite directions as the set of interfaces at its other end, then the connector just lets functionality calls pass through. If not, the connector is said to do some functional adaptation. For simplicity's sake, in this paper, connectors are pass through connectors; they don't adapt function calls (yet).

Representative connectors models are UniCon [START_REF] Shaw | Abstractions and implementations for architectural connections[END_REF], SOFA [START_REF] Bálek | Software connectors and their role in component deployment[END_REF], Wright [START_REF] Allen | A formal basis for architectural connection[END_REF] and COSA [START_REF] Oussalah | An explicit definition of connectors for component-based software architecture[END_REF]. Beyond the basic binding function of connectors, each of these models has its specificity. UniCon has a predefined taxonomy of connectors, either simple or complex (pipes, remote calls, etc.). SOFA has a composite connector model that allow connectors to be described by an inner component architecture. Wright models connector glue and event trace specification with CSP. COSA eases the building of numerous connector types by composing simple connectors. None of these models, however, provide system life-cycle related services.

As connectors clearly separate concerns of component computation and inter-component communication, we claim they can be designed to meet non-functional requirements of systems, such as adding security (encrypting messages) or life-cycle related services. Our work proposes a connector model which embeds a system evolution support service. It reconfigures the connections between components to add new component versions, remove components or replace components by one of their (newer) versions. This is why our evolution process is said to be connector-driven.

Goals and illustrative example

Dynamic software evolution requires that evolution be performed at runtime. This operation is risky as the new version might introduce errors. These errors might come from the functional problem of new configuration introduced by new components or new component versions, or from the inconsistency of new configuration caused by the removal of components. Despite this, most research on dynamic evolution mainly focuses on configuration consistency test at the architecture level, before the implementation of evolution.

To our knowledge, no approach proposes a gradual process based on the configuration level that supports dynamic evolution and include correction tests of both the new configuration and the newly introduced components; no ADL uses the semantics of evolution operations to describe, test and measure the quality of the evolved software; and no connector model embeds mechanisms to monitor and drive evolution.

The work presented in this paper aims at developing a connector driven gradual and dynamic evolution process which fully covers evolution, from its description to its test and validation. It focuses on three elementary change operations -component addition, removal and replacementand tests to the validity of changes before committing them. As an initial application of our work, each evolution consists in a single change operation. When component replacement is concerned, the evolution semantics proposed by Lientz and Swanson [START_REF] Lientz | Software Maintenance Management[END_REF] is used to measure the adequateness of the new component. Our system covers two of their evolution purposes: perfective evolution and corrective evolution. It uses this information on evolution semantics to test the resulting configuration. Furthermore, our evolution process is required to have the following characteristics:

1) gradual: have the architecture evolve smoothly through a transitional phase, 2) testable: be able to test desired changes (component evolution) and validate them before they become effective, 3) transparent: have changes (introduce new component and remove existing component) during the transitional phase and test phase remain transparent to the software system, 4) self-repairable: prevent fatal failures using a system recovery mechanism. This implies that components have the capability of recording their internal states and recovering from this recorded state when needed. In order to support such evolution process, connectors need to supply following functionalities: 1) connect and disconnect multiple component versions at runtime, 2) test new configuration and collect observation data, 3) control the dataflow to make component test transparent to the system. The example of a bike rental system illustrates the concepts of our evolution process throughout the paper (cf. Fig. 2). In this example, the Vendor component manages the user interface. It cooperates with the Basket component which handles user commands. The Basket component cooperates with the User, BikeTrip and Account components respectively to identify the user, check the balance of its account, assign an available bike and finally calculate the price of the course when the bike is returned. Component BikeTrip manages the courses for each bike and each user and is designed to retrieve location and calculate the distance between departure and arrival addresses.

Connectors that drive the evolution process

In this section, our definition of the conceptual model of component architectures and connectors is presented. In our model, a software configuration is defined as a collection of components and connectors which are contained in and managed by a container. These architectural entities are composed of core and extension elements. Core elements consist of classes which describe the basic, invariable part of the different kinds of architectural entities, i.e. their functional concerns. Extension elements are added to architectural entities in order to support the non-functional concerns which apply specifically, depending on the management policies defined by ADL descriptors, regarding for instance the dynamic evolution of components. Extension elements consist of meta-objects, Controllers and Control interfaces, that are added to the definition of components to modify and control their behavior. Figure 3 shows the class model of architectural elements.

A container can be seen as the component at the top of the composition hierarchy. It contains the description of the entire software system and thus contains a set of connectors and components which describe a system as a configuration. It is extended by an evolution manager which manages the evolution of its inner components and evaluates the feedback from its inner connectors.

A component has a name and a set of interface elements. There are two kinds of components: primitive and composite. A primitive component is a leaf component that is directly implemented. A composite component is built from the interconnecting o more primitive components and connectors as a substructure. Primitive components are extended by StateTrace controllers. StateTrace controllers keep track of the successive states of primitive components each time they are modified. They allow to recover from a failure and put back the components into a sound state to prevent system breakdown.

Connectors govern communication between components. A connection is the binding between provided and required interfaces of components and connectors. Indeed, components should not communicate directly by referencing each other. Instead, they should use connectors which minimize coupling between components and enable binding decisions to change without requiring component modification. The interfaces of two component which are connected by a connector need to be compatible: the names of methods should be the same. The connection should be chained as is: a component's required interface connects to a connector's provided interface and the required interface of the connector connects with another component's provided interface.

Connectors are extended to manage and control the evolution of each connected component, control the dataflow between components and collect test samples of component inputs and outputs. The extension of connectors consists of three controllers: the connector controller, the dataflow controller and the time controller. The connector controller controls evolution procedures of the connected components. The dataflow controller controls the dataflow that traverses the connector and records messages from each connected component to compare them in case evolution is declared to be corrective. The time controller records input and output time of each message that traverses the connector to compare them in case evolution is declared to be its perfective.

These controllers are structured into three levels. Evolution manager is a top-level controller that controls the entire configuration evolution process by managing connectors and components. Connector controllers and state-Trace controllers separately control local evolution actions of respectively connectors and components. Dataflow and time controllers are third level controllers that are used by Connector controllers to control and collect data on

Protocols of the evolution operations

One of the main ideas exposed in this paper is to have the original configuration evolved into an objective configuration through a transition step. The transition configuration aims to test new component versions and either validate the evolution (commit changes) or invalidate it to rollback to the original state.

To achieve this, we propose a four step evolution process controlled by an evolution manager, depicted in Fig. 4. The preparation stage collects evolution description and builds the transition configuration. The test stage collects observations from newly introduced components and components affected by changes (those connected to changing components) to determine if new components work correctly (in case of component addition), new component versions meet the requirements induced by the declared evolution Each stage obeys two phases: evolution and validation. The evolution phase defines how connectors drive the evolution process during each stage. The validation phase determines if the activities performed during each stage are valid or not.

Component substitution

Component version substitution potentially affects four elements of components: their name, interface, behavior protocols or implementation (as described by Palsberg and Schwartzbach [START_REF] Palsberg | Three discussions on object-oriented typing[END_REF]). In our system, component substitution amounts to replace an old version of a component by one of its newer versions in order to meet the declared evolution requirements (corrective evolution or perfective evolution). Thus, the test focuses on the two evolution motivations which affect the measures our evolution manager can perform to guarantee the feasibility of the thought evolution.

Example. The objective of this evolution is to replace version 1 of the Basket component by its version 2. It implies changing the architecture from the original architecture represented on Fig. 2 to the objective architecture represented on Fig. 5b. Evolution concerns the return provided interface and its purpose is corrective. Contrary to most evolution approaches, we propose to deploy a transition architecture (cf. Fig. 5b) to smoothly switch from an architecture to another through a test period. 3) change test condition for corrective evolution. How to evolve refers the number of collected samples that are to be used during tests. In the example of Fig. 2, the return interface of Basket is changed to correct (corrective evolution) its protocol for Basket version 2 with the following condition: if type of bike is tandem then price is twice the normal price. The collected evolution description is shown in Table 1.

Secondly, the evolution manager deploys evolution descriptions according two connector groups: changed group and unchanged group. Changed group contains connectors which connect to changed interfaces like rent, return and selectBike. These connectors drive the evolution process. Unchanged group contains all other connectors like login, pay, etc.

At the validation step, the evolution manager collects feedback from all connectors. If all connectors connect successfully with new component version, the evolution process passes to next stage. Offline test is focused on the functioning of the new version, keeping it transparent to the system. Old version is dominant, which means that connectors just propagate old version's results to the rest of system, while new version is insulated from the system.

Online test aims at adapting the system to new version: new version becomes dominant. As this entails risks of system failure, a state-trace mode is activated. All components' StateTrace controllers record the state modification of each component during online test. When critical errors happen, the whole system rolls back to its previous safe state, as every component rolls back to its previous safe state.

Each test of a changed interface is controlled by the connector which connects with this interface. This includes dataflow control and data collection. Thus, according to the direction of interface (provided or required), test and evaluation behave differently. We use a part of the example to explain how dataflow is controlled by connectors (Fig. 6). The Basket rent (P1) interface illustrates provided interface evolution, and its returnBike (R1) interface illustrates required interface evolution.

Figure 6. Net response time

Provided interface evolution means that a component's provided interface is evolved with either a corrective or a perfective purpose. The return connector (cf. Fig. 6) collects test data and controls the evolution of the return interface of the Basket component.

During offline test, component Basket1 is dominant. The dataflow controller of the return connector distributes incoming calls to two versions, while all connectors block outgoing calls from Basket2 to keep it transparent to system. For example, the return connector blocks the response of Basket2 and the returnBike connector blocks the incoming calls of Basket2. During online test, the situation is reversed: Basket2 becomes dominant. The collected data elements are listed in Table 2.

Required interface evolution means that a component's provided interface is evolved with a corrective purpose. The returnBike connector in Fig. 6 collects test data and controls the evolution of thereturnBike interface of the Basket component.

During offline test, the dataflow controller of the return-Bike connector blocks Basket2 incomings and let pass Bas-ket1 incomings. The outgoings of the BikeTrip component are sent to the two versions of Basket. During online test, the dataflow controller reverses the situation to make the new version (Basket2) become dominant.

To evaluate a new version, observations encompasses various data, ranging from dataflow (test for corrective evolution) to execution times (test for perfective evolution) as listed in Table 2. The dataflow controller is in charge of collecting data from incoming calls which comprises the calling method and inputs and outputs of old and new versions for this calls. The time controller is responsible for collecting time for each input and output. Furthermore, in order to obtain the needed number of observations, each data collection by connectors will continue until all connectors in the changed group have enough observation samples (as defined in the preparation stage).

The evaluation of observations is handled by the evolution manager which collects all observations from connectors and thus have a global view to precisely calculate the time spent in each function in order to test the behavior of the new version. For corrective evolution, the new version must meets its predefined evolution condition. For perfective evolution, the new version must execute faster than the old version. But the time of response measured is not really the response time of the evolved interface. For example, when the return interface of component Basket1 is called by component Vendor, it will call the interface returnBike before it returns an answer to the Vendor component. Thus, the response time of the return interface includes the response time of the interface returnBike. In order to get net response times for the component, the formula to calculate the response time is T response = T go +T back in Fig. 6. After the new version passes the offline and online evaluation, the evolution process proceeds to next stage.

Observation and commit stage. Observation stage is another feature used to further secure evolution. In this stage, the old version still remains in the system, but only as a backup (it is not active anymore). The system is still in state-trace mode. If a critical error of new version arises and makes the system fail, the old version will be activated to replace the new version and the whole system will roll back to the previous sound state. Finally, the evolution manager either commits evolution after the above stages (if the new versions passes all stages) or abandons evolution and disconnects the new version (rollback). The unused version is disconnected and uninstalled.

Component addition

Component addition aims to add some functionality to the system. This change may cause system failure if there are errors in the new component functionality or if the new component is not compatible with its connected components. The evolution process mainly tests the two aspects: the functionality of the new component and the compatibility of the new component to its connected components.

Example. The evolution objective is to add the Station Data to the system. It implies changing the configuration from the original architecture represented on Fig. 7a to the objective configuration Fig. 7b.

Preparation stage. The preparation stage aims to both introduce a new component into the system and connect it. The addition of a component must be accompanied by the addition of new connectors which connect the new component with existing components. At first, the preparation actions for component addition are the same as in other ADLs :

1) Add the component to the system, 2) According to the connected interfaces, generate connectors, 3) Connect the new component and connectors and the existing components. Test stage. The test stage focuses examine the functionality (offline) and adaptiveness (online) of the new component.

• Offline test: test its functionality. Connected connectors authorize the input of new component but do not return the response to test whether the responses are produced correctly.

• Online test: test its adaptiveness with connected component. During this test stage, each affected connector sends twice the input to the connected component. At first, the controlling connectors block the connections between the new component and connected components. The affected connectors collect responses and send them to the system. In a second phase, controlling connectors authorize the connection between the new component and existing components. The affected connectors collect the response but do not send it to the system. Between these two phases, components record their states and after the first phase, return to their original states to pretend that the first phase did not exist. After test, affected connectors send all this data collection to the evolution manager which compares the two sets of responses and decides whether to effectively add the component or not. Observation and commit stage. During this stage, the system remains in recovery alert state. All state controllers record the states of components to prevent errors from the new component. If the new component works well during the observation stage, the system will enter its actual working state.

Component removal

Component removal aims to suppress an unused component from the system. This change may leave the system incomplete and even prevent it from continuing to work. The evolution test evaluates if the new configuration works correctly without the component to remove.

Example. We reverse the example of the component addition. The evolution objective is to remove the Station Data from the system. It implies changing the configuration from the original architecture represented on Fig. 7b to the objective configuration Fig. 7a.

Preparation stage. The preparation stage is similar to component addition's. We need to find the connected connectors, connected components, and affected connectors.

Test stage. This test mainly focuses on the connected components to evaluate whether they can work correctly without the removed component. All affected connectors send twice the same input to connected components. At first, connected connectors authorize input calls from connected components. Affected connectors record this response and send it back to the system. In a second phase, connected connectors block the input calls from connected components. Affected connectors record the responses of connected components which do not successfully call the removed component. After test, affected connectors send all this data collection to the evolution manager which compares the two sets of responses and decides whether to effectively remove the component or not.

Observation and commit stage. The removed component will remain in the system but isolated by connected connectors, to prevent connected components from generating instability errors. If the system has no problem during the observation stage, the removed component and connected connectors will be effectively be removed from the system.

Implementation as a Fractal extension

Our model is implemented as an extension of Julia, an open-source java implementation of the Fractal component model1 . In the Fractal component model, everything has to be a component. Fractal components are managed by controllers contained in the membrane of components. It thus was straightforward to adapt our model to the implementation. First, we kept all existing Fractal controllers. The evolution manager implements the EvolutionCon-trolInterface to control evolution through two mains functions as presented in Fig. 8. The cmpEvol function triggers component version evolution: it is given as parameters the old and new component versions, the set of interfaces that are impacted by the change and the purpose of the evolution (corrective, perfective or both). The add function triggers component addition evolution: firstly, the new component will be added to system, secondly, it automatically generates a suitable connector and uses to connect given components (connections presents which component's interface it should be connect). The remove function triggers component removal evolution.

Figure 9 shows a code sample that uses these functions.

Conclusion and perspectives

This paper presents and illustrates our connector-driven gradual and dynamic software assembly evolution process. Few existing ADLs fully support component replacement evolution process from its description to its test and validation. These ADLs do not support either component substitution, or any test phase, or the complexity induced by multiversion components. Our contribution is twofold. Firstly, we propose a gradual, testable, transparent and repairable evolution process which fully supports evolution operations from the specification of evolution semantics to the test and validation of changes. Secondly, we introduce a connector model which embeds the necessary mechanisms to monitor and drive architectural configuration modifications. We use evolution semantics to automatically build a connector that measures, in situ, the safety of the desired changes and either commits or rollbacks them.

Perspectives for this work are numerous. We plan to use the same process to support complex evolution operations [START_REF] Urtado | Complex entity versioning at two granularity levels[END_REF] that are composed of several successive ele-// connect aComp to cComp1 Fractal.getEvolutionManager(container). connect (aComp, "r", cComp1, "f"); // evolve component cComp1 to cComp2 // (corrective evolution) Fractal.getEvolutionManager(container). cmpEvol (cComp1, "f", cComp2, "corrective", "if(m.equal("bike")) rent(m)=1;"); Figure 9. Use of the evolution manager mentary operations that are all semantically related. The semantics of these changes might also be exploited to drive the change process. We also plan to tackle the "architecture drift" [START_REF] Perry | Foundations for the study of software architecture[END_REF] problem which is a crucial coherence problem after architectural configuration evolution. It will consist in synchronizing the architectural view of the software system to the actual implementation, thus allowing to enrich the architectural description of the software from the changes that succeeded.

Figure 1 .

 1 Figure 1. Sample architecture (left), a conforming configuration (top right) and an evolution description (bottom right) described using C2 and C2 AML

Figure 2 .

 2 Figure 2. Example of a bike rental system configuration

Figure 3 .

 3 Figure 3. Class model of connectors

Figure 4 .

 4 Figure 4. Life cycle of evolution actions

Figure 5 .

 5 Figure 5. Example of component substitution evolution

  Test stage. Test stage aims to examine the behavior of new component version according to its evolution purpose. Test stage thus involves collecting observations on new component versions in connectors and evaluating this ob-servation in the evolution manager. The measurement of new component versions focuses on functioning and are decomposed into to two sub-stages: offline and online test.

Figure 7 .Figure 8 .

 78 Figure 7. Example of component addition

Table 1 .

 1 Evolution description of example

	Components	Old	Basket version 1
		New	Basket version 2
	Change inter-	Purpose	Condition
	face
	selectBike
	rent	perfective
	return	corrective	if	bike∈Tandem	then
			Basket2.return(bike)=
			2*Basket1.return(bike)

Table 2 .

 2 Offline and online data collected by controllers.Then, in order to test the new component, we need to find its connected components and the affected interfaces from its connected components, the interfaces of the connected components that are indirectly involved in the behavior of the interfaces of the changed component. We uses the affected connectors which connect with affected interfaces to test new version's adaptiveness. The new generated connectors which connect new component with other components called connected connectors. Table3summarizes this data for the addition of the Station Data component of our example.

	Controllers	Provided interface evolution	Required interface evolution
	Dataflow Controller (DC)	(method, input, outputOld, outputNew)	(method, inputOld, inputNew, output)
	Time Controller (TC)	(method, inputTimeOld, outputTimeOld, inputTimeNew, outputTimeNew)

Table 3 .

 3 Affected connectors and components when adding the Station Data component.

	Connected connectors	findLocation, calcDistance
	Connected components	BikeTrip
	Affected connectors	selectBike, returnBike

http://www.objectweb.org