Member IEEE Usman Zabit
email: usman.zabit@seecs.nust.edu.pk

Khadija Shaheen

Maryam Naveed

Member IEEE Olivier D Bernal

Senior Member Thierry Bosch

Automatic Detection of Multi-modality in Self-Mixing Interferometer

Keywords: Self-mixing Interferometry, Optical Feedback Interferometry, Vibration Measurement, Laser Sensors, Neural Networks, Laser modes, Laser feedback. I. INTRODUCTION elf-mixing interferometry (SMI) or optical feedback interferometry

Laser feedback based self-mixing interferometry (SMI) has been demonstrated for diverse metric sensing applications. Typically, SMI sensors are based on such laser diodes (LDs) which provide mono-modal emission resulting in SMI signals in which each interferometric fringe occurs due to change in optical path length of λ/2, where λ is emission wavelength. However, in case multiple laser modes undergo SMI, then each mode contributes its own set of fringes. As LDs can emit multiple modes under variable operating conditions, so, non-detection of multiple SMI modes can cause drastic increase in measurement error due to wrong interpretation of fringes. Previously, detection of multiple laser modes undergoing SMI was achieved by adding spectroscopic instruments to the SMI setup. This, however, compromises the inherent simplicity of SMI sensing. In this work, an automatic SMI based multi-modality detection method is proposed which is able to detect if multiple modes of deployed LD are undergoing SMI and are contributing additional fringes within the SMI signal under variable sensing conditions. Such detection enables correct interpretation of SMI fringe count and can be used to signal occurrence of modehopping or secondary mode excitation. The method uses an artificial neural network, able to automatically identify uni-, bi-, or tri-modal SMI signals. Two different LDs (emitting at 637 nm and 650 nm) were used to acquire 131 experimental uni-, bi-, and tri-modal SMI signals for variable operating conditions and target vibration amplitude. The proposed system has achieved modality detection accuracy of 98.57% on 70 unseen experimental SMI signals.

displacement [START_REF] Milesi | Measurement of local chest wall displacement by a custom self-mixing laser interferometer[END_REF][START_REF] Bernal | Robust Detection of Non Regular Interferometric Fringes from a Self-Mixing Displacement Sensor using Bi-Wavelet Transform[END_REF], distance [START_REF] Norgia | Absolute distance measurement with improved accuracy using laser diode self-mixing interferometry in a closed loop[END_REF], vibration [START_REF] Lu | Dual-channel self-mixing vibration measurement system in a linear cavity fiber laser[END_REF][START_REF] Khan | Adaptive Cancellation of Parasitic Vibrations Affecting a Self-Mixing Interferometric Laser Sensor[END_REF], velocity [START_REF] Valavanis | Self-mixing interferometry with terahertz quantum cascade lasers[END_REF], refractive index [START_REF] Zhang | Self-Mixing Interferometer Based on Frequency Analysis Method for Accurate Refractive Index Measurement[END_REF], range finding [START_REF] Norgia | High resolution self-mixing laser rangefinder[END_REF], flow [START_REF] Norgia | Self-mixing laser Doppler spectra of extracorporeal blood flow: a theoretical and experimental study[END_REF], strain [START_REF] Suleiman | Interrogation of fiber Bragg grating dynamic strain sensors by self-mixing interferometry[END_REF], and imaging [START_REF] Bertling | Imaging of acoustic fields using optical feedback interferometry[END_REF] etc.

Traditionally, mono-modal laser diodes (LD) are used for SM sensing and each interferometric SM fringe is assumed to occur for a remote target motion of /2, where  is the LD wavelength. /2 is thus considered the basic resolution of SM sensors. However, in case of change in LD modality (e.g. switching from mono-modal to bi-, or even tri-modal emission), different individual modes [START_REF] Keeley | Measurement of the emission spectrum of a semiconductor laser using laser-feedback interferometry[END_REF] under SM are incoherently superimposed and a corresponding subperiodicity appears in the SM signal [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF][START_REF] Tucker | Effect of multiple transverse modes in selfmixing sensors based on vertical-cavity surface-emitting lasers[END_REF]. As a result, fringes within the multimodal SM signal need to be interpreted differently. Thus, if the LD under optical feedback exhibits multi-modal behavior during the course of continuous sensing of a remote target then the corresponding multiplicity of SMI fringes needs to be appropriately detected and classified in order to correctly retrieve the target displacement with potentially improved SMI sensor resolution [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF][START_REF] Pham | Selfmixing sensing under strong feedback using multimode semiconductor lasers[END_REF]. This multiplicity of SMI fringes, however, turns into a source of drastic increase in measurement error [START_REF] Tucker | Effect of multiple transverse modes in selfmixing sensors based on vertical-cavity surface-emitting lasers[END_REF] in case failure occurs in detecting the change in multiplicity of SMI fringes. Thus, any change from uni-modal to multi-modal SMI signal (or vice-versa) needs to be automatically detected followed by appropriate fringe count interpretation. Otherwise, even advanced SMI displacement/vibration retrieval algorithms yielding high accuracy (for uni-modal SMI) [START_REF] Arriaga | Real-time algorithm for versatile displacement sensors based on self-mixing interferometry[END_REF][START_REF] Bernal | Study of laser feedback phase under self-mixing leading to improved phase unwrapping for vibration sensing[END_REF][START_REF] Wei | Obtaining Scalable Fringe Precision in Self-Mixing Interference Using an Even-Power Fast Algorithm[END_REF][START_REF] Bernal | Robust method of stabilization of optical feedback regime by using adaptive optics for a self-mixing micro-interferometer laser displacement sensor[END_REF][START_REF] Ehtesham | Analysis and Implementation of a Direct Phase Unwrapping Method for Displacement Measurement using Self-Mixing Interferometry[END_REF][START_REF] Donati | Single Channel Self-Mixing Interferometer Measures Simultaneously Displacement and Tilt and Yaw Angles of a Reflective Target[END_REF][START_REF] Fan | Improving the measurement performance for a self-mixing interferometrybased displacement sensing system[END_REF][START_REF] Giuliani | Self-mixing laser diode vibrometer[END_REF][START_REF] Siddiqui | All Analog Processing of Speckle Affected Self-Mixing Interferometric Signals[END_REF][START_REF] Jha | Frequency-Modulated Optical Feedback Interferometry for Nanometric Scale Vibrometry[END_REF][START_REF] Magnani | Self-mixing vibrometer with real-time digital signal elaboration[END_REF] will provide erroneous measurements.

Variation can occur in LD modality [START_REF] Keeley | Measurement of the emission spectrum of a semiconductor laser using laser-feedback interferometry[END_REF][START_REF] Pham | Selfmixing sensing under strong feedback using multimode semiconductor lasers[END_REF] due to change in laser diode' operating current [START_REF] Keeley | Measurement of the emission spectrum of a semiconductor laser using laser-feedback interferometry[END_REF] or temperature [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF] while change in length of external cavity also influences the modality of the laser under optical feedback [START_REF] Tucker | Effect of multiple transverse modes in selfmixing sensors based on vertical-cavity surface-emitting lasers[END_REF]. Currently, change in modality cannot be detected without introducing optical components and spectroscopic instruments into the SM sensor set-up [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF]. Such introduction of additional optical components, however, compromises the inherent simplicity (see Fig. 1) of SM sensing for real-world applications.

To the best of authors' knowledge, no previous method exists for automatic detection of changes in SMI signal's modality. In this work, an artificial neural network (NN) based system has been designed to achieve automatic detection and classification of multi-modality of optical feedback based SMI signals for sensing purposes using two different laser diodes.

As a result, SM fringe count can now be correctly and automatically interpreted even if the SMI signal changes from uni-modal to multi-modal operation. Such a detection potentially allows the use of multi-modal lasers for sensing purposes as well, thus extending the choices in an area previously dominated by mono-modal lasers. Similarly, it enables monitoring and SMI based use of such uni-modal laser diodes which are prone to switch to multimode operation e.g. due to change in operating conditions.

As another potential use, the automatic multi-modality detection provided by the NN can also be used in a feedback loop so that either LD operating current [START_REF] Pham | Selfmixing sensing under strong feedback using multimode semiconductor lasers[END_REF] and/or the focusing lens position be electronically controlled (e.g. as already demonstrated for the robust stabilization of optical feedback regime of SMI sensor using electronically controlled liquid lens [START_REF] Bernal | Robust method of stabilization of optical feedback regime by using adaptive optics for a self-mixing micro-interferometer laser displacement sensor[END_REF]) so that LD based SMI sensor is stabilized to operate with a specific uni-/multi-modal behaviour.

NNs have been regularly used to improve the performance and selectivity of various sensors such as surface acoustic wave sensor array [START_REF] Jha | Preprocessing of SAW sensor array data and pattern recognition[END_REF], gas-mixture sensors [START_REF] Zhao | Detection of formaldehyde in mixed VOCs gases using sensor array with neural networks[END_REF], optical-fiber based sensor [START_REF] King | An optical-fiber sensor for use in water systems utilizing digital signal processing techniques and artificial neural network pattern recognition[END_REF], and chemical sensors [START_REF] Lozano | Identification of typical wine aromas by means of an electronic nose[END_REF] etc. Likewise, NNs have also been used for SMI based sensing. For example, an SMI sensor, using NN for the data processing, was designed to classify the surface of the remote moving target [START_REF] Shinohara | Compact optical instrument for surface classification using self-mixing interference in a laser diode[END_REF]. The results presented better than 92% correct classification for eight different surfaces involving different materials, manufacturing methods, and roughness levels. The NN used statistics of mean speckle amplitude, mean speckle frequency, and speckle contrast [START_REF] Shinohara | Compact optical instrument for surface classification using self-mixing interference in a laser diode[END_REF]. Similarly, NN was used to eliminate the noise associated with the uni-modal SMI signals belonging to weak and moderate optical feedback regimes [START_REF] Wei | Pre-processing of signals observed from laser diode self-mixing intereferometries using neural networks[END_REF]. It eliminated noise by means of NN curve fitting technique. Simulations revealed a measuring accuracy of λ/25 for weak optical feedback and λ/20 for moderate optical feedback regime SMI signals [START_REF] Wei | Pre-processing of signals observed from laser diode self-mixing intereferometries using neural networks[END_REF].

The paper is organized as follows: Section II discusses the broad principles of SMI and the deployed experimental set-up for acquisition of multi-modal SMI signals. NN based classification methodology and detection results are described in Section III followed by Discussion and Conclusion.

II. SELF-MIXING INTERFEROMETRY

SMI is a very attractive sensing scheme in the way that it allows a simple laser diode (LD) package (containing its builtin photodiode) to be simultaneously used as a laser source, a micro-interferometer, and a detector. This thus allows a compact, miniaturized, low-cost, and self-aligned sensor capable of nanometric measurement accuracy [START_REF] Donati | Developing self-mixing interferometry for instrumentation and measurements[END_REF][START_REF] Taimre | Laser feedback interferometry: A tutorial on the self-mixing effect for coherent sensing[END_REF]. An SMI system is much simpler than conventional interferometers because many optical elements such as beam splitters, reference mirror, and external photo-detector are not required. Thus, with a simply constructed optoelectronic system, smart laser sensors have been developed using SMI. SMI signals are observed when a part of the back-reflected laser beam illuminating a remote target re-enters into the active optical cavity. This then causes a mixing of generated and back-reflected optical fields within the laser cavity. The said mixing or interference affects the properties of laser including modulation of its wavelength [START_REF] Keeley | Measurement of the emission spectrum of a semiconductor laser using laser-feedback interferometry[END_REF] and optical output power (OOP) of the laser as a function of changes in the optical path length [START_REF] Bertling | Imaging of acoustic fields using optical feedback interferometry[END_REF]. The variation in the OOP of the laser diode P(t) caused by this optical feedback can be written as [START_REF] Donati | Developing self-mixing interferometry for instrumentation and measurements[END_REF]:

𝑃(𝑡) = 𝑃 0 [1 + 𝑚𝑐𝑜𝑠[𝛷 𝐹 (𝑡)]] (1
) where P0 is the emitted power under free running conditions, m is the modulation index and ΦF(t) is the laser output phase in the presence of feedback, given by [START_REF] Donati | Developing self-mixing interferometry for instrumentation and measurements[END_REF]:

𝛷 𝐹 (𝑡) = 2𝜋 𝐷(𝑡) 𝜆 𝐹 (𝑡) 2 ⁄ (2)
where D(t) is the target displacement. The emission wavelength subject to feedback λF(t) is provided by the wellknown excess phase equation [START_REF] Donati | Developing self-mixing interferometry for instrumentation and measurements[END_REF]: 𝛷 0 (𝑡) = 𝛷 𝐹 (𝑡) + 𝐶𝑠𝑖𝑛[𝛷 𝐹 (𝑡) + arctan(𝛼)]

(3) where Φ0(t) is the laser output phase in the absence of feedback, given by:

𝛷 0 (𝑡) = 2𝜋 𝐷(𝑡) 𝜆 0 (𝑡) 2 ⁄ ( 4
)
where λ0 is the emission wavelength under free running conditions, and α is the line width enhancement factor, also known as Henry's factor [START_REF] Henry | Theory of the linewidth of semiconductor lasers[END_REF]. The feedback coupling factor C, also known as Acket's parameter [START_REF] Acket | The influence of feedback intensity on longitudinal mode properties and optical noise in index-guided semiconductor lasers[END_REF], is usually used to identify the SM operating regime such as weak-(C < 1), moderate-(1 < C < 4.6), or strong-(C > 4.6) optical feedback regime [START_REF] Donati | Developing self-mixing interferometry for instrumentation and measurements[END_REF][START_REF] Taimre | Laser feedback interferometry: A tutorial on the self-mixing effect for coherent sensing[END_REF].

A. Self-Mixing Sensing Set-up

Fig. 1 schematizes a basic arrangement for studying the SM effect. The arrangement consists of a laser diode biased with a constant current while the built-in monitor photodiode, receiving light from the back facet of the laser diode, is used to measure the optical output power emitted by the laser.

The so-called external cavity is created between the front facet of LD and moving target, which may be cooperative (i.e. mirror) or non-cooperative (i.e. diffuse surface). For a given target surface, the focusing lens placed in the external cavity and the sensor-to-remote-target distance determine the amount of optical feedback coupling into the LD. The experimental setup was tested using two different LDs i.e. L637P5 and HL6501MG. L637P5 LD has threshold current Ith of 20mA, a slope efficiency η of 1mW/mA and λ0 of 637nm at 25˚C, providing 5 mW of optical power. HL6501MG LD has Ith of 75mA, η of 0.75mW/mA and λ0 of 650 nm at 25˚C providing 35 mW of optical power.

The collimation tube (model LT110P-B by ThorLabs) with focusing lens of 6.24 mm focal length was used to house the laser diode and to focus the laser beam onto the vibrating target. A custom-made circuit board was used to drive the LD with adjustable operating current. It also includes a transimpedance amplifier (TIA) to amplify the photodiode signal.

C. Experimental Observations

The laser diode L637P5 was biased with constant current of 23mA and the external cavity length Lext was about 10 cm. The lens of collimation tube was initially set to the defocus position thus small amount of optical feedback occurred resulting in a mono-modal SMI signal as shown in Fig. 3(b). When the amount of optical feedback was increased by focusing the lens, other modes of LD also entered SM and a sub-periodicity appeared in the optical output power, resulting in a bi-modal SM signal, as seen in Fig. 3(c). When the amount of optical feedback was increased further, tri-modal SMI signal appeared, as seen in Fig. 3(d).

Similar results were obtained by using HL6501MG with operating current of 78mA, as shown in Fig. 4.

It was also observed that the shape of a given multi-modal (e.g. tri-modal) SM signal significantly varied as Lext was varied while the focus remained the same (see Fig. 5 and Fig. 6). This may be due to different gain and phase shifts encountered by individual modes making up the tri-modal signal which are incoherently superimposed [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF][START_REF] Tucker | Effect of multiple transverse modes in selfmixing sensors based on vertical-cavity surface-emitting lasers[END_REF].

"Previous research [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF] measured the optical spectra corresponding to multiple modes undergoing optical feedback. The number of modes undergoing SM was controlled by varying the amount of optical feedback (which in their experimental setup was controlled through a variable optical attenuator). Importantly, it was also experimentally observed that a normally mono-modal laser diode (such as Mitsubishi ML1412 LD with Ith of 43 mA, η of 0.75 mW/mA, and λ0 of 680 nm at 25 °C) can be subject to mode hopping under optical feedback [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF]. Specifically, when ML1412 LD was biased at 50 mA then it presented a mono-modal optical emission spectrum. However, under specific amount of optical feedback resulting in a bi-modal SM signal, the corresponding optical spectrum showed that optical intensity of the second mode was approximately 80% with respect to the primary mode. Likewise, in the case of tri-modal SM signal, optical intensity of second (third) mode was approximately 75% (55%) with respect to the primary mode [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF].

A. SMI Data-set

As previously mentioned, various mono-, bi-, and tri-modal experimental SMI signals were acquired using two different LDs by varying the optical feedback through variation of Lext (from 15 cm to 60 cm approximately) and lens' focus. The peak to peak amplitude of target vibration was also varied (from 0.7 µm to 3 µm approximately) resulting in change in the number of fringes per vibration cycle in SMI signal (varying from 2, 4, or 6 fringes to 9, 18, or 27 fringes for uni-, bi-, or tri-modal operation respectively). Thus, multiple monomodal, bi-modal, and tri-modal SMI acquisitions were obtained to form a data-set. Specifically, this data-set is composed of 131 SMI signals with 42 uni-modal (32.1%), 42 bi-modal (32.1%), and 47 tri-modal (35.8%) SMI signals.

B. Pre-processing

Different SMI signals are made comparable by removing any dc offset followed by normalization of SMI signal amplitude within the range [1 -1]. Likewise, for correct classification, it is important to enhance the quality of the input experimental SMI signals by using filtering to reduce noise. Lastly, it is important to take such steps (e.g. differentiation) so that subsequent features can be extracted (see Fig. 8).

1) DC Offset Removal 2) SMI Signal Normalization 3) Low Pass Filtering

The normalized SMI signal is passed through a low pass filter. This improves the overall signal to noise ratio of experimentally acquired SMI signals and makes their patterns (based on sub-periodicity in case of multi-modality) become more prominent (see Fig. 8 (b)). The process of down-sampling is performed (by a factor of 3) thereby reducing the total number of samples of raw SMI signal which is sampled at a high sampling rate. As a result, the slopes of transitions (indicative of fringes) in SM signal become steeper and hence can be better localized in subsequent steps (see Fig. 8(c)). Note that all subsequent steps are carried out on this filtered and down-sampled SMI signal, denoted as SMd.

4) Down-sampling

5) Differentiation

The pattern of transitions (indicative of location of individual fringes) in multi-modal SMI signals is an important feature for classification of SMI multi-modality as this pattern is indicative of individual modes contributing in a multi-modal SMI signal. By performing differentiation of SMd, each transition (fringe) within the SMI signal appears as local peak in differentiated SMI signal (see Fig. 8(d)). Thus, these transitions (indicative of individual fringes) can be localized and the associated pattern can be identified and later used as a part of other features indicative of modality.

C. Feature Extraction

As experimental SMI signals can be composed of hundreds of thousands of samples per second due to high sampling rate requirements of typical SMI signals so it is important to reduce the dimensionality of the input SM signals while preserving their significant features (whose values are different for each class of modality, thus enabling class identification). This stage is known as feature extraction. So input data is processed in such a way that the useful features (providing clues of a certain modality) existing in the SMI signal are extracted. The important features include:

1) Amplitude of peaks of differentiated SMI signal

The pattern made up by the values of amplitude of peaks in differentiated SMI signal is usually different in each case of modality of SMI signals (i.e. mono-modal, bi-modal, and trimodal SMI signal.) These peaks, shown in Fig. 9(a), need to be first detected and then their amplitude values and locations (used later on) are saved. Values of six consecutive peaks are used later as features.

2) Amplitude difference between consecutive peaks

The peaks of 𝑆𝑀 𝑑 signal are identified and the difference of amplitude (∆𝑃) between 6 consecutive peaks (resulting in five ∆𝑃 values) is computed as shown in Fig. 9. The pattern of ∆𝑃 is usually different in each mode of SMI signal and thus can be utilized for modality classification.

3) Time difference between consecutive peaks

The time indices of peaks in 𝑆𝑀 𝑑 signal are identified (using their location information) and the difference of indices (∆𝑡) between 6 consecutive peaks (resulting in five ∆𝑡 values) are computed as shown in Fig. 9. The pattern of ∆𝑡 is also usually different in each mode of SMI signal which makes it a useful feature.

In order to achieve high accuracy in modality classification, following guidelines were followed:

1) The detected peaks should not include the directionreversal segment of SMI signal, as it is devoid of true fringes.

2) No genuine peak should remain undetected within the SMI signal segment used for feature extraction." Thus, each SMI signal is processed so that its corresponding feature vector is obtained. The feature vector is then composed of 16 total elements in which 6 elements are taken from the peak value of differentiated SMI signal, 5 elements from the amplitude difference between peaks of SMd, and 5 elements from time difference between peaks of SMd. All such feature The neural network pattern recognition MATLAB ® toolbox is used as classifier. This classifier not only creates a NN but also validates its performance after supervised learning. This classifier is using back propagation algorithm for training of NN. The architecture of employed NN is shown in Fig. 10 in which the input layer is composed of 16 nodes (each receiving one input from the SMI feature vector), the output layer has three elements (each indicating the detected SMI modality, i.e. U (for uni-modal), B (for bi-modal), and T (for tri-modal)) while there is one hidden layer comprising of 18 neurons.

2) Testing of Classification

After the training of NN, it is used to classify the unseen and unlabeled SMI signals into one of three modal classes. The unseen and unlabeled SMI signal is passed through preprocessing stage and features are extracted from it. The feature vector is provided as input to the trained classifier and then it makes the decision about its class with a certain performance, as detailed below.

IV. DISCUSSION

The number of neurons Nhl in the hidden layer of the neural network affects the performance in terms of correct detection of modality of SMI signals. As seen in Table I, if Nhl ≤ 16 then the performance of NN will comparatively decrease as it will not be able to make use of all 16 input features. On the other hand, if Nhl > 18, then comparatively poorer performance is attained due to data over-fitting problem. So, for the proposed scheme, best SM modality classification accuracy of 98.57% was obtained when 18 hidden neurons are used inside the NN.

It is also seen in Table I that the NN is able to successfully detect all unseen uni-modal SM signals. Such a result is to be expected given the observation that uni-modal SM signals are the least diverse in nature as compared to bi-, or tri-modal SM signals. Performance of the NN in detecting unseen bi-modal signals is also very good due to appropriate choice of features and pre-processing.

Focusing on the incorrect detection by the NN, it can be noted in Fig. 11 that such a tri-modal SM signal is quite difficult to correctly classify due to very small amplitude of the third mode contained in this signal (see very small fringes belonging to the third mode (encircled in red) at around -1.3 V in Fig. 11). Furthermore, the other two modes of this signal (and their derivative peaks) not only have comparable amplitudes but are also evenly placed in time. This special relationship between the dominant two modes leads to a pattern similar to that of typical uni-modal SMI signals (and the NN mis-classified this signal as a uni-modal signal). This signal thus exemplifies the remaining challenges in achieving 100% multi-modality detection, and is the limiting case of the proposed method.

Previous research on multimodal SMI indicated presence of up to three modes [START_REF] Keeley | Measurement of the emission spectrum of a semiconductor laser using laser-feedback interferometry[END_REF][START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF][START_REF] Tucker | Effect of multiple transverse modes in selfmixing sensors based on vertical-cavity surface-emitting lasers[END_REF][START_REF] Pham | Selfmixing sensing under strong feedback using multimode semiconductor lasers[END_REF]. In case more than 3 modes undergo SMI then the proposed method could be modified to detect additional modes as well. However, the total number of input features to the NN would need to be increased to capture the variations contained in additional mode(s). E.g., if four modes undergo SMI then number of input features would need to be increased from 16 at present to 22.

V. CONCLUSION

Automatic detection and classification of uni-, and multimodal self-mixing interferometric vibration sensor signals has been achieved by using a NN based method. This has been achieved through appropriate feature extraction and training of the NN. This technique has successfully processed various experimentally acquired noisy SMI signals (acquired using two different laser diodes emitting at 637 nm and 650 nm respectively) as a function of their multimodality. The three classes of multimode SMI signals (uni-modal, bi-modal, and tri-modal SMI signal) were classified with 98.57% overall correct recognition, with 100 %, 100%, and 96.15% correct detection of uni-, bi-, and tri-modal SMI signals respectively.

The detection of multimodality of SMI signals is of high significance in order to enable the use of multi-modal SM signals for metric sensing purposes while such an automated detection of SMI multimodality, to the best of our knowledge, has not been achieved before.

This signal processing based automatic identification of change in modality of a laser diode operating under different optical conditions is a significant challenge and has important repercussions on the error performance of the SM sensor. As stated previously, this has not been achieved before, thereby, 1) restricting the use of multimodal lasers (potentially providing higher SM sensing resolution [START_REF] Ruiz-Llata | Self-mixing technique for vibration measurements in a laser diode with multiple modes created by optical feedback[END_REF]) for robust SM sensing set-ups or 2) restricting the use of uni-modal laser diodes having a risk of switching to multimode operation under SM e.g. due to change in operating conditions. The number of laser modes of a unimodal or multi-modal laser can vary due to operating conditions [START_REF] Tucker | Effect of multiple transverse modes in selfmixing sensors based on vertical-cavity surface-emitting lasers[END_REF][START_REF] Pham | Selfmixing sensing under strong feedback using multimode semiconductor lasers[END_REF]. Therefore, previously, it has been difficult (without adding bulky and expensive optical spectroscopic instruments into optical path thus destroying the simplicity of SM sensing set-up) to ascertain as to how many modes are lasing under SM conditions. As each mode would engender its own set of interferometric fringes, therefore, an unidentified change in modality of SM sensor can greatly affect the total fringe count thus greatly undermining the SM sensor performance as each interferometric fringe is usually assumed to identify λ/2 displacement under uni-modal SM sensing. The proposed NN based identification of multi-modality can thus potentially pave the way for the increased use of multi-modal SM sensors under varying operating and optical feedback conditions.

Likewise, the automatic modality detection enabled by the designed NN can also be used in a feedback loop (involving LD current control [START_REF] Pham | Selfmixing sensing under strong feedback using multimode semiconductor lasers[END_REF] and/or the focusing lens' electronic control [START_REF] Bernal | Robust method of stabilization of optical feedback regime by using adaptive optics for a self-mixing micro-interferometer laser displacement sensor[END_REF]) so that the SMI sensor could be stabilized to operate with a specific uni-/multi-modal behaviour.

Future work would focus on improved detection performance by using additional features of multi-modal SM signals while real-time implementation involving active feedback loop would also be considered. More SM signals belonging to diverse laser sources and optical conditions can also be added to form a bigger data bank to improve the reliability of NN based modality detection over time.

Fig. 1 .

 1 Fig. 1. Schematic diagram of SMI sensing set-up based on a laser diode package including the built-in monitor photodiode. Remote vibrating target causes variation in optical output power P(t) which is detected by the monitor photodiode and amplified by a trans-impedance amplifier (TIA).

©

  2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works DOI: 10.1109/JSEN.2018.2869771 3 B. Experimental Set-up The basic SM interferometer was implemented by using the experimental set up shown in Fig. 2. The vibrating target was a polished metallic ring mounted on a mechanical shaker (model SF-9324 by PASCO having operating frequency range of about 0.1Hz to 5 kHz). The function generator (model AFG-2225 by GW Instek) provided sinusoidal input vibration of 100 Hz frequency to the wave driver. The digital oscilloscope (model GDS-2204E by GW Instek) was used to observe and to acquire the SMI signals.

Fig. 3 .

 3 Fig. 3. Experimentally acquired SMI signals using L637P5 laser diode with operating current of 23mA. (a) driving voltage provided to the vibrating mechanical shaker acting as target, (b) mono-modal SMI signal, (c) bi-modal SMI signal, and (d) tri-modal SMI signal. Note the characteristic sub-periodicity in SMI fringes indicative of multi-modality.

Fig. 4 .

 4 Fig. 4. Experimentally acquired SMI signals using HL6501MG laser diode with operating current of 78mA. (a) driving voltage provided to the vibrating mechanical shaker acting as target, (b) mono-modal SMI signal, (c) bi-modal SMI signal, and (d) tri-modal SMI signal.

Fig. 2 .

 2 Fig. 2. (a) Experimental set-up for acquiring uni-and multi-modal selfmixing interferometric signals using two different laser diodes, (b) closeup.

  " A variety of SMI signals were thus observed and acquired under different optical feedback and Lext conditions. Weak feedback regime signals are identified by quasi-sinusoidal fringes devoid of discontinuity (e.g. see Fig. 3 (b) and Fig. 4 (b)). Moderate feedback regime signals are characterized by presence of sharp discontinuity at each fringe as well as hysteresis [1,2]. Certain acquired SM signals belong to moderate feedback regime (e.g., see Fig. 3 (c-d). Strong feedback regime SM signals are usually avoided due to fringeloss and chaos [1, 2]. No such signals were observed during signal acquisition for the present work. Having discussed how different mono-and multi-modal SMI signals were experimentally acquired, methodology of their automatic classification and detection is discussed next. III. CLASSIFICATION OF MODALITY Schematic block diagram of the proposed classification and detection of mono-and multi-modal SMI signals for sensing is shown in Fig. 7. It is composed of four sub-blocks: 1) SMI Data-set, 2) Pre-processing, 3) Feature Extraction, and 4) Classification, as detailed below.

Fig. 7 .

 7 Fig. 7. Schematic block diagram of proposed automatic detection method of uni-and multi-modal SMI signals for vibration sensing. Fig. 5. Different tri-modal SMI signals observed using HL6501MG laser diode at different external cavity lengths of approx. (a) 10 cm (b) 13 cm (c) 15 cm respectively.

Fig. 6 .

 6 Fig.6. Magnified portion (0.001s to 0.003s) of Fig.5showing the variation in shape of different tri-modal SMI signals.

Fig. 9 .

 9 Fig. 9. (a) Fringes of a tri-modal SMI signal and corresponding detected peaks indicated by black circles. The time difference (∆t) and amplitude difference (∆P) between consecutive peaks are also indicated. (b) Peaks of corresponding differentiated SMI signal indicated by black circles.

Fig. 8 .

 8 Fig. 8. Preprocessing steps: (a) raw experimentally acquired SMI signal, (b) normalized and low-pass filtered SMI signal, (c) down-sampled SMI signal, and (d) differentiated SMI signal.

  E. ResultsThe performance of proposed NN is quantified by computing its accuracy of classification. Here, accuracy is the ratio of correctly classified SMI signals to total number of SMI signals that are being classified. The results of classification are shown in Table I. The proposed NN was provided 70 unseen SMI signals (composed of 22 uni-modal, 22 bi-modal, and 26 tri-modal SMI signals). The NN has provided best results when 18 neurons are used in the hidden layer. In this case, the classifier performed correct SM modality detection on 69 out of 70 unseen uni-, and multimodal SMI signals with 98.57% overall correct detection accuracy.

Fig. 10 .

 10 Fig. 10. The architecture of neural network employed for the proposed classification of multi-modality in SMI signals for vibration sensing.

Fig. 11 .

 11 Fig. 11. The only incorrectly classified unseen SM signal is a tri-modal SM signal which was classified as a uni-modal SM signal by the NN. Very small SMI fringes of the third mode are encircled in red near -1.3 V.


Mohamed Lamine Kerdoudi
email: l.kerdoudi@univ-biskra.dz

Tewfik Ziadi
email: tewfik.ziadi@lip6.fr

Chouki Tibermacine
email: chouki.tibermacine@lirmm.fr

Salah Sadou
email: salah.sadou@irisa.fr

Recovering Software Architecture Product Lines

A large component and service-based software system exists in different forms, as different variants targeting different business needs and users. This kind of systems is provided as a set of "independent" products and not as a "single whole". Developers use ad hoc mechanisms to manage variability. However, for deriving new product variants that are built upon existing ones, the presence of a single model describing the architecture of the whole system with an explicit specification of commonality and variability is of great interest. Indeed, this enables them to see the invariant part of the whole, on top of which new functionality can be built, in addition to the different options they can use. We investigate in this work the use of software product line reverse engineering approaches, and in particular the framework named But4Reuse, for recovering an architecture model that enables us to build a Software Architecture Product Line (SAPL), from a set of software variants. We propose a generic process for recovering an architecture model of such a product line. We have instantiated this process for the OSGi Java framework and experimented it for building the architecture model of Eclipse IDE SPL. The results of this experimentation showed that this process can effectively reconstruct such an architecture model.

I. INTRODUCTION

Software Product Line (SPL) Engineering (SPLE) considers the existence of a single model describing all the variants that implement each architecture element.

The particularity of this "single" architecture is that it includes what is refereed as a variability model (also called feature model), in which variability and commonality are explicitly specified using high level characteristics of the socalled features [START_REF] Apel | Feature-Oriented Software Product Lines -Concepts and Implementation[END_REF]. These are then mapped to components, which are organized according to the identified features. Product variants can be derived (generated) by choosing the desired features, then SPL tools choose and assemble the appropriate components mapped to the selected features [START_REF] Apel | Feature-Oriented Software Product Lines -Concepts and Implementation[END_REF]. During recent years, multiple approaches have been proposed addressing SPL implementation, or product derivation [START_REF] Apel | Feature-Oriented Software Product Lines -Concepts and Implementation[END_REF], [START_REF] Thüm | FeatureIDE: An extensible framework for feature-oriented software development[END_REF]. However, there are many systems that exist as several "independent" variants and not as a "single whole". Indeed, large component and service-based software systems exist in different forms, as different variants targeting different business needs and users. For example, IDEs like Eclipse, exist as several variants targeting different kinds of software engineers. These systems often use ad hoc mechanisms to manage variability and they do not take complete benefits from the SPLE framework.

For developers of new product variants that are built upon existing ones, the presence of a single model describing the architecture of the whole system with an explicit specification of commonality and variability is of great interest. Indeed, this enables to see the common part of the whole, on top of which new functionality can be built, in addition to the different options they can use.

This paper considers the challenge of analysing the source code of existing variants of component and service-based software systems to reverse-engineer a software architecture following that is common to all the existing variants. We call this constructed architecture Software Architecture Product Line (SAPL) that represents the unique software architecture that supports the software product line and common to all the product variants members of the SPL.

We defend a vision by considering SAPL as a reference architecture starting from which the architecture of each product variant can be derived. Indeed, each derived software variant can have its own life. This life is regulated by evolution needs whose origin often depends on the context which is specific to each product. From the point of view of the responsible on the maintenance of the product, the architecture is a crucial artifact for two reasons: i) understand the product before making the changes, and ii) notify changes made on the product to keep its documentation compliant with its implementation. However, the situation where the product variants do not have any specific architecture raises problems during the maintenance stage of a product on the two points mentioned above: i) referring to a generic architecture to understand a given product is a very difficult task. Knowing that understanding is the most costly activity during maintenance, this will generate considerable additional costs. ii) Modifying a generic architecture, to take into account the modifications made on one of its products, is a task that is not only difficult and error prone, but also with unforeseeable consequences on the other products.

Our vision is that the different products (software) can be created from the same SPL, but must be able to evolve independently and without constraints. So, our approach to solving the two problems mentioned above is that the product line must produce the software architecture of a product, but not directly the corresponding software. This is what we called Software Architecture Product Line (SAPL).

We propose in this paper a process for SAPL-reverseengineering. This process extends the BUT4Reuse framework, which is considered as one of the most effective methods for SPL-reverse-engineering [START_REF] Martinez | Bottom-up adoption of software product lines: a generic and extensible approach[END_REF], [START_REF] Martinez | Bottomup technologies for reuse: automated extractive adoption of software product lines[END_REF]. This framework was proposed as a generic and extensible framework for SPL reverseengineering. We extend BUT4Reuse to SAPL reverse-engineer large component and service-based software systems starting from a collection of their existing variants. The remaining of the paper is organized as follows. In Section II, we expose our SAPL-RE process. In Section III, we present an instantiation of the process for the OSGi component model. We show the results of our experiments in Section IV. We finally discuss the related work in Section V, before concluding the paper in Section VI.

II. A GENERIC PROCESS FOR SAPL-REVERSE ENGINEERING

Before presenting the proposed process for SAPL Reverse Engineering and variant derivation, we first describe the metamodel supported by our approach.

A. SAPL Metamodel for Component-Based Software Variants

Figure 1 depicts the defined SAPL meta-model which is used for creating an architecture for a set of component-based software variants. We have been inspired in the definition of this meta-model by the feature meta-model in [START_REF] Perrouin | Reconciling automation and flexibility in product derivation[END_REF]. We enriched it by adding component-based architecture elements. An instance of this meta-model serves as a feature model that represents the variability in a family of software product variants and a comprehensive architecture (modules / components) that helps the developer to understand the structure of the SPL features and the relations between them.

As our meta-model is used for representing the componentbased systems, it has been defined based on an abstract syntax of a software component model. It is used to represent any kind of component-based system such as OSGI, Spring, etc. A generally accepted view of a software component is that it is a software unit with provided capabilities and a set of requirements. The provided capabilities (ProvidedElement in our meta-model) can be operations performed by the component. The requirements (RequireElement in our metamodel) are needed by the component to produce the provided capabilities.

B. SAPL-RE and Component-based Application derivation process

The goal of the process presented in this paper is to analyze existing product variants to extract a SAPL with an explicit specification of commonality and variability. This architecture can be used to generate new variants using the principles of SPLE. This extraction is one of the most challenging research directions identified in the SPL community. Many SPL extraction approaches have been proposed in the last years. Wesley et al. [START_REF] Assunc | Feature location for software product line migration: a mapping study[END_REF] present a complete survey on these existing works. In this paper, we propose to revisit this problem from the software architecture (SA) perspective.

In this context, we identified five main challenges: 1) How to extract a software architecture from the source code; 2) How to compare the architecture variants to identify the common part and find and name different features; 3) How to construct the SAPL with an explicit specification of the variability at an architectural level; 4) How to simplify and reduce the complexity of the recovered architectures. The extraction should be generic and extensible to support all these different views; 5) Once the SAPL is constructed, one remaining challenge is related to the derivation process. How the SAPL can be used to derive new SA variants?

The overall process of our approach to tackle the identified challenges is illustrated in Figure 2. This process is initially introduced in our previous work [START_REF] Kerdoudi | A bottomup approach for reconstructing software architecture product lines[END_REF], which is substantially extended in this paper with a detailed specification and a validation. It is composed of three main activities: 1) Reverse-Engineering of SA variants; 2) SAPL Reconstruction; and 3) Variants Derivation. In the following, we describe each activity.

1) Reverse-Engineering of SA Variants: The first activity in our approach is to use reverse-engineering techniques to extract a software architecture variant from the source code of each software variant. As we will see in the next section, the reverse-engineering of SAs from eclipse variants is based on the analysis of the configuration files and the source code of the different components (plugins).

2) SAPL Construction: In this activity, the different SA variants are analyzed and compared to identify the common part and the different features. As illustrated in Figure 2, this activity extends the BUT4Reuse framework to support architectural artefacts. Indeed, BUT4Reuse [START_REF] Martinez | Bottom-up adoption of software product lines: a generic and extensible approach[END_REF], [START_REF] Martinez | Bottomup technologies for reuse: automated extractive adoption of software product lines[END_REF] was proposed as a generic and extensible framework to identify features from a set of similar artifacts. It is extensible by enabling to add different concrete techniques or algorithms for the relevant steps of feature identification, mining feature constraints, extracting reusable assets, synthesizing and visualizing feature models.

To support the different types of artifacts, and enabling extensibility, BUT4Reuse relies on adapters for the different artifact types. These adapters are implemented as the main components of the framework. An adapter is responsible for decomposing each artifact type into the constituting elements, and for defining how a set of elements should be constructed to create a reusable asset. Designing an adapter for a given artifact type requires three main tasks:

• Element identification. The first step is to identify the Elements that compose an artifact. This will define the granularity of the elements in a given artifact type. For the same artifact type, we can select from coarse to fine granularity (e.g., package level versus statement level for source code). • Similarity metrics definition. This task defines a similarity metric between any pair of Elements. An element should be able to compare its definition with the one of When the artifact type is structured, the elements will have containment relations. In the case of architecture artifacts, relations between interfaces, components and plugins usually capture this information. In this paper, we extend BUT4Reuse by proposing a new adapter related to software architectures. In addition to allow comparing software architectures, this new adapter is designed with a set of parameters to consider different architectural views (services, interfaces, packages, extensions, etc).

Once the adapter is implemented, SAPL construction follows four sub-activities as illustrated in Figure 2.

a) Decomposition in Architectural Elements: The first step takes as input a collection of architecture variants that are obtained from the reverse-engineering activity. It decomposes each variant into a set of Architectural Elements (AEs). The computed AEs can be of different types depending on the considered view.

b) Block Identification and Feature Naming: This step reuses algorithms implemented in BUT4Reuse which automatically identify sets of AEs that correspond to the distinguishable features from the SA variants. These sets of AEs are named Blocks. In this paper, we reused the algorithm called Interdependent Elements that formalizes block identification using class equivalences. Once blocks are identified, the next step is a semi-automatic process where domain experts manually review the elements from the identified blocks to map them with the functionalities (i.e., features) of the system. BUT4Reuse integrates what is called VariCloud [START_REF] Martinez | Name suggestions during feature identification: The VariClouds approach[END_REF], a tool that analyzes the elements inside each block and extracts words that help domain experts to identify features. VariCloud uses information retrieval techniques, such as TF-IDF (Term Frequency Inverse Document Frequency), to analyze the text describing elements inside blocks. The descriptions used by BUT4Reuse to build word clouds are thus provided by the specific adapter. As we will see in the next section, for our adapter, words correspond to the names of packages, interfaces and plugins.

c) Dependencies Identification: During this step, the approach identifies the dependencies between the different blocks. BUT4Reuse uses the dependencies defined within the adapter to identify dependencies between blocks.

d) Multi-View SAPL Constrcution: A software architecture of a large system is a complex entity; it cannot be presented in a single view. One of the most important concepts associated with software architectures are views. A view is the result of applying a viewpoint to a particular system of interest (for instance, service-, interface-, and extensionoriented views). In this step of our process, we enable the developer to construct a multi-view SAPL. These views can help and assist the developer to understand progressively the SPL.

3) Variants Derivation: In this step, the developer can select starting from the recovered SAPL a set of features that meet her/his requirements for deriving the architecture of the new variant. We provide a graphical tool to visualize the derived architecture. Once the developer analyzed and understood this architecture, she/he can derive the new product as a new variant.

III. INSTANTIATION OF THE PROCESS FOR OSGI COMPONENT/SERVICE MODEL

We have instantiated the previous process for the OSGi Java framework, in order to analyze applications like Eclipse. The OSGi specification defines a component model and a framework for creating highly modular Java systems [START_REF] Mcaffer | OSGi and Equinox: Creating highly modular Java systems[END_REF]. Eclipse-based applications run on top of Equinox which is the reference implementation of the OSGi specification. It is a collection of similar software products that share a set of software assets. It offers a set of "releases" where each one is a large-sized Java application composed of hundreds to thousands of components, registering and consuming hundreds of services. This complex structure requires a considerable effort to understand all dependencies when building a new product. The default Eclipse releases are predefined for targeting specific developer needs. Currently, if a developer wants to create a customized release, she/he has to select one of the default releases1 (for instance, IDE for C/C++ Developers) and then manually install new software which meets her/his requirements. In this paper, we consider Eclipse releases as product variants and we aim to adopt the SAPL approach in order to be able to develop efficiently a personalized Eclipse variant. Before presenting the implementation details, we introduce the OSGi Meta-Model.

A. OSGi Meta-model

Figure 3 presents our metamodel for the OSGi SAPL. It is an adaptation of the meta-model in Figure 1 for the OSGi component model. A component in OSGi is known as a bundle or a plugin (PluginElement in this metamodel) which packages a set of Java types, resources and a manifest file. Plugin dependencies are expressed as manifest headers that declare requirements and capabilities. The "import-package" header is used to express a plugin's dependency upon packages that are exported by other plugins. The "require-bundle" is used when a plugin requires another plugin. The first plugin has access to all the exported packages of the second. The manifest file declares also what are the packages that are externally visible using "export-package" (the remaining packages are all encapsulated). Furthermore, the Java interfaces that are present in the exported and imported packages are considered respectively as the plugin's provided and required interfaces (represented by ProvidedInterfaceElement and RequiredInterfaceElement).

Besides, the OSGi framework introduces a service-oriented programming model which is a publish, find and bind model. The registered services with the OSGi Service Registry are represented by the RegisteredServiceElement, while a consumed service by a plugin is represented by a ConsumedServiceElement.

Services are not the only collaboration way between plugins. Equinox provides a means of facilitating inter-plugin collaboration via Extension Registry. Plugins open themselves for extension or configuration by declaring extension points (ExtensionPointElement in this metamodel) and defining contracts. Other plugins contribute by developing extensions (ExtensionElement in this metamodel) using existing extension points.

Our OSGi meta-model allows to produce several SA views that represent different kinds of plug-in's capabilities and requirements. The supported architecture views in this metamodel are: interface, service, package, and extension views. Of course these views are not orthogonal, there are intersections Fig. 3. An OSGi Meta-Model between each other. But, nobody would be able to understand the whole system by analyzing all the views together. Thanks to this meta-model, developers can progressively understand the system by analyzing each architecture view separately. In addition, our framework can be easily extended to support other views in order to cover all the aspects that the developers need to know when they develop a new variant.

B. Reverse Engineering of the Eclipse Variants

For recovering the SA variants, we analyze the Eclipse artifacts as follows: i) for each variant, we create a compositeElement with the name of the variant. ii) for each plug-in, we create a PluginElement with the plug-in's characteristics. iii) we parse the manifest file of each plug-in to identify the exported and imported package elements. iv) the provided and required interface elements are identified by analyzing the Java source code and Bytecode in the exported and imported package folders. iv) the extension and extension-point elements are identified by parsing the "plugin.xml" files of each plug-in. v) Finally, the programmatically registered and consumed services are identified by parsing the source code and bytecode of each class in the plug-in. We parse here the following statements: <context>.registerService(..) and <context>.getServiceReference(..) to capture the type of classes that are instantiated and registered. In addition, the services that are declared with DS (Declarative Services) framework are identified by parsing the "OSGI-INF/component.xml" files. Before saving the architecture, we create the connectors to link the created elements. At the end, we note that the parsing of the source code and bytecode has been implemented by reusing existing Java tools such as AST-Parser and ObjectWeb-ASM.

C. But4Reuse Adapter for Eclipse-Software Architecture Variants

In this section, we present our adapter for Eclipse-SA variants2 . We have followed the generic activities which are defined in [START_REF] Martinez | Bottomup technologies for reuse: automated extractive adoption of software product lines[END_REF] to implement this adapter : i) Elements identification: to compare and analyze several product variants, But4Reuse divides each variant into a set of elements. Our elements are:

PluginElement, ServiceElement, PackageElement, InterfaceElement, ExtensionElement, and ExtensionPointElement. To identify them, our adapter loads and parses the input Eclipse SA variants and performs a mapping of the elements in the input SAs with these elements.

ii) Similarity strategy: It involves comparing all pairs of elements of the same kind. Two elements are similar if they have the same name and exactly the same sub-elements. For example, i) two plugin elements are similar, if they have the same symbolic names, and their extension elements and interface elements are also similar. ii) Two interface elements are similar, if they have the same qualified names and contain exactly the same operations (method signatures).

iii) Structural dependencies identification: A plugin element structurally depends on its required plugins. These dependencies are identified starting from the different outgoing connectors (service, interface, extension, or package connectors) of this plugin element. iv) Block identification and feature naming: We used the interdependent elements algorithm in the identification process. Once the blocks are identified they have names like block 0, block 1, etc. They are then automatically renamed

D. Multi-views SAPL Construction for Eclipse SA Variants

The generation of the SAPL is implemented as a separate plug-in. This plug-in provides an extension-point for other developers to contribute by developing extensions for generating SAPL for other kinds of component-based software product lines, such as applications built with Java 9+ module system. This plug-in provides an editor that allows to visualize graphically the SAPL as follows. First, the SAPL can be visualized as a compact representation of all the assets of the SAPL in terms of "features". Second, we enable the developer to click twice on a given feature in order to visualize its architecture, which can be opened in another editor. In this way, instead of visualizing the whole SAPL in one screen, we assist the developer to understand features progressively. Figure 4 depicts the generated SAPL starting from three Eclipse variants which are IDE for Java, IDE RCP and RAP, and IDE for Java and Report Developers. The block "eclipse core equinox" is common to the three variants. The edge with a dashed line represents a discovered require dependency.

Besides, Figure 5 shows an excerpt of the architecture of the block "eclipse birt jst". As we can see, the component "BIRT Emitter Conf. Plug-in" provides an extension-point which is extended by several plugins. In this architecture, the set of provided / required elements that are not connected to others components, represent elements that are connected to components located in other features. Our tool enables the developers to merge two or several features in a single architecture to visualize the structural dependencies between them.

E. Architecture and Product Derivation

In order to create a new Eclipse variant, the developer can use the featureIDE tool for configuring manually the SAPL and select a set of desired features among the identified list. Before deriving the variant, we offer to the developer a way for mapping this configuration into an architecture model for this variant. This architecture model represents the structure of selected features and their relationships without variability information, which is useful for the understanding purpose. At the end, the new variant can be derived by collecting the extracted software assets which correspond to the selected features.

IV. EVALUATION OF THE PROCESS

In order to evaluate the performance of our approach, we have conducted a set of experiments on a set of Eclipse releases (product variants). The selected variants are the 12 Eclipse IDE Kepler SR2 releases 3 . The size of these variants varies from 110 to 323 MB and the number of components varies from 213 to 892 components.

In this experiment, we have addressed the following research questions:

• RQ1: What is the performance of our SAPL reverse engineering process? • RQ2: What is the additional cost induced by the proposed Muti-Views SAPL construction? • RQ3: What is the performance of block identification and feature naming? • RQ4: What is the additional cost induced by the variants derivation using our approach?

A. Evaluation Protocol a) : For answering RQ1, we have measured the accuracy of SAPL recovery process and the SA / product derivation. We have followed the following steps:

1) We have used our approach to recover the SAPL from the candidate variants. Next, we have used FeatureIDE Framework4 for configuring a new variant in which we have selected Xtext feature and all the features that are identified from Eclipse Modeling variant. 2) After that, we have used our tool to derive the SA corresponding to this configuration. 3) Without our approach, we installed manually the Xtext in the Eclipse Modeling variant (click on Help->Install Modeling Components->set Xtext...). 4) At the end, we have used the Architecture2Architecture (a2a) [START_REF] Lutellier | Measuring the impact of code dependencies on software architecture recovery techniques[END_REF] metric to measure the architectural change between the derived SA and the SA of the variant that is created manually (in step 3). The architectural change refers to the addition, removal, and modification of components and their elements.

a2a(A i , A j ) = (1 - mto(A i , A j ) aco(A i ) + aco(A j ) * 100% (1)
where, mto(A i , A j ) is the number of operations needed to transform architecture A i into A j and aco(A i ) is the number of operations needed to create architecture A i from a "null" architecture. b) : For answering RQ2, we have used a set of measures for comparing the size and complexity of the recovered SAPL views using our process. c) : For answering RQ3, we have measured the precision and recall on the results of block identification process. Indeed, we have compared the content of each identified block with the content of Eclipse features (obtained from "features" folders of the input variants). The evaluation is performed by comparing the plugins that belong to an identified block with plugins that are present in the "feature.xml" files of the common features folders of the artifacts that contain this block. To evaluate block naming, we have compared our block names with names that are manually given by three domain experts with more than ten years of experience working on Eclipse development (see [START_REF] Martinez | Bottom-up adoption of software product lines: a generic and extensible approach[END_REF]).

d) :

For answering RQ4, we have compared the size and the number of components in "Block 0" (which is considered as the smallest variant that can be derived using our approach) with the size and number of components of the smallest input variant. This allows us to see to what extent is efficient the variant derivation using our approach.

B. Results and Discussion

1) Experiment results for RQ1: : We have used the LoongFMR implementation5 of the a2a metric for comparing the architecture of the variant that is created manually with the architecture that is derived using our approach. The obtained value is a2a = 87%. This value can be considered as a good result that indicates that the two architectures are not identical but almost the same. To understand why there is a little difference between them, we compared the new added (installed) plugins after the manual installation with the plugins in the architecture of the identified feature "eclipse xtext" using our approach. We observed that 56 new plugins (without counting plugins containing source code) are added to the variant after the manual installation of Xtext feature, but in the architecture of the identified feature ("eclipse xtext") using our approach, we only found 43 plugins. In fact, all these 43 plugins belong to the manually added plugins. By analyzing the remaining 13 plugins, either they represent plugins with older versions which already exist in the default variant, or they already exist but they are located in another identified feature where they must belong (for example, the plugin "com.google.guava" is located in the feature "google common collect"). This makes our variant more consistent than the variant that is created manually.

In addition, we have compared the size of the two variants in order to confirm that the derived variant using our approach corresponds to the variant that is created manually. Indeed, the size of the Eclipse variant that is created manually is 256 MB, while the derived variant has a size of 268 MB. This minor difference in size is due to the fact that in the derived variant there are some plugins (such as ch.qos.logback.slf4j) that have been added for meeting the constraints that are discovered using But4Reuse. Examples of these constraints include: "eclipse ecore implies eclipse Maven apache" and "Maven apache implies logback qos", where the feature "eclipse ecore" is required for installing Xtext.

2) Experiment results for RQ2: In Table I the recovered SAPL views are compared in size with the whole SAPL (all views together). First, we can see that the number of elements (per block or per artifact) in each SAPL view is much less than the number of elements in the whole SAPL. This confirms our intuition that focusing on a single view allows to reduce the size and complexity of the SAPL. We can remark also that the number of elements in the extension view is less than the number of elements in the other views. This supports our idea that the developer needs to start with an architecture view that contains a few elements (only the plugins and their extensions). After that, (s)he can pass to another view with more information about other kinds of dependencies.

3) Experiment results for RQ3: We have found 971 "features" folders in all the chosen variants which is larger than the number of identified blocks. This is due to the fact that in our adapter, several features are merged into a single block. We depicted in Table II the obtained values of precision and recall. As we can see, we have obtained good values of recall and precision for Block 0. This means that, our tool can create an operational and minimal variant with an error rate almost equal to zero.

For the other blocks, we also obtained quite good scores, especially when we recover the SAPL with the Interface view. We can observe that the median scores are quite low compared to the Block 0 scores, but, they are relatively good which illustrates the effectiveness of our approach. This decrease compared to Block 0 is explained by the fact that there are some blocks which contain a few number of plugins (sometimes one or two plugins), and they are not present in the corresponding Eclipse features. Hence, we obtained low scores of precision and recall which decreases the median scores. But, we can observe from the scores that the number of these blocks is very low.

Besides, we present in Figure 6 the 62 identified blocks (for the interface view). The common part between all the variants (in blue color) represents the "Block 0" that is named "eclipse core equinox". This represents the core components that must exist in each variant. We note that all block names in this figure are assigned automatically. When comparing them with names given by the experts, more than 70% of names are the same, thanks to the word cloud that is used to name these blocks starting from words that are extracted from the elements names.

4) Experiment results for RQ4: After applying our SAPL reverse engineering process on the input variants, we have derived a new variant with only the "Block 0". We have found that the size and the number of components in this block is respectively 62.6 MB and 193 components. This is much less than the size and the number of components of the smallest input variant (IDE for Testers with 110 MB). This means that the minimalistic Eclipse variant (that contains the required minimum) that can be derived starting from the input variants can have only this size. This demonstrates the efficiency of our process. Instead of installing a default variant, we can configure an architecture, optimized according to developer requirements, and voluntarily minimalistic.

V. RELATED WORK Wesley et al. [START_REF] Assunc | Feature location for software product line migration: a mapping study[END_REF] presented a complete survey on the existing SPLE approaches. Three ways for adopting SPLE are exposed: (i) from scratch, by applying a complete domain analysis and variability management before application engineering (ii) by creating and updating the SPL when every new product appears; and (iii) by using an extractive approach, which takes existing products as the basis for the core assets. But4Reuse is a framework for extractive SPL adoption. Several extensions of BUT4Reuse have already been developed and published in [START_REF] Martinez | Automating the extraction of model-based software product lines from model variants (T)[END_REF], [START_REF] Li | Mining families of Android applications for extractive SPL adoption[END_REF], [START_REF] Ziadi | Software product line extraction from bytecode based applications[END_REF]. Martinez et al. [START_REF] Martinez | Automating the extraction of model-based software product lines from model variants (T)[END_REF] proposed an approach for automating the extraction of model-based SPL from model variants as follows. First, they identify features and detect constraints among them. After that, the model variants are refactored to conform to an SPL approach. [START_REF] Ziadi | Software product line extraction from bytecode based applications[END_REF] proposed a SPL extraction approach from Bytecode based applications.

Besides, software architecture recovery (SAR) is a challenging problem, and several works in the literature have already proposed contributions to solve it (e.g., works cited in [START_REF] Ducasse | Software architecture reconstruction: A process-oriented taxonomy[END_REF], [START_REF] Lutellier | Measuring the impact of code dependencies on software architecture recovery techniques[END_REF], [START_REF] Maqbool | Hierarchical clustering for software architecture recovery[END_REF]). Most of these approaches are proposed for a single software architecture recovery. Lutellier et al. [START_REF] Lutellier | Measuring the impact of code dependencies on software architecture recovery techniques[END_REF] present a comparative analysis of six SAR techniques. Maqbool et al. [START_REF] Maqbool | Hierarchical clustering for software architecture recovery[END_REF] presented a review of the hierarchical clustering techniques. In the last decade several works had proposed approaches that aim to recover component-/serviceoriented architectures from existing systems. For example, the works in [START_REF] Chardigny | Extraction of component-based architecture from object-oriented systems[END_REF] and [START_REF] Seriai | Enactment of components extracted from an object-oriented application[END_REF] are based on the definition of a correspondence model between the code elements and the architectural concepts. In [START_REF] Allier | Restructuring object-oriented applications into component-oriented applications by using consistency with execution traces[END_REF], [START_REF] Allier | From objectoriented applications to component-oriented applications via componentoriented architecture[END_REF] a component is considered as a group of classes collaborating to provide a system function. Seriai et al. in [START_REF] Seriai | Deriving component interfaces after a restructuring of a legacy system[END_REF] used FCA to perform the component interface identification. The authors in [START_REF] Kerdoudi | Opening web applications for third-party development: a service-oriented solution[END_REF] recover BPMN models starting from service oriented systems that have been generated from web applications. Some works have been proposed to recover software architecture at run-time. For instance, [START_REF] Huang | Runtime recovery and manipulation of software architecture of component-based systems[END_REF] presented an approach for recovering at runtime software architectures from component based systems and changing the system via manipulating the recovered SA. The authors in [START_REF] Kerdoudi | Spotlighting use case specific architectures[END_REF] have proposed an approach to recover at run-time architectures of a large-sized component/service oriented systems by considering some specific use cases in order to reduce the size of the recovered architectures.

In our approach, we assume that the SAs of the product variants can already exist and considered as inputs for our Besides, few works were proposed in the literature that aim to recover SPLA. [START_REF] Sinkala | A mapping study of software architecture recovery for software product lines[END_REF] presented a mapping study of the existing SPLA recovery approaches. Shatnawi et al. [START_REF] Shatnawi | Recovering software product line architecture of a family of object-oriented product variants[END_REF] have proposed a process for recovering software product line architectures of a family of object-oriented product variants. First, they used FCA to migrate the object-oriented systems to a set of component variants. Each variant is a set of similar components that share the majority of their classes and dependencies. Second, they used FCA to identify mandatory and optional components. At the end, they build the SPLA as a feature model where the dependencies between component variants are based on relations of type alternative, OR, AND, require and exclude. The authors in [START_REF] Eyal-Salman | Toward recovering component-based software product line architecture from object-oriented product variants[END_REF] have proposed an approach for recovering SPLA from software product variants.

They identify mandatory components and variation points of components as a main step. They analyze commonality and variability across product variants in terms of features.

Compared to our work, the recovered SAPL using our approach is both a feature model and a complete architecture that shows all the architectural connections between components. In addition, our inputs can be system variants or SA variants. The variability is identified starting from the elements in the input architectures. Wille et al. [START_REF] Wille | Variability mining of technical architectures[END_REF] have proposed a variability mining approach for Technical Architecture (TA) variants. They eliminate the unnecessary information from the input TAs. The components from the TAs are clustered by filtering them based on their structural relations to eliminate unrealistic variability. Unfortunately, their approach can not recover an architecture describing all the variants. On the other hand, our solution can derive new SAs and product variants starting form the reconstructed SAPL. The proposed process is generic and can be applied for many component based-systems (orsoftware architectures).

VI. CONCLUSION

Recovering architecture models of large-sized software products is an important activity in software maintenance and evolution. These architecture models offer a good documentation to understand the software product before changing it. For large software products with several product variants, these models become of greater interest since they enable also to choose the most appropriate variant. SPL Reverse Engineering (SPL-RE) processes enable to recover models with a better structure, since they factorize the variable part in the product variants and enable to see the variability points.

In our work we focused on component-and service-based systems and proposed in this paper: i) a (meta-)model for architectures of component/service-based software product lines, ii) the design of an adapter of a generic SPL-RE process (But4Reuse) for building architecture models (SAPL models) by analyzing product variants, iii) an implementation of this adapter specific to OSGi-based applications, and iv) an experimentation of this recovery process on a set of Eclipse releases. The experimentation that we conducted enabled us to evaluate the efficiency of the process in identifying correct features, compared to those identified/built by experts. In addition, it enabled us to measure the accuracy of architectures of products derived from the recovered SAPL.

As perspectives to this work, we plan to study the enrichment of SPL reverse engineering of large component/servicebased systems by including a learning module which exploits existing SPLs and their variants/features. In addition, we envisage the instantiation of the process for other component/service frameworks, or just investigate its use with Java modules for exploring variability in Java SE, EE, ME, TV, etc. From a tool-support point of view, we intend to enrich our implementation by capabilities such as software product configuration and derivation to complete the "loop".

Fig. 1 .

 1 Fig. 1. SAPL Metamodel for Component-Based Software Variants

Fig. 2 .

 2 Fig. 2. Proposed SAPL-Reverse Engineering Process

Fig. 4 .

 4 Fig. 4. Example of SAPL for three Eclipse Variants

Fig. 5 .

 5 Fig. 5. Excerpt of the SA of "eclipse birt jst" Block (Extension and Package view)

Fig. 6 .

 6 Fig. 6. Blocks per Variant: Interface View

TABLE I VALUES

 I OF SIZE FOR THE RECOVERED SAPL VIEWS vs WHOLE SAPL

	SAPL	# of Blocks	Mean of Elem. per Artifact	Median of Elem. per Artifact	Mean of Elem. per Block	Median of Elem. per Block
	Extension	67		3144	2848			51		7
	Package	67		7942	7557			208		30
	Service	61	54861	12174			29		8
	Interface	62		8492	7896			376		57
	Whole SAPL	77	74439	30475			664		102
					TABLE II
	PRECISION AND RECALL CALCULATION FOR THE BLOCK IDENTIFICATION STEP
		Extension View	Package View	Service View		Interface View
		Precision	Recall	Precision	Recall	Precision	Recall	Precision	Recall
	Block 0	0.99	0.83	0.99	0.83	0.99		0.83		0.99	0.83
	Median	0.76	0.68	0.76	0.68	0.91		0.75		0.94	0.69

In https://www.eclipse.org/downloads/packages/release

For more details see: http://tiny.cc/wuwv7y

Downloaded from: https://bit.ly/2uylkT8

FeatureIDE Framework: http://www.featureide.com/

Downloded from: https://github.com/csytang/LoongFMR

ACKNOWLEDGEMENT

The work of Tewfik Ziadi was supported by the ITEA3 15010 REVaMP2 project: FUI the Ile-de-France region and BPI in France.