Hamid Sediki

Ali Bechouche

Djaffar Ould Abdeslam
email: djaffar.ould-abdeslam@uha.fr

Salah Haddad

ADALINE approach for induction motor mechanical parameters identification

Keywords: Adaptive linear neuron, Artificial neural networks, Field oriented control, Induction motor, Parameters identification

Two new methods to identify the mechanical parameters in induction motor based field oriented drives are presented in this paper. The identified parameters are: the moment of inertia and the viscous damping coefficient. The proposed methods are based on the adaptive linear neuron (ADALINE) networks. The two parameters are derived and optimised during the online training process. During the identification phase, the motor torque is controlled by the well-known field oriented control strategy. This torque is subjected to variations in order to obtain mechanical speed transients. The two proposed methods are simple to implement compared to the previous techniques. They require only the stator current and mechanical speed measurements. Finally, the effectiveness of the two methods and the accuracy of the derived parameters are proven experimentally by two direct starting tests. The originality of this work is the building of a model representation that it is suitable for implementation with ADALINE networks. This leads to a simple implementation and ease of mechanical parameters identification.

Introduction

To achieve high dynamic performance of induction motor (IM) speed control, knowledge of electric parameters is not sufficient. The mechanical parameters such as the moment of inertia and the viscous damping coefficient are needed and very important to design controllers and/or states observers. Therefore, it is essential to develop algorithms for IM mechanical parameters identification.

There are many proposed techniques that identify the motor parameters off-line. However, when these parameters are subject to variations, the motor control performances are deteriorated and the system becomes detuned. It is therefore suitable to track these changes online in order to ensure optimal controller tuning at any time. To identify the moment of inertia J, conventional methods can be used. They are based on direct and indirect techniques. The direct techniques consist of extracting the rotor and performing measurements which require other devices and not always adaptable for all electric motors. For indirect techniques, the slowdown method can be mentioned. This method requires that the turning system "shaft-end" should be accessible. Measurement is carried out by adding a known inertia wheel J 0 to the motor shaft. The slowdown curves both with and without the added inertia permit the deduction of the inertia moment J. The viscous damping coefficient f can be estimated in steady state by measuring the power consumption at a given speed in no-load test. The use of conventional techniques in industrial environments for determining the mechanical parameters can be an arduous and complicated task. Moreover, these techniques are not able to track changes in the system parameters.

In recent years, several estimation strategies have been developed for mechanical parameters identification in field oriented controller drives. The advantage of the field oriented control (FOC) drives is the possibility to obtain the knowledge of the motor torque since the stator currents and the rotor flux are known [START_REF] Robyns | Fuzzy logic based field orientation in an indirect FOC strategy of an induction actuator[END_REF]. In these conditions, many techniques are developed. The methods based on the least mean squares (LMS) algorithms and recursive least squares algorithms used for online identification [START_REF] Telford | Online identification of induction machine electrical parameters for vector control loop tuning[END_REF] can be mentioned. The main limitation of these methods is due to its noise sensitivity. In several papers, observer's techniques have been attempted [START_REF] Choi | Inertia identification algorithm for high-performance speed control of electric motors[END_REF][START_REF] Laroche | Methodological insights for online estimation of induction motor parameters[END_REF]. In [START_REF] Choi | Inertia identification algorithm for high-performance speed control of electric motors[END_REF], an algorithm is proposed for identifying the moment of inertia by observing the position error signal generated by a speed observer which contains error information on the moment of inertia. A reduced-order extended Luenberger observer is also proposed to estimate the motor inertia value [START_REF] Lee | Improvement of low speed operation of electric machine with an inertia identification using ROELO[END_REF]. However, these methods require that some conditions such as observability must be checked and need a long computing-time at the implementation.

Recently, heuristic approaches for IM parameters identification are proposed and have provided efficient results. An off-line method based on the genetic algorithm is proposed to estimate mechanical and electrical parameters. Particle swarm optimisation algorithms are also attempted in order to identify the IM parameters. However, the most known and used heuristic method is that based on artificial neural networks (ANNs) [START_REF] Wlas | Neural-network-based parameter estimations of induction motors[END_REF]. For a few years, these techniques have been proposed and developed as an alternative to conventional methods for modern control challenges [START_REF] Kruger | Stochastic and neural models of an induction motor[END_REF][START_REF] Oguz | Speed estimation of vector controlled squirrel cage asynchronous motor with artificial neural networks[END_REF][START_REF] Pryymak | Neural network flux optimization using a model of losses in induction motor drives[END_REF]. Latest papers demonstrate the ANN effectiveness in the state variable estimation and the IM parameters identification [START_REF] Bechouche | A novel method for identifying parameters of induction motors at standstill using ADALINE[END_REF][START_REF] Geodtel | Load torque identification in induction motor using neural networks techniques[END_REF][START_REF] Wlas | Neural-network-based parameter estimations of induction motors[END_REF]. Among the ANN techniques, the most attractive for linear system identification is that based on single layer called adaptive linear neuron (ADALINE) networks. The main advantages of this technique are its simplicity and the ability to be trained online. In addition, the ADALINE weights can be interpreted physically [START_REF] Bechouche | A novel method for identifying parameters of induction motors at standstill using ADALINE[END_REF][START_REF] Ould Abdeslam | A unified artificial neural network architecture for active power filters[END_REF]. It is thus very efficient for parameters identification of linear systems. In some areas such as adaptive signal processing [START_REF] Jannati | A novel approach to adaptive single phase auto-reclosing scheme for EHV transmission lines[END_REF] or current harmonics identification in power systems [START_REF] Ould Abdeslam | A unified artificial neural network architecture for active power filters[END_REF], the ADALINE has become a powerful tool.

This paper proposes and investigates the use of two new methods for online identification of IM mechanical parameters. These methods are based on the ADALINE and use LMS learning rule to perform the online training. The hardware implementation is very simple and does not require any additional costs other than that commonly used in FOC. The input/output vectors of the ADALINE are the stator current and the mechanical speed, respectively. These input/output vectors can be obtained by using simple sensor devices. The two methods provide the two parameters J and f online. It represents a main advantage when an online tuning controller is required.

The paper is organized as follows. Section 2 gives the IM model and the FOC principle used during the identification process. In section 3, the ADALINE basic concept, the learning process and the identification strategies are given. The obtained experimental results are presented in section 4. Finally, section 5 is devoted to conclusions. Sampling period.

Nomenclature

Induction motor mechanical model under field-oriented control

The main objective of the FOC is, as in DC motors, to independently control the electromagnetic torque and the rotor flux. This is performed by using a d-q rotating frame synchronously with the rotor flux space vector. As shown in Fig. 1, the d axis is aligned with the rotor magnetizing current space vector, which yields I rmq =0 and I rmd =I rm . The rotor magnetizing current I rm is generated by the I sd component. Under steady state conditions, I sd is equal to I rm . The rotor flux angular speed ω s is calculated by adding the rotor electric speed (p.Ω) to the motor slip pulsation ω r . The direct and inverse Park transformations require an input angle θ s obtained by integrating the field pulsation ω s . The slip pulsation is expressed by the rotor time constant T r , the quadratic stator current I sq and the rotor magnetizing current I rm .

If suitable orientation of the stator current and the rotor flux is maintained, the rotor flux and the electromagnetic torque can be controlled independently [START_REF] Robyns | Fuzzy logic based field orientation in an indirect FOC strategy of an induction actuator[END_REF]. The I sd current controls the rotor flux through the direct axis stator voltage V sd and the I sq current controls the electromagnetic torque T em through the quadratic axis stator voltage V sq . This is the key of indirect FOC.

With the FOC implementation, I rm , ω s and T em can be estimated by

with a 1 =1/T r and b 1 =p(1-σ)L s .

The IM control scheme adopted for the mechanical parameters identification is shown in Fig. 1. Two proportional-integral (PI) regulators are used to control the electromagnetic torque T em and the rotor magnetizing current I rmd . In order to reconstitute the voltage vectors V sd and V sq , to be applied to the IM, the decoupling terms E d and E q are added at the output of each regulator. The functional diagram of the mechanical system is shown in Fig. 2. This model is described by the following differential equation:

( ) // em l d dt T T J Ω= - (4) with:
() Under some assumptions like T d =0 and Γ s =0, the relationship between the rotor speed and the electromagnetic torque is given by the following transfer function:

l sd T f sign T = Ω+ Ω Γ + (5)
1 em m K Ts τ Ω = + (6)
Where: K=1/f and τ m =J/f. Though the IM dynamic behaviour is the same of the DC motor, the IM control performance is still significantly influenced by the system uncertainties including mechanical parameters. To improve the process control, the constants K and τ m must be known accurately. Thereafter, the mathematical model given by (6) will be used to determinate the parameters K and τ m .

ADALINE principles

ADALINE architecture

The ADALINE neural network is well-known in the ANNs architecture. It has been applied successfully in many power applications, including current harmonics estimation [START_REF] Ould Abdeslam | A unified artificial neural network architecture for active power filters[END_REF], voltage and current components extraction of an unbalanced three-phase Decoupling system [START_REF] Flieller | Distortions identification and compensation based on artificial neural networks using symmetrical components of the voltages and the currents[END_REF], power quality disturbances detection [START_REF] Ai | ADALINE and its application in power quality disturbances detection and frequency tracking[END_REF], IM electric parameters identification [START_REF] Bechouche | A novel method for identifying parameters of induction motors at standstill using ADALINE[END_REF][START_REF] Karanayil | Online stator and rotor resistance estimation scheme using artificial neural networks for vector controlled speed sensor-less induction motor drive[END_REF], and feature of control [START_REF] Wai | Intelligent control of induction servo motor drive via wavelet neural network[END_REF]. As shown in Fig. 3, the ADALINE is equivalent to one neuron which is composed of an input vector X k , a weights matrix W k , and an activation function f(v). The weights vector W k =[w 0k w 1k … w nk ] T corresponds to the whole neuron synaptic forces. The input vector X k =[1 x 1k …

x nk ] corresponds to the whole neuron input stimulus. The activation function f(v) specifies the neuron behaviour. Various activation functions can be used in the ANN theory. However, the ADALINE uses the linear activation function f(v)=v. Consequently, the ADALINE output y k is given by: y k =X k W k . When the ADALINE is excited, it produces the output y k which depends on the input vector. The weights vector W k is continuously modified during the network learning process with the purpose of approaching as close as possible the desired output d k .

ADALINE training

In the ADALINE theory, the most known training process is that called μ-LMS algorithm [START_REF] Wang | LMS learning algorithms: misconceptions and new results on convergence[END_REF][START_REF] Widrow | Statistical efficiency of adaptive algorithms[END_REF][START_REF] Widrow | 30 years of adaptive neural networks: perceptron, madaline, and backpropagation[END_REF]. The weight vector is updated after the presentation of each input sample. The μ-LMS algorithm is performed by using the steepest-descent gradient. It starts with an arbitrary initial value W 0 for the system's weight vector. The instantaneous gradient k ∇ upon the square of the instantaneous linear error is measured and the weight vector is altered in the direction corresponding to the measured negative gradient. The procedure is repeated, causing the mean square error to be successively reduced on average and causing the weight vector to approach a locally optimal value. The method of steepest descent can be described by the following expression:

2 1 () k k k kk k e WW W W µµ + ∂ = + -∇ = -∂ (7)
where μ is a parameter that controls stability and convergence rate, and k ∇ is the instantaneous gradient value at W=W k .

The ADALINE uses a supervised learning, so a desired output d k is provided with each input X k during the training phase. The error information is

T kkkk k k e d y d XW =-=- (8)
Performing the differentiation in [START_REF] Karanayil | Online stator and rotor resistance estimation scheme using artificial neural networks for vector controlled speed sensor-less induction motor drive[END_REF] and replacing the linear error given by ( 8), we can write

y est (k) - e(k) 1 x 1 (k) x 2 (k) x n (k) w 0 (k) w 1 (k) w 2 (k) w n (k) Σ W(k) X(k) v f(v)

Learning rate

The learning constant μ determines stability and convergence rate. For time independent input patterns, the weight vector mean and variance convergence is ensured for most practical purposes if 0<µ<1/trace[R] (12) Where trace[R]=Σ (diagona1 elements of R) and R is the input correlation matrix defined in ensemble average terms: R= E(X.X T ).

The learning rate μ is an important parameter. The choice of a small value for μ leads to a better network stability but the weights convergence can become very slow. Therefore, to accelerate the weights convergence and to refine the results, μ must be variable during the training process. Its value will be selected relatively high at the beginning, and will decrease significantly and have a small value at the end. The expression of μ can be selected by the following equation:

( ) max / t t if i µ µµ µ = (13
) μ i and μ f are respectively the initial and the final values of the learning rate. t max is the maximal training time.

Identification strategies based on ADALINE

The theoretical basis of this identification strategy is to find and to exploit the linear relationship existing between the weights and the mechanical parameters. If the weights adjustment gives the error between the actual and the estimated rotor speed to the minimum value, then the mechanical parameters are well known.

Mechanical equation based method

This method can be implemented with any form of torque command T em_ref and the resulted speed Ω. To have a valid viscous damping coefficient in a wide speed range, it is preferable to apply alternate torques which lead to positive and negative speeds close to the nominal value.

Let us consider the mechanical equation ( 6) written in the recursive form

( ) ( ) ( ) 00 -1 -1 em k k B k AT Ω= Ω + (14)
The coefficients B 0 and A 0 are equivalent to the ADALINE weights, w 1 and w 2 respectively, as represented in Fig. 4. They are given by the following expressions:

Once the optimal weights w 1 and w 2 are correctly known during the training process, they can be used to calculate the parameters f and J by inversion of [START_REF] Telford | Online identification of induction machine electrical parameters for vector control loop tuning[END_REF]. Their expressions will be as follows:

( )

1 2 1 1- 1/ -/ ln me w fK w J f fT w τ  = =    = =  (16)
The implementation block diagram of this method is shown in Fig. 4.

Encoder

Eq. ( 16)

f J isb isc 4.

Harmonic speed response based method

This method can be applied only if the imposed torque command T em_ref has a sinusoidal form. Theoretically, with this form of torque, the motor speed response would be also sinusoidal. The use of an ADALINE with two sinusoidal terms (sinωt and cosωt) as inputs is suggested (Fig. 5). The ADALINE weights w 1 and w 2 will be adjusted during the training process to approach the measured mechanical speed. Once the weights converge towards fixed and optimal values, it is easy to derive the required mechanical parameters f and J.

Let us give the mathematical formulation of this method. If the reference torque is defined as

_ max sin em ref em TT t ω = ( 17
)
and if the IM mechanical model is accurately given by ( 6), then, in steady state operating conditions the obtained speed response will be written as follows: max ( ) sin( )

tt ωφ Ω= Ω + ( 18
)
The constants max Ω and φ are given by 22 max max 22 1

arctan em m m KT τω φ τω  Ω= +   = -  (19)
The speed response given by ( 18) can be subdivided into two terms in the following way:

Where:

1 max

1 max cos sin A B φ φ = Ω   = Ω 
The two terms sinɷt and cosɷt will be considered as ADALINE inputs. As shown in Fig. 5, the constant terms A 1 and B 1 coincide with ADALINE weights w 1 and w 2 respectively. Once the weights are known, it is easy to reconstitute the mechanical parameters in the following way: τ ω

 = =  +    = = -   (23)
The implementation principle diagram of this method is explained in Fig. 5.

Experimental results

The identified system is a squirrel cage IM. The electric parameters R s , L s , σ and T r have been successfully identified by using ADALINE strategies [START_REF] Bechouche | A novel method for identifying parameters of induction motors at standstill using ADALINE[END_REF]. The IM characteristics are given in Table 1. The IM is supplied by a voltage-source IGBT inverter. The FOC strategy, the Pulse Width Modulation (PWM) signals generation and the signals conditioning are carried out numerically via a dSPACE board based on a TMS320C31 floating point DSP. The control and the identification algorithms are implemented in MATLAB-Simulink using Runge-Kutta resolution method. The real-time interface is used to build real-time code (C language) and execute it on dSPACE hardware. The mechanical speed is measured by an incremental encoder with a global resolution of 2.10 4 point/round. The stator phase currents are measured by Hall Effect transducers. All the signals can be visualized and recorded on a computer via the ControlDesk visualization software. A view of the test bench is given in Fig. 6. To obtain an accurate identification and a fast convergence of the used methods, some adjustments were carried out. The identification signals must contain the least amount of noise possible. Therefore, the mechanical speed signal, delivered by the incremental encoder, is filtered by a first order low-pass filter. The actual torque is substituted by the torque reference. This approximation is justified since the identification signals are relatively slow compared to the torque regulator response time. The identification was carried out with a sinusoidal torque reference. Its magnitude is 2.25 Nm and the pulsation is set to 0.6rad/s. The

Table 1 Induction motor characteristics

Encoder

Eq. ( 23)

f J isb isc sinωt cosωt
motor rotation speed reaches 90 rad/s. The maximal and minimal values of the learning rates, ensuring an optimal speed convergence, are experimentally adjusted respectively to η max =4.10 -5 and η min =10 -7 . The sampling period used in the identification process is T e =0.5ms. Fig. 7 shows the identification signals waveform; the torque reference and the measured speed. It can be noted that the resulted speed waveform is not completely sinusoidal, especially with the zero crossing. That is explained by the viscous damping coefficient f which is not constant but depends on the mechanical speed. Indeed, f is very high at low speeds and becomes small when the IM operates at high speeds.

Mechanical speed equation based method

Fig. 8(a) shows the ADALINE weights evolution w 1 and w 2 . After the transient state, the weights are stabilized at the values: w 1 =0.9998 and w 2 =0.0133. As shown in Fig. 8(b), the residual error is very low, which is what justifies the good performance of the ADALINE network. Fig. 9 shows the identified parameters. In the steady state, the identified values are: J=0.037 kg.m 2 (Fig. 9(b)) and f=0.012 N.m.s/rad (Fig. 9(a)). The fluctuating value of f is explained by the fact that the viscous dumping coefficient is not constant. The obtained value of f is only an average in this speed range.

Harmonic speed response based method

Fig. 10 shows the ADALINE weights evolution and the error between the actual and estimated speed. In Fig. 10(a), the weights w 1 and w 2 are stabilized at 37.2 and -78.1 respectively. The error, as shown in Fig. 10(b), still relatively significant compared to that obtained using the first method. This is due to the presence of arctan function in [START_REF] Widrow | 30 years of adaptive neural networks: perceptron, madaline, and backpropagation[END_REF] which is very sensitive to the weight variations. In Fig. 11, the convergence of the parameters J and f is shown. In the steady state, the two parameters are: J=0.0394 kg.m 2 and f=0.0123 N.m.s/rad. As shown in Fig. 11(a), the viscous damping coefficient f seems better identified than in the first method. A significant improvement in precision is obtained. The application of this method consists to filter the speed signal and to extract the fundamental component. It results in a constant value of J and f.

Validation tests

To check the accuracy of the identified parameters related to the two proposed methods; two direct starting tests of the IM are carried out. The mechanical speed and the stator phase current are recorded during the transient and steady state. To avoid current peaks during the starting phase, the IM is fed by a reduced voltage via a voltage-source IGBT inverter. The maximum of the voltage is about 100V and the frequency is set to 30Hz. Two tests are carried out in simulation with the identified parameters and under the same conditions. In order to perform a comparison; the experimental measurements and the computed curves of the identified parameters are superimposed on the same graph. Fig. 12 and Fig. 13 give the validation results of the identified parameters using the two proposed methods. These parameters are summarized in Table 2.

Incontestably, the identified parameters seem to be identified accurate since the theoretical curves coincide perfectly with those obtained by experiment. In both cases, the transient state duration is 0.2s and the maximal current reaches 20A at the beginning, then, it's equal to 3A in the steady state. Nevertheless, a light shift between the simulation and the experiment curves appears at the transient period. It is due to the viscous damping coefficient which constitutes only an average value on the considered speed range.

Conclusion

This work demonstrates the effectiveness application of the ADALINE for mechanical parameters identification in vector controlled IM drives. Two online techniques are presented to identify the moment of inertia and the viscous damping coefficient. These methods, based on a single neuron, are very simple to implement. They require the knowledge of the phase currents, the mechanical speed, and a FOC. The first method, more general, exploits recursive form of the mechanical equation. The second one is applied in case of a sinusoidal form of the torque reference. The suggested methods feasibility has been checked by experiments and the identified parameters accuracy has been tested by comparing the experimental results, as well as those obtained from simulations. Nevertheless, for the viscous damping coefficient, and regarding its disparate value, the second method is more accurate. A possible direction for future work, for the purpose of refining the identification, could be the introduction of a coulomb friction into the torque loss.

Fig. 1 .

 1 Fig. 1. IM control scheme used in the identification process.

Fig. 2 .

 2 Fig. 2. Functional diagram of the mechanical system.

Fig. 3 .

 3 Fig. 3. ADALINE topology.

  X k are independent of W k , that leading to

Fig. 4 .

 4 Fig. 4. Overall structure of ADALINE identifier for mechanical equation based method.

  the system (22) permits to derive the mechanical parameters

Fig. 5 .

 5 Fig. 5. Overall structure of ADALINE identifier for harmonic speed response based method.

Fig. 6 .

 6 Fig. 6. View of the test bench.

Fig. 7 .

 7 Fig. 7. Identification signals: torque reference and rotor speed.

Fig. 8 . 2 )Fig. 9 .

 829 Fig. 8. Evolution of the weights (a) and prediction error (b).

Fig. 10 . 2 )Fig. 11 .

 10211 Fig. 10. Evolution of the weights (a) and the prediction error (b).

Fig. 12 .

 12 Fig. 12. Validation test (Mechanical speed equation based method).

Fig. 13 .

 13 Fig. 13. Validation test (Harmonic speed response based method).

Table 2

 2 Values of the Identified Parameters J (kg.m 2 ) f (N.m.s/rad)

	Mechanical speed equation based method				0.037	0.012
	Harmonic speed response based method				0.039	0.0123
	0 0	0.1	0.2	0.3	0.4	0.5	0.6


Li Li

Alexandre Bartel

Jacques Klein

Yves Le Traon

Steven Arzt

Siegfried Rasthofer

Eric Bodden

E C Spride

Damien Octeau
email: octeau@cse.psu.edu

Patrick Mcdaniel
email: mcdaniel@cse.psu.edu

I know what leaked in your pocket: uncovering privacy leaks on Android Apps with Static Taint Analysis

Android applications may leak privacy data carelessly or maliciously. In this work we perform inter-component dataflow analysis to detect privacy leaks between components of Android applications. Unlike all current approaches, our tool, called IccTA, propagates the context between the components, which improves the precision of the analysis. IccTA outperforms all other available tools by reaching a precision of 95.0% and a recall of 82.6% on DroidBench. Our approach detects 147 inter-component based privacy leaks in 14 applications in a set of 3000 real-world applications with a precision of 88.4%. With the help of ApkCombiner, our approach is able to detect inter-app based privacy leaks.

INTRODUCTION

With the growing popularity of Android, thousands of applications (also called apps) emerge every day on the official Android market (Google Play) as well as on some alternative markets. As of May 2013, 48 billion apps have been installed from the Google Play store, and as of September 3, 2013, 1 billion Android devices have been activated [1]. Researchers have shown that Android apps frequently send the user's private data outside the device without the user's prior consent [START_REF] Zhou | Dissecting android malware: Characterization and evolution[END_REF]. Those applications are said to leak private data. Android applications are made of different components; most of the privacy leaks are simple and operate within a single component. More recently, cross-component and also cross-app privacy leaks have been reported [START_REF] Wu | The impact of vendor customizations on android security[END_REF]. Analyzing components separately is not enough to detect such leaks. Therefore, it is necessary to perform an intercomponent analysis of applications. Android app analysts could leverage such a tool to identify malicious apps that leak private data. For the tool to be useful, it has to be highly precise and minimize the false positive rate when reporting applications leaking private data.

Privacy leaks. In this paper, we use a static taint analysis technique to find privacy leaks, i.e., paths from sensitive data, called sources, to statements sending the data out-side the application or device, called sink s. A path may be within a single component or cross multiple components and/or applications.

State-of-the-art approaches using static analysis to detect privacy leaks on Android apps mainly focus on detecting intra-component sensitive data leaks. CHEX [START_REF] Lu | Chex: statically vetting android apps for component hijacking vulnerabilities[END_REF], for example, uses static analysis to detect component hijacking vulnerabilities by tracking taints between sensitive sources and sinks. DroidChecker [START_REF] Chan | DroidChecker: analyzing android applications for capability leak[END_REF] uses inter-procedural Control-Flow Graph (CFG) searching and static taint checking to detect exploitable data paths in an Android application. Flow-Droid [START_REF] Arzt | Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps[END_REF] also performs taint analysis within single components of Android applications but with a better precision. In this paper, we not only focus on intra-component leaks, but we also consider Inter-Component Communication (ICC) based privacy leaks, including Inter-Application Communication (IAC) leaks.

Other approaches use dynamic tracking to find privacy leaks. For instance, TaintDroid [START_REF] Enck | Taintdroid: An information-flow tracking system for realtime privacy monitoring on smartphones[END_REF] leverages Android's virtualized execution environment to monitor Android apps at runtime in which it tracks how application leaks private information. CopperDroid [START_REF] Reina | A system call-centric analysis and stimulation technique to automatically reconstruct android malware behaviors[END_REF] dynamically observes interactions between the Android components and the underlying Linux system to reconstruct higher-level behavior.

A dynamic approach must send input data to the app at runtime to trigger code execution. The input data may be incomplete and thus not execute all parts of the code. Furthermore, some code may only be executed if precise conditions are met at runtime such as a data. In this paper, we focus on static analysis to avoid these drawbacks. The counterpart of static analysis is that it may yield an overapproximation since it analyzes all code even the one that could never be executed.

Static taint analysis for Android is difficult. Despite the fact that Android applications are mainly programmed in Java, off-the-shelf static taint analysis tools for Java do not work on Android applications. The tools need to be adapted mainly for three reasons. The first reason is that, as already mentioned, Android applications are made of components. Communications between components involve two main artifacts: Intent Filter and Intent. An Intent Filter is attached to a component and "filters" Intents that can reach the component. An Intent is used to start a new component by first dynamically creating an Intent instance, and then by calling a specific method (e.g. startActivity, startService) with the intent previously created as parameter. The intent is used either explicitly by specifying the new component to call, or implicitly by for instance only specifying the action1 to perform. The launch of a component is performed by the Android system which "resolves" the matching between Intent and Intent Filter at runtime. This dynamic resolution done by the Android system induces a discontinuity in the control-flow of Android applications. This specificity makes static taint analysis challenging by requiring pre-processing of the code to resolve links between components.

The second reason is related to the user-centric nature of Android applications, in which a user can interact a lot through the touch screen. The management of user inputs is mainly done by handling specific callback methods such as the onClick method which is called when the user clicks on a button. Static analysis requires a precise model that stimulates users' behavior.

The third and last reason is related to the lifecycle management of the components. There is no main method as in a traditional java program. Instead, the Android system switches between states of a component's lifecycle by calling callback methods such as onStart, onResume or onCreate. However, these lifecycle methods are not directly connected in the code. Modeling the Android system allows to connect callback methods to the rest of the code.

Our Proposal. The above challenges will unavoidably cause some discontinuities in the control-flow graph. To overcome these issues, we present an Inter-component communication Taint Analysis tool named IccTA2 . IccTA allows a sound and precise detection of ICC and IAC links. This approach is generic and can be used for any data-flow analysis. In this paper we focus on using IccTA to detect privacy leaks.

IccTA is based on three software artifacts: Epicc-IccTA, FlowDroid-IccTA and ApkCombiner.

Epicc-IccTA extends Epicc [START_REF] Octeau | Effective inter-component communication mapping in android with epicc: An essential step towards holistic security analysis[END_REF] which computes ICC links between Android components. Epicc-IccTA leverages Epicc to incrementally store the computed ICC links to a database for conveniently analyzing a large set of apps. FlowDroid-IccTA extends FlowDroid [START_REF] Arzt | Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps[END_REF]. FlowDroid only finds privacy leaks within single components of Android applications but not between components.

FlowDroid-IccTA uses ICC links computed by Epicc to improve FlowDroid. Based on these computed links, Flow-Droid-IccTA modifies Android applications' code to directly connect components to enable data-flow analysis between components. By doing this, we build a complete controlflow graph of the whole Android application. This allows propagating the context between Android components and yielding a highly precise data-flow analysis. To the best of our knowledge, this is the first approach that precisely connects components for data-flow analysis.

Finally, ApkCombiner helps analyzing multiple Android applications by combining multiple apps into one when there exist data flows between these apps. This results in having a complete control-flow graph of the combined apps. This allows to propagate the context not only between components of a single app but also between components of different apps.

To verify our approach, we developed 26 apps containing ICC based privacy leaks. We have added these applications to DroidBench [START_REF]Droidbench-benchmarks[END_REF], an open test suite for evaluating the ef- 1.

Contributions. To summarize, we present the following original contributions in this paper:

• A novel methodology to resolve the ICC problem by directly connecting the discontinuities of Android apps at the code level.

• IccTA, a tool for inter-component data-flow analysis.

• An improved version of DroidBench with 26 new apps to evaluate tools detecting ICC based privacy leaks.

• An empirical study to evaluate IccTA over an augmented version of the DroidBench test suite (available online 3 ) and 3000 real-world Android applications.

BACKGROUND

Android ICC Methods

An Android application is made of basic units, called components, described in a special file, called Manifest, stored in the application. There are four types of components: a) Activities that represent the user interface and are the visible part of Android applications; b) Services which execute tasks in background; c) Broadcast Receivers that receive messages from other components or the system, such as incoming calls or text messages; and d) Content Providers which act as the standard interface to share structured data between applications. Some specific Android system methods are used to trigger inter-component communication. We call them Inter-Component Communication (ICC) methods. Those methods take as parameter a special kind of object, called Intent, which specifies the target component(s). We perform a short study to compute the usage rate of ICC methods. We analyzed 3000 Android applications randomly selected from Google Play and other third party markets. Table 1 shows the top 8 most used ICC methods. The third column represents the number of apps using at least once the corresponding ICC method. The most used ICC method is startActivity, used to launch a new Activity component, which accounts for 59.2% of the total detected ICC methods.

All ICC methods4 take at least one Intent in their parameters to specify the target component(s). There are two ways to specify ICC method's target components. The first one is by explicitly specifying them by setting the name of the target components through an Intent. The second one is by implicitly specifying them by setting the action, category and data fields of an Intent. In order to receive implicit Intents, target components need to specify an Intent Filter in their application's manifest file. Note that Intents can transfer data between components.

Again, we performed a short study on the 3000 apps to compute the ratio between explicit and implicit Intents for the startActivity ICC method. Among the 55,802 star-tActivity method calls, 27978 use explicit intents and 27824 use implicit Intents.

Figure 1 represents three Android apps made of Activity components. There is an explicit ICC from Activity1 to Activity2 in Application 1. There are two implicit ICCs from Activity2 to Activity3 in Application 1 and from Activity2 to Activity4 between Application 1 and Application 2. Note that the target components of implicit ICC, Activity3 and Activity4, have an Intent Filter with the same action and category value as the Intent used in Activity2. Each time there is an ICC, there may be a flow of data between components and potentially a privacy leak.

FlowDroid

FlowDroid [START_REF] Arzt | Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps[END_REF] is a context-, flow-, field-, object-sensitive and lifecycle-aware static taint analysis tool for Android applications. FlowDroid is based on Soot [START_REF] Lam | The soot framework for java program analysis: a retrospective[END_REF] and Heros [START_REF] Bodden | Inter-procedural data-flow analysis with ifds/ide and soot[END_REF]. The context-, flow-, field-, object-sensitives of FlowDroid are guaranteed by the precise call-graph of Soot and the IFD-S/IDE [START_REF] Reps | Precise interprocedural dataflow analysis via graph reachability[END_REF][START_REF] Sagiv | Precise interprocedural dataflow analysis with applications to constant propagation[END_REF] based data-flow analysis of Heros. A special main method, which considers all combinations of lifecycles, callbacks and entry points of Android components is generated to model data flows within the application. The sources and sinks used by FlowDroid are provided by SuSi [START_REF] Arzt | Susi: A tool for the fully automated classification and categorization of android sources and sinks[END_REF], also an open sourced tool used to fully automatically classify and categorize Android sources and sinks. FlowDroid achieves 93% recall and 86% precision when detecting data leaks on DroidBench. FlowDroid has been mainly used on single component. However, with slight modifications, FlowDroid could also be used when multiple components are involved, i.e., for ICC analyses. Indeed, it's possible to use FlowDroid to compute paths for all individual components and then combines all those paths together, whatever there is a real link or not between these components. A major drawback is that this naive approach yields many false positives.

Epicc

Epicc [START_REF] Octeau | Effective inter-component communication mapping in android with epicc: An essential step towards holistic security analysis[END_REF] is a tool, also based on Soot and Heros, to identify ICC links. In other words it finds links from ICC methods to their target components. Epicc reduces the discovery of ICC in Android to an instance of the Interprocedural Distributive Environment (IDE) problem [START_REF] Sagiv | Precise interprocedural dataflow analysis with applications to constant propagation[END_REF]. It uses data flow analysis to compute Intent values at every ICC method call statements. Experiments show that Epicc identifies 93% of all ICC links and finds ICC vulnerabilities with far fewer false positives than the next best tool.

MOTIVATING EXAMPLE

This section motivates our approach and illustrates the problem we solve through a concrete example. This example is detailed in Listing 1, which presents code of Application 1 introduced in Figure 1. The app has three Activity components represented by Activity1, Activity2 and Activity3 classes. It also features ButtonOnClickListener a listener class used to handle button click events. Activity1 registers a button listener for the to2 button (lines 6-11) and Activity2 registers one for the to3 button (line 15). String id = telMnger . g e t D e v i c e I d() ; When button to2 and to3 are clicked, the onClick method is executed and the user interface will change to Activity2 and to Activity3, respectively. In both cases, an Intent containing the device ID (lines 7 and 32), considered as sensitive data, is sent between two components by first attach- ing the data to the intent with the putExtra method (lines 9, and 35) and then by invoking either startActivity or startActivityForResult (lines 10 and 36). Note that Listing 1 exemplifies both the use of explicit and implicit intents. At line 8, the intent is created by explicitly specifying the target class (Activity2). At line 34, only the intent action is specified with no explicit reference to the target.

8 Intent i = new Intent ( A c t i v i t y 1. this , A c t i v i t
In this example, sendTextMessage is directly executed when Activity2 or Activity3 is loaded since onCreate is the first method in the lifecycle of an Activity. It sends the data retrieved from the Intent as a SMS to the specified phone number.

In this code, two privacy leaks occur: one when button to2 is clicked, the other when button to3 is clicked. When to2 is clicked, the device ID is transferred from Activity1 to Activity2 (line 10) and then Activity2 sends it outside the application (line 18).

When to3 is clicked, the device ID is transferred (line 36) from Activity2 to Activity3 5 . Actually, the device ID (the source) is retrieved in class ButtonOnClickListener instantiated by Activity2. Finally, Activity3 sends the device ID outside the application (line 27).

The sensitive data leaks described above crosses two components: they cannot directly be detected since there is no real code connection between startActivity and onCreate (lines 10 and 13) or between startActivityForResult and onCreate (lines 36 and 24). Section 5 describes our approach to connect components to analyze paths between components and even between applications.

DEFINITIONS

In order to better describe our approach, some android and taint analysis related concepts need to be defined.

Control-Flow Graph (CFG)

We detect data leaks by analyzing control-flow graphs of Android applications. An application CFG consists of a collection of method CFGs linked together according to how they call one another.

Source Method. A source method returns data considered as private from the user's point of view into the application code. For example, method getDeviceId (line 7 6 ) is a source method returning the device ID.

Sink Method. A sink method sends data out of the application. For example, method sendTextMessage (line 27) is a sink method sending data to another phone using SMS. We use sources and sinks computed for Android by the SuSi tool [START_REF] Arzt | Susi: A tool for the fully automated classification and categorization of android sources and sinks[END_REF]. An ICC method is used to trigger communication between two components. For example, method startActivity (line 10) is an ICC method which triggers component communication from Activity1 to Activity2.

Tainted Stmt. A tainted statement contains at least one tainted piece of data. For example, i.putExtra("sensitive ",id) (line 9) is a statement containing the tainted data id.

Tainted Stmt Sequence. A tainted stmt sequence is a flowsensitive sequence of tainted stmt. For instance statements at line 9 and 10 form a tainted statement sequence.

Tainted Path. A tainted path is a tainted stmt sequence where 1) More than one stmt exist in the tainted path; 2) The first stmt contains a source method; 3) The last stmt contains a sink method. Tainted Stmt, Tainted Stmt Sequence and Tainted Path are illustrated in Figure 2.

There are three types of tainted stmt paths in Android: Intra-Component Communication, Inter-Component Communication (ICC) and Inter-Application Communication (IAC) based tainted paths.

Intra-Component Tainted Path. An intra-component tainted path is a tainted path only happening within a component. In our motivating example, there is no intra-component tainted path. But if the startActivity call was replaced with a call to sendTextMessage which sends the device id out of the application, there would be an intracomponent tainted path (line 7-10).

ICC based Tainted Path. An ICC based tainted path is a tainted path among two or more components, i.e., there is at least one ICC method in the path. In our motivating example, there is an ICC based tainted path from source method getDeviceId in Activity1 to sink method send-TextMessage in Activity2 through the startActivity ICC method (line 10).

IAC based Tainted Path. An IAC based tainted path is a tainted path between two or among more applications, i.e., it has at least one ICC method between two components of different applications. There is no IAC based tainted path in our motivating example. But if the Activity4 in Figure 1 sends the device id transferred from Activity2 out of the application, then there is an IAC based tainted path from Application 1 to Application 2.

Privacy Leaks. If a tainted path is detected, it means that a privacy leak has been found. In other words, some private data obtained from a source method can flow through the tainted path to a sink method.

ICCTA

In this Section we describe IccTA, our tool to detect privacy leaks in Android applications. It uses static taint analysis to detect privacy leaks. solve the discontinuities problem introduced by the Android system.

We present the architecture of IccTA in Figure 3 where new or modified component are surrounded by a dashed line. IccTA is the combination of Epicc-IccTA and FlowDroid-IccTA. Epicc-IccTA relies on Epicc to incrementally compute ICC links from Android apps. Both FlowDroid and Epicc are based on Soot [START_REF] Lam | The soot framework for java program analysis: a retrospective[END_REF] and Heros [START_REF] Bodden | Inter-procedural data-flow analysis with ifds/ide and soot[END_REF]. Soot is a framework to analyze Java based applications. It uses the Dexpler [START_REF] Bartel | Dexpler: Converting Android Dalvik Bytecode to Jimple for Static Analysis with Soot[END_REF] plugin to convert Android Dalvik byte code to Soot's internal representation called Jimple and relies on Spark [START_REF] Lhoták | Scaling java points-to analysis using spark[END_REF] to build accurate call graphs. Heros is a scalable implementation of IFDS [START_REF] Reps | Precise interprocedural dataflow analysis via graph reachability[END_REF] and IDE [START_REF] Sagiv | Precise interprocedural dataflow analysis with applications to constant propagation[END_REF], two frameworks to perform data flow analysis. Analyzing multiple applications is done using ApkCombiner. It combines multiple apps to a single one to ease the analysis of IccTA.

Figure 4 is a comparison between IccTA and FlowDroid. FlowDroid (4 up) first converts the Android bytecode to Jimple in step (1.1). Then, in step (1.2), it analyzes the Jimple code to detect tainted paths in single Android components.

IccTA (4 down) can analyze one or multiple Android applications. If more than one application is analyzed, it uses ApkCombiner to merge the Android applications in a single application in step (2.1). The Android application's bytecode is then converted to Jimple in step (2.2). In parallel, Epicc-IccTA analyzes all the input applications (Apk1 and Apk2 in the Figure ) to generate ICC Links in step (2.3) and stores the results to a database in step (2.4). IccTA uses ICC links generated by Epicc-IccTA to connect Android components in the Jimple code in step (2.5). Steps (2.2) and (2.6) correspond to FlowDroid's steps (1.1) and (1.2): the Jimple code is updated to take into account lifecycles and callbacks of components and the taint analysis is launched to generate a list of tainted paths.

FlowDroid-IccTA: Reducing the ICC problem to an Intra-Component problem

Since there is no direct code connection between two Android components, FlowDroid cannot detect ICC based privacy leaks with precision. In this section, we describe how FlowDroid-IccTA reduces the ICC problem to an intracomponent problem on which FlowDroid can perform an highly precise data-flow analysis. Our approach instruments the Jimple code of Android applications to connect components directly in the code.

As mentioned in the introduction, there are three types of discontinuities in Android: (1) ICC methods, (2) lifecycle methods and (3) callback methods. We first describe how FlowDroid-IccTA tackles ICC methods in Section 5.1.1. Then, we detail how FlowDroid-IccTA resolves lifecycle and callback methods in Section 5.1.2. Finally, using our motivating example of Listing 1, we illustrate the code instrumentation process in Section 5.1.3.

ICC Methods

As shown in Figure 4, the ICC problem is solved at step 2.5. This is where the Jimple code is updated by FlowDroid-IccTA to connect components. This code modification is required for all ICC methods (listed in Table 1). We detail these modifications for the two most used ICC methods: startActivity and startActivityForResult. We handle ICC methods for Services and Broadcast Receiver s in a similar way.

StartActivity. Figure 5 shows the code transformation done by FlowDroid-IccTA for the ICC link between Activity1 and Activity2 of our motivating example. FlowDroid-IccTA first creates a helper class named IpcSC (B in Figure 5) which acts as a bridge connecting the source and destination components. Then, the startActivity ICC method is removed and replaced by a statement calling the generated helper method (redirect0) (A).

In (C), FlowDroid-IccTA generates a constructor method taking an Intent as parameter, a dummyMain method to call all related methods of the component (i.e., lifecycle and callback methods) and overrides the getIntent method. An Intent is transferred by the Android system from the caller component to the callee component. We model the behavior of the Android system by explicitly transferring the Intent to the destination component using a customized constructor method, Activity2(Intent i), which takes an Intent as its parameter and stores the Intent to a newly generated field intent_for_ipc. The original getIntent method asks the Android system for the incoming Intent object. The new getIntent method models the Android system behavior by returning the Intent object given as parameter to the new constructor method.

The helper method redirect0 constructs an object of type Activity2 (the target component) and initializes the new object with the Intent given as parameter to the helper method. Then, it calls the dummyMain method of Activity2.

To resolve the target component, i.e., to automatically infer what is the type that has to be used in the method redirect0 (in our example, to infer Activity2), Flowdroid-IccTA uses the ICC links computed by Epicc-IccTA. Epicc-IccTA resolve the target component not only for explicit intents, but also for implicit intents. Therefore, there is no difference for Flowdroid-IccTA to handle explicit or implicit intent based ICCs.

StartActivityForResult. There are some special ICC methods in Android, such as startActivityForResult. A component C1 can use this method to start a component C2. Once C2 finishes running, C1 runs again with some result data returned from C2. The control-flow mechanism of startActivityForResult is shown in Figure 6. There are two discontinuities: one from (1) to (2), similar to the discontinuity of the startActivity method, and the other from (3) to (4).

The startActivityForResult ICC method has a more complex semantic compared to common ICC methods that only trigger one-way communication between components (e.g., startActivity). Figure 7 shows how the code is instrumented to handle the startActivityForResult method in our motivating example. To stay consistent with common ICC methods, we do not instrument the finish method of Activity3 to call onActivityResult method. Instead, we generate a field intent_for_ar to store the Intent which will be transferred back to Activity2. The Intent that will be transfered back is set by the setResult method. We override the setResult method to store the value of Intent to intent_for_ar. The helper method IpcSC.redirect0 does two modifications to link these two components directly. First, it calls the dummyMain method of destination component. Then, it calls the onActivityResult method of the source component.

Lifecycle and Callback Methods

One challenge when analyzing Android applications is to tackle the callback methods and the lifecycle methods of components. There is no direct call among those methods in the code of applications since the Android system handles lifecycles and callbacks. For callback methods, we need to take care of not only the methods triggered by the User Interface (UI) events (e.g., onClick) but also of callbacks triggered by Java or the Android system (e.g., the onCreate method). In Android, every component has its own lifecycle methods. To solve this problem, IccTA generates a dummy-Main method for each component in which we model all the methods mentioned above so that our CFG based approach is aware of them. Note that FlowDroid also generates a dummyMain method, but it is generated for the whole app instead of for each component like we do.

The CFG of instrumented motivating example

Figure 8 represents the CFG of the instrumented motivating example presented in Listing 1. In the CFG, getDe-viceId is a source method in the anonymous OnClickListener class (line 6) called by Activity1. Method send-TextMessage is a sink in Activity2. There is an intracomponent tainted statement path from the source method to sink method (represented by edges 1 to 12).

Figure 8 also shows that IccTA builds a precise crosscomponent control-flow graph. Since we use an technique instrumenting the code to build the CFG, the context of a static analysis is kept between components. This enables Ic-cTA to analyze data-flows between components and thereby enables IccTA to have a better precision than existing approaches. In practice, when increasing the number of applications to analyze, and if all those applications are combined with ApkCombiner, the processing time and memory requirement of FlowDroid-IccTA also grows. To solve this problem, we need to decrease the number of Android apps to combine. Our solution is to build an IAC graph, where a node is an application and an edge a link, to represent the dependencies between applications. The idea behind being that if there is no link between two applications there is no need to combine them.

ApkCombiner: Reducing an IAC problem to an ICC problem

The IAC graph is made up of small independent IAC (sIAC) graphs (connected components). Given a sIAC graph, ApkCombiner combines all the nodes (apps) in it into one app, then IccTA extracts leaks from the resulting app. However, in some case, if a sIAC graph still contains a lot of nodes. This will also limit our approach to be scalable. Our solution is to limit the length (how many apps are involved) of an IAC leak 7 . For example, If a sIAC graph contains 10 nodes (where Ai is connected to Ai+1, i ∈ {1, 9}) and the length limitation is set to five. Then, the sIAC graph is split into five sIACs (e.g., one sIAC is from A2 to A6) that IccTA can analyze. The trade-off limitation length enables our approach to become scalable.

Another good point of building an IAC graph is that new applications can be added to the graph in an iterative and incremental manner. When new apps are involved, we only run them against Epicc-IccTA and add them to the existing IAC graph. We do not need to run the previously computed apps again when adding the new apps to the IAC graph.

In short, by building an IAC graph, the original set of Android applications is split into multiple small sets that IccTA can analyze.

EVALUATION

Our evaluation addresses the following research questions:

RQ1 How does IccTA compare to commercial taint-analysis tools for Android and FlowDroid in terms of precision and recall?

RQ2 Can IccTA find leaks in real-world applications and how fast is it?

RQ3 How do IccTA compare to other academic ICC leak detection approaches? 7 In practice we have not seen a leak going through more than 2 apps.

RQ1: IccTA vs FlowDroid and Commercial Tool

We evaluate and compare IccTA with FlowDroid and IBM AppScan Source 9.0 on DroidBench to test for ICC and IAC leaks. Unfortunately, we were unable to compare IccTA to other static analysis tools as their authors did not make them available.

DroidBench. DroidBench [START_REF]Droidbench-benchmarks[END_REF] is a set of hand crafted Android applications for which all leaks are known in advance. The fact of knowing all leaks in the applications is called the ground truth and is used to evaluate how well static and dynamic security tools find data leaks. DroidBench version 1.2 contains 64 different test cases with different privacy leaks. However, all the leaks in DroidBench are intra-component privacy leaks. Thus, we developed 26 apps and 23 test cases to extend DroidBench with ICC and IAC leaks. A test case is applied on one application to test for ICC and on two applications to test for IAC. In total, 18 apps contain intercomponent privacy leaks and 6 apps contain inter-app privacy leaks. The new set of test cases covers each of the top 8 ICC methods in Table 1. Moreover, among the 26 new apps, two of them do not contain any privacy leaks. If a tool detects privacy leaks on these two apps, the detected leaks are false alarms. Finally, for each test case application we add an unreachable component containing a sink. These unreachable components are used to flag tools that do not properly construct links between components.

The 23 test cases are listed in the first column of Table 2.

IccTA. We run IccTA on all the 23 test cases. The results are shown in Table 2. IccTA successfully passes 18 test cases, with 17 test cases containing 19 privacy leaks and one test case (startActivity5) with no leak.

Among the detected privacy leaks, three of them are IAC based privacy leaks and the remaining ones are ICC based privacy leaks. In the startActivity5 test case, the source component uses an implicit intent with data type text/plain to start another activity. However, no other activity in this test case declares that it can receive an intent with data type text/plain. That means there is no connection among the components in startActivity5 test case. As IccTA takes into consideration the data type of an intent it does not report any privacy leak for this test case.

The startActivity4 test case does not contain any leaks. However, IccTA does report a false warning. The reason is that the source component uses an implicit intent with an URI to start another activity. Since IccTA relies on Epicc which does over-approximate URIs links, it reports a false leak.

The current version does not take into account Content Providers. This is why IccTA misses leaks for the insert1, delete1, update1, and query1 test cases. All the four test cases are related to Content Provider.

FlowDroid. FlowDroid has been evaluated on the first version of DroidBench in [START_REF] Arzt | Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps[END_REF]. In table 2, we present the results of FlowDroid on the new 23 test cases. As already explained, FlowDroid has been initially proposed to detect leak in single Android component. However, we can use FlowDroid in a way that it computes paths for all individual components and then combines all those paths together (whatever there is a real link or not). As a result, we expect that FlowDroid detects most of the leaks but yields several false positives. Results of Table 2 confirm this expectation: FlowDroid has a high recall (69.6%) and a low precision (23.9%). FlowDroid misses three more leaks than IccTA in bindService{2,3,4}. After investigation, we discover that FlowDroid does not consider some callback methods for service components.

AppScan. AppScan Source 9.0 requires a lot of manual initialization work since it has no default sources/sinks configuration file and is unable to analyze Android applications without specifying the entry points of every components. We define the getDeviceId and log methods, that we always use in DroidBench for ICC and IAC leaks, as source and sink, respectively. We also add all components' entry point methods (such as onCreate for activities) as callback methods so AppScan knows where to start the analysis. AppScan is natively unable to detect inter-component dataflows and only detects intra-component flows. AppScan has the same drawbacks as FlowDroid and should have a high recall and low precision on DroidBench. We use an additional script to combine the flows between components. As expected AppScan's recall is high (56.5%) and its precision low (21.0%). Compared to FlowDroid, AppScan does worse. Indeed, AppScan does not correctly handle startActivi-tyForResult and thus misses leaks going through methods receiving results from the called activities in startForRe-sult{2,3,4}.

Conclusion. IccTA outperforms both the commercial taint-analysis tool AppScan 9.0 and FlowDroid in terms of precision and recall.

RQ2: IccTA and Real-World Apps

We run the experiments on a Core i7 CPU running a Java VM with 8 Gb of heap. To evaluate our approach, we use IccTA to analyze 3000 Android apps downloaded from the Google Play market as well as some third-party markets (e.g., wandoujia). IccTA process 3000 apps in about 100 hours. IccTA does not detect any leak for 2575 (85.83%) applications. IccTA reports 425 applications containing privacy leaks. Among the 425 apps, 411 apps only contain intra-component leaks and 14 apps contain at least one ICC leak. From those 14 apps, 13 contain both intra-component leaks and ICC leaks. IccTA detects 6989 IAC links. Among those IccTA detects one IAC leak. This result indicates that components do communicate and share data, but it is rare that an inter-application leak occurs.

For intra-app leaks, IccTA detects 5986 leaks in the 425 apps. Among the detected leaks, 147 (2.5%) are ICC privacy leaks. We manually check the 147 reported ICC leaks and the device through SMS. However, to distinguish the intention of detected privacy leaks is out of scope of this paper. We take it as our further work. ICC leak: com.dikkar.ifind. An ICC based privacy leak is detected by IccTA on this application. In method onLocationChanged of class .iFindPlaces, the getLongitude source method is called and returns the location of the Android phone. Then, the location is transferred to another component named .PlaceDetail, where method b of class j is called. In method b, a sink method Log.d logs the location into disk with ServiceHandler tag name. To verify the detected leaks, we developed an Android application named LogParser. By giving the permission android.permission.READ_LOGS 9 , LogParser reports all the locations logged by Find Places.

IAC leak: com.bi.mutabaah.id to jp.benishouga.clipstore. An IAC leak is reported by IccTA between app com.bi.mutabaah.id and app jp.benishouga.clipstore. The source method findViewById is called in component com.bi.mutabaah.id.activity.Statistic, where the data of a TextView is obtained. Then the data is stored into an intent with two extras named android.intent.extra.SUBJECT and android.intent.extra.TEXT. After that, startActivity is used to send the data to app jp.benishouga.clipstore, which extracts the data from the intent with the same extra names and writes all the data into a file named clip.txt under path /data/data/jp.benishouga.clipstore/files.

Conclusion. IccTA finds leaks in real-world apps in a reasonable amount of time. Nevertheless, IccTA only detects a single IAC leak. This is an indication that interapplication leaks are rare.

RQ3: Compare with Other academic Tools

We identify two academic tools able to deal with ICC leaks: SCanDroid [START_REF] Fuchs | Scandroid: Automated security certification of android applications[END_REF] and SEFA [START_REF] Wu | The impact of vendor customizations on android security[END_REF]. However, ScanDroid fails to report any leaks and SEFA is not available. As a result, we were not able to evaluate them on DroidBench.

To answer the research question, we focus and discuss some key aspects of the various approaches. SCanDroid and SEFA both use a path matching approach, which computes paths for all individual components and then combines some paths together, the decision of combining two paths or not is given by a matching algorithm. A path matching approach presents at least two main drawbacks.

First, even if the taint analysis is done for each compo-

Figure 9: The problem of using path matching approach for startActivityForResult nent, the context of the analysis is lost when SCanDroid and SEFA combine the taint paths, since the analysis is performed before the combination of the paths. IccTA does not present this problem because it connects the components at the code level and then performs the analysis. Thus, it keeps the data-flow between two components. Losing the context decreases the precision of the tool. Indeed, an Intent can carry data, i.e., it may contain a lot of extras key/value pairs but only part of them are sensitive. A precise tool needs to distinguish them to avoid false positive. For a path matching approach, it is not easy to distinguish them because they do not keep the state of Intent when matching two available paths.

Second, some specific ICC methods such as startActiv-ityForResult are difficult to handle with a matching algorithm. It will become even worse when the special ICC methods exist in a class which is invoked by multiple components. Suppose a component Activity4 also uses the class ButtonOnClickListener shown in Listing 1 to communicate with other components. We present this scenario in Figure 9. A path matching approach first finds a path from startAc-tivityForResult to Activity3. After the finish method of Activity3 is called, the onActivityResult method of the source component is invoked by the Android system. The problem is that it is difficult to know which component (Activity2 or Activity4) is the source because they both use the same class ButtonOnClickListener where the Intent is created. In fact, It is very difficult to statically resolve this problem since it is caused by the mechanism of dynamic binding of Android (or Java). In our approach, IccTA resolves this problem by explicitly calling the appropriate onActivityResult method (see Figures 6 and7) of the source component (Activity2 or Activity4) thanks to the helper class IpcSC.

Conclusion. Even if we were not able to evaluate stateof-the-art tools detecting ICC leaks (SCanDroid and SEFA), IccTA seems to be more precise mainly because it keeps the context between components unlike path matching approaches.

LIMITATIONS

In this section, we discuss the limitations of IccTA. FlowDroid. IccTA is based on FlowDroid to perform static taint analysis and thereby shares the same limitations of FlowDroid. IccTA resolves reflective calls only if their arguments are string constants. It is also oblivious to multithreading. We experienced that FlowDroid cannot properly analyze some apps (too much memory consumption or hangs). We start by analyzing a set of 5000 and keep only 3000 apps that work with FlowDroid. Running IccTA on a big server could significantly decrease the number of falling analysis. Moreover, we are very confident that the next release of FlowDroid will resolve this problem.

Epicc. IccTA relies on Epicc to compute links between components. Since Epicc does not handle URIs, it fails to find ICC links for ContentProvider and yields false positives for the other three types of components when they communicate using URIs. In practice the number of links is huge due to the false positives. We check the links (intents and intent filters) and only keep the ones not using URIs.

IccTA. At the moment IccTA does not handle some rarely used ICC methods such as sendActivities or sendOrdered-BroadcastAsUser. Data send between component with an intent, is represented as key/value pairs. When a tainted data is put in the intent, IccTA taints all key/value pairs. This could result in false positives if a tainted data is put in an intent and, in the receiving component, a non-tainted data is retrieved from the intent and flows to a sink.

Native Code. Some Android application are packaged with native code. IccTA only analyzes the dex file containing the Dalvik bytecode.

RELATED WORK

As far as we know, IccTA is the first approach to seamlessly connect Android components through code instrumentation in order to perform ICC based static taint analysis. By using a code instrumentation technique, the state of the context and data (e.g. an Intent) is transferred between components. To the best of our knowledge, there is no other existing static approach to detect Android privacy leaks tackling the ICC problem and keeping state between components.

Static Analyses. There are several approaches using static analysis to detect privacy leaks. PiOS [START_REF] Egele | Pios: Detecting privacy leaks in ios applications[END_REF] uses program slicing and reachability analysis to detect the possible privacy leaks. TAJ [START_REF] Tripp | Taj: effective taint analysis of web applications[END_REF] uses the same taint analysis technique to identify privacy leaks in web applications. However, these approaches introduce a lot of false positives. CHEX [START_REF] Lu | Chex: statically vetting android apps for component hijacking vulnerabilities[END_REF] is a tool to detect component hijacking vulnerabilities in Android applications by tracking taints between sensitive sources and externally accessible interfaces. However, it is limited to at most 1-object-sensitivity which leads to imprecision in practice. LeakMiner and AndroidLeaks state the ability to handle the Android Lifecycle including callback methods, but the two tools are not context-sensitive which precludes the precise analysis of many practical scenarios. FlowDroid [START_REF] Arzt | Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps[END_REF] introduces a highly precise taint analysis approach with low false positive rate, but it does not identify ICC based privacy leaks. IccTA performs an ICC based static taint analysis by instrumenting the code of the original app while keeping the precision high.

ComDroid [START_REF] Chin | Analyzing inter-application communication in android[END_REF] and Epicc [START_REF] Octeau | Effective inter-component communication mapping in android with epicc: An essential step towards holistic security analysis[END_REF] are two tools that tackle ICC problem, but they mainly focus on ICC vulnerabilities and do not taint data.

SCanDroid [START_REF] Fuchs | Scandroid: Automated security certification of android applications[END_REF] is a tool for analyzing ICC based privacy leaks. It prunes all call edges to Android OS methods and conservatively assumes the base object, the parameters and the return value to inherit taints from arguments. This approach is much less precise than our tool since we model all the Android OS methods (except native methods) with our dummy main method in the control-flow graph. Another tool SEFA [START_REF] Wu | The impact of vendor customizations on android security[END_REF] also resolves the ICC problem. It performs a system-wide data-flow analysis to detect possible vulnerabilities (e.g., passive content leaks). Both SCanDroid and SEFA use a matching approach to analyze inter-component leaks. SCanDroid defines all the methods importing data to an app as inflow methods and all the methods exporting data from an app as outflow methods. Then, it matches the inflow and the outflow methods to connect two components. SEFA defines ICC methods as bridge-sinks to distinguish with the sensitive-sinks. It uses the bridge-sinks to match with other components and thereby connecting two components. As we mentioned before, the matching approach has some drawbacks compared to our instrumenting approach. Therefore, even if we were not able to evaluate SCanDroid and SEFA on DroidBench, it comes that IccTA is more precise by design.

AsDroid [START_REF] Huang | AsDroid: Detecting stealthy behaviors in android applications by user interface and program behavior contradiction[END_REF] and AppIntent [START_REF] Yang | Appintent: Analyzing sensitive data transmission in android for privacy leakage detection[END_REF] are another two tools using static analysis to detect privacy leaks in Android apps. Both of them try to analyze the intention of privacy leaks. Analyzing the leaking intention is out of scope of this paper. However, we think it is necessary to distinguish whether a privacy leak is intended or not. We take this as our further work.

Dynamic Analyses. Dynamic taint analyses techniques, on the other hand, track sensitive data at runtime. Taint-Droid [START_REF] Enck | Taintdroid: An information-flow tracking system for realtime privacy monitoring on smartphones[END_REF] is one of the most sophisticated dynamic taint tracking systems. It tracks flows of private data of thirdparty apps. CopperDroid [START_REF] Reina | A system call-centric analysis and stimulation technique to automatically reconstruct android malware behaviors[END_REF] is another dynamic testing tool which observes interactions between the Android components and the Linux system to reconstruct high-level behavior and uses some special stimulation techniques to exercise the app to find malicious activities. Several other systems, including AppFence [START_REF] Hornyack | These aren't the droids you're looking for: retrofitting android to protect data from imperious applications[END_REF], Aurasium [START_REF] Xu | Aurasium: practical policy enforcement for android applications[END_REF], AppGuard [START_REF] Backes | Appguard: enforcing user requirements on android apps[END_REF] and BetterPermission [START_REF] Bartel | Improving privacy on android smartphones through in-vivo bytecode instrumentation[END_REF] try to mitigate the privacy leak problem by dynamically monitoring the tested apps.

However, those dynamic approaches can be fooled by special designed methods to circumvent security tracking [START_REF] Sarwar | On the effectiveness of dynamic taint analysis for protecting against private information leaks on android-based devices[END_REF]. Thus, dynamic tracking approaches may miss some data leaks and yield an under-approximation. On the other hand, static analysis approaches may yield an over-approximation because all the application's code is analyzed even code that will never be executed at runtime. Both approaches are complementary when analyzing Android applications for data leaks.

CONCLUSION

This paper addresses the major challenge of performing data-flow analysis across multiple components or multiple applications. We have presented IccTA10 , an ICC based taint analysis tool able to perform such analysis. In particular, we demonstrate that IccTA can detect ICC based privacy leaks by providing a highly precise control-flow graph through instrumentation of the code of applications. Unlike previous approaches, IccTA enables a data-flow analysis between two components and adequately models the lifecycle and callback methods to detect ICC based privacy leaks. When running IccTA on DroidBench, it reaches a precision of 95.0%. When running IccTA on three thousands applications randomly selected from the Google Play store as well other third-party markets, it detects 130 inter-component based privacy leaks in 12 applications. Other existing privacy detecting tools (e.g., AndroidLeaks) could benefit by implementing our approach to perform ICC and IAC based privacy leaks detection.

Figure 1 :

 1 Figure 1: Explicit and Implicit ICC between Components of Android Applications.

1

  // T e l e p h o n y M a n a g e r telMnger ; ( default ) 2 // S m s M a n a g e r sms ; ( default ) 3 class A c t i v i t y 1 extends Activity { 4 void onCreate ( Bundle state ) { 5 Button to2 = ( Button ) f i n d V i e w B y I d( to2a ) ; 6 to2 . s e t O n C l i c k L i s t e n e r( new O n C l i c k L i s t e n e r() { 7

Figure 2 :

 2 Figure 2: Representation of Statements, Source, Sink, Statement Sequence and Tainted Path.

5Figure 3 :

 3 Figure 3: The architecture of IccTA

Figure 4 :

 4 Figure 4: Overview of IccTA (down) and FlowDroid (up).

Figure 5 :

 5 Figure 5: Code Modifications to Handle ICC Communication between Activity1 and Activity2. The startActivity ICC method is replaced (A) by a call to code that instantiates and calls the "main" method of Activity2 (B). The target component class is updated to handle Intent objects directly, by modeling the Android system behavior (C).

Figure 6 :

 6 Figure 6: The control-flow mechanism of startActivity-ForResult

Figure 7 :

 7 Figure 7: An Example about running FlowDroid-IccTA to startActivityForResult ICC method. (A) represents the modified code of ButtonOnClickListener and (C) the modified code of Activity3. (B) is the glue code connecting ButtonOnClickListener and Activity3. Some method parameters are not represented to simplify the code.

Figure 8 :

 8 Figure 8: The control-flow graph of the instrumented motivating example

Table 1 :

 1 The top 8 used ICC methods †

	ICC Method	Counts(#.)	Used Apps(#.)
	startActivity	55802 (61.44%) 2765 (92.2%)
	startActivityForResult 11095 (12.21%) 1980 (66.0%)
	query	6606 (7.27%)	1601 (53.4%)
	startService	3942 (4.34%)	1077 (35.9%)
	sendBroadcast	3472 (3.82%)	790 (26.3%)
	insert	2100 (2.31%)	615 (20.5%)
	bindService	1515 (1.67%)	644 (21.5%)
	delete	1238 (1.36%)	350 (11.7%)
	Other ICC Methods	5058 (5.57%)	-
	Total	90828 (100%)	-
	† Methods with higher counts are selected when overload
	methods exist
	fectiveness and accuracy of taint analysis tools specifically
	for Android apps. The 26 apps cover the top 8 used ICC
	methods illustrated in Table

  The main challenge for this is to

			Apk	(1.1) Soot	Jimple		(1.2) FlowDroid Analysis		Tainted Paths
	Apk1	(2.1)
	Apk2 (2.3) Epicc Combiner Apk-(2.3) Epicc	Apk * ICC Links	Epicc-IccTA (2.2) Soot (2.4)	Jimple Links DB	(2.5) FlowDroid-IccTA	Jimple + ICC + Lifecycle + Callback	(2.6) FlowDroid Analysis	Tainted Paths

  In Android, Inter-Application Communication (IAC) is similar to Inter-Component Communication (ICC). Indeed, IAC also relies on component communication, except that the source component and the destination component belong to different applications. If we can connect applications, an IAC Problem becomes a standard ICC Problem.Analyzing Multiple Applications. As shown in Figure4, FlowDroid can only analyse one application at a time. Therefore, we develop a tool, ApkCombiner, to combine multiple apps into one. ApkCombiner combines all the parts of Android apps including bytecodes, assets, manifest and all the resources. Then, we use IccTA to analyze the combined app to compute IAC based privacy leaks. As FlowDroid-IccTA handles the combined application as a single applications, it only detects ICC based privacy leaks. To distinguish ICC leaks from IAC leaks, IccTA checks if all statements of the tainted path belong to the same application or not.

	String id = telMnger.getDeviceId();	(4)	this.intent for ipc = i;	(9)	return this.intent for ipc;
	(1)	Activity2 a2 = new Activity2(i);			Intent i = getIntent();
	i.putExtra("sensitive", id); (2)	(3)	return-site;	(5)	(8)		return-site;	(10)
	ipcSC.redirect0(i);		(6)	(7)	onCreate(null);		(11)
			a2.dummyMain();		String s = i.getStringExtra("sensitive");
	return-site;				return-site;		(12)
			return-site;			sendTextMessage(s);
	normal edge		call-to-start edge		call-to-return edge		exit-to-return edge

Table 2 :

 2 DroidBench test results ⋆ = correct warning, ⋆ = false warning, = missed leak multiple circles in one row: multiple leaks expected all-empty row: no leaks expected, none reported

Table 3 :

 3 The top 5 used source methods and sink types

	Method/Type	Counts(#.) Detail
	openConnection	Source Methods 601	http connection
	getLongitude		514	longitude
	getLastKnownLocation	448	Location
	getDeviceId getCountry		403 265	IMEI or ESN country code
		Sink Types
	Log URL		2755 821	error or warn execute
	SharedPreferences		717	putInt, putString
	Message		339	sendTextMessage
	File		9	write(string)

Such as android.intent.action.VIEW or .CALL or .EDIT

Our experimental results and IccTA itself are available at https://sites.google.com/site/icctawebpage.

github.com/secure-software-engineering/DroidBench

Except Content Provider related methods such as query or insert

† C/A: # of Components / # of Applications Test Case (C/A) † FlowDroid AppScan IccTA Inter-Component Communication startActivity1 (3/1) ⋆ ⋆ ⋆ ⋆ ⋆ startActivity2 (4/1) ⋆ (4 ⋆ ) ⋆ (4 ⋆ ) ⋆ startActivity3 (6/1) ⋆ (32 ⋆ ) ⋆ (32 ⋆ ) ⋆ startActivity4 (3/1) ⋆ ⋆ ⋆ ⋆ ⋆ startActivity5 (3/1) ⋆ ⋆ ⋆ ⋆ startForResult1 (3/1) ⋆ ⋆ ⋆ startForResult2 (3/1) ⋆ ⋆ startForResult3 (3/1) ⋆ ⋆ ⋆ startForResult4 (3/1) ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ startService1 (3/1) ⋆ ⋆ ⋆ ⋆ ⋆ startService2 (3/1) ⋆ ⋆ ⋆ ⋆ ⋆ bindService1 (3/1) ⋆ ⋆ ⋆ ⋆ ⋆ bindService2 (3/1) ⋆ bindService3 (3/1) ⋆ bindService4 (3/1) ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ sendBroadcast1 (3/1) ⋆ ⋆ ⋆ ⋆ ⋆ insert1 (3/1) delete1 (3/1) update1 (3/1) query1 (3/1) Inter-App Communication startActivity1 (4/2) ⋆ ⋆ ⋆ ⋆ ⋆ startService1 (4/2) ⋆ ⋆ ⋆ ⋆ ⋆ sendBroadcast1 (4/2) ⋆ ⋆ ⋆ ⋆ ⋆Sum, Precision, Recall and F1 ⋆ , higher is better

The package name is omitted when the class name starts with the package name

Starting from Android 4.1 it is no more granted to regular apps, but it can still be granted to either vendor apps or apps running on rooted phones.

Our experimental results and IccTA itself are available at https://sites.google.com/site/icctawebpage.

We summarize the frequently used source methods and sink types (Java classes) in Table 3 from the 425 apps having at least one leak. Note that we only count such source and sink methods that appear in the detected leaks. The most used source method is openConnection and it is used 601 times in 169 apps. The most used sink types is Log and it is used 2755 times in 261 apps. The reason why we study sink types instead of sink methods is that there are a lot of sink methods in a same sink type. Take the Log sink type as an example, there are eight sink methods which log the private data to disk.

Let us describe in details three leaks, one for each type of leak.

Intra-component leak: bz.prana.myphonelocator. I-ccTA detects an intra-component privacy leak starting from the getLongitude source method in method onLocation-Changed of class .SMSReceiver$MyLocationListener 8 . The location is sent out of the app through SMS by the send-TextMessage sink method in method smsReply of class .SM-SReceiver. The app is designed to send the location outside


Costin Vasile
email: costin.vasile@aii.pub.ro

Petrut Teodor

Petrut Teodor-Ion #
email: teodor-ion.petrut@gipsa-lab.grenoble-inp.fr

Cornel Ioana #
email: cornel.ioana@gipsa-lab.grenoble-inp.fr

Valentin Sgârciu
email: vsgarciu@aii.pub.ro

Jérôme Mars

Ion Candel
email: ion.candel@gipsa-lab.grenoble-inp.fr

Ultrasound Testing of Metallic Structures using a Dual Symmetric Path

published or not. The documents may come   L'archive ouverte pluridisciplinaire

I. INTRODUCTION

The detection and localisation of defects in metallic structures is a crucial aspect of any industrial endeavour, as any malfunction of a piece of equipment will impact production capabilities and will become the source of further spending in maintenance and repair. Thus, by taking preemptive actions to detect and localise defects in the earliest of stages, one can minimize these costs and the impact on production activities.

When using matched filtering, modulated excitation signals are commonly used in ultrasound inspection methods, due to the advantage of a filtering gain proportional to the bandwidth-duration product, with improvements of 12dB to 18dB for chirps [linear frequency modulation (FM)], or in the range of 4dB to 9dB for non-linear FM and binary codes [START_REF] Misaridis | Use of modulated excitation signals in medical ultrasound. part I: basic concepts and expected benefits[END_REF], [START_REF] Misaridis | Use of modulated excitation signals in medical ultrasound. part II: design and performance for medical imaging applications[END_REF]. In this paper we propose to investigate the use of stepped frequency modulation in order to further exploit these advantages in the ultrasound inspection of metallic structures.

With this type of signal and the appropriate matched filter approach, we also introduced a symmetric path inspection method, which consists of inverting the roles of the two transducers that were used (the emitter becomes the receiver and vice versa), thus having two acquired received signals. These two signals will be repeatedly filtered with a timefrequency mask, which will then become the inputs for a matched filtering step in our proposed algorithm.

The blocks of steel on which the methods were tested present the worst case scenario for ultrasound testing: coarse grain structure, high attenuation and interference, longitudinal defects (parallel to the ultrasound waveform).

Section II will describe the two methods with further details (MF and MF-DSPI), in Section III we will present the experimental setup and results, followed by the conclusions in Section IV.

II. MATCHED FILTERING (MF) AND DUAL SYMMETRIC PATH INSPECTION (MF-DSPI) METHODS

A. Matched Filtering (MF)

Matched filtering is the preferred and most commonly used method for filtering signals with large bandwidth-duration product (such as linear frequency modulation, phase modulations, etc) and for identifying them in the presence of noise -for very low signal to noise ratios [START_REF] Harput | Diagnostic Ultrasound Tooth Imaging using Fractional Fourier Transform[END_REF]. The matched filter is a linear time invariant filter, which maximizes the receiver SNR. Using the likelihood criterion, such a filter has the impulse response h(t), equal to the time-reversed input waveform, s(t), [START_REF] Misaridis | Use of modulated excitation signals in medical ultrasound. part I: basic concepts and expected benefits[END_REF], [START_REF] Harput | Diagnostic Ultrasound Tooth Imaging using Fractional Fourier Transform[END_REF]:

• (1)
,where k is a gain factor and is the physical realisation generated time shift.

For the input s(t), the matched filter output is given by equation (2):

• ( 2
)
,where is the time-shifted auto-correlation of the transmitted signal, s(t). In other words, in our ultrasound application, the reception consists of several echoes, with the same form as the transmitted signals, but attenuated and corrupted by noise and false arrivals (interferences, reflections by grains, etc). A cross-correlation between the transmitted and the received signals will contai corresponding to the time of arrival of th ideal situation (in the presence of white n filter output would be zero in the absence of present maxima as the echoes arrive.

B. Dual Symmetric Path Inspection (MF-D

The basis of this approach is the symmet of the steel block. This consists of tw acquisitions, the first in which we send an with one ultrasound transducer and receive and the second where we inverse the roles where the emitter becomes the receiver and 1). The reason behind this is that the two re contain the useful echoes (backwall and echoes) while maintaining the same detectio the same time of arrival (TOA); the other alarms" (generated by metal impurities properties (different TOA's and differen signatures) due to their different relative po the transducers (thus, different r geometries). By analysing the two dete managed to greatly reduce the false alarm show in the experimental results section. An echo generated by a defect will hav than the TOA corresponding to the echo backwall of the steel block. It is therefore for the excitation signal pattern only until backwall generated echo (including it, in or a reference on the detection signals).

The excitation signal pattern was used fo frequency mask, that was applied on the rec in local maxima hese echoes. In an noise), the matched f echoes and would DSPI) The time-frequency mask manner:

tric
• time mask: sele corresponding to the • frequency mask: sel (Butterworth pass-b the bandwidths and chirps that make up The time-frequency mask is the first backwall generated ec offset of 1 point between two each iteration, there is a match will sum up to the previous itera Thus, for iteration i, we have domains) reception m i (t), and matched filter output, R i-1 (τ); t signal is given by: enerated echo. Figures 2 and3 k highlighted on the excitation on the pattern of the excitation signal. ound the 11 chirps). ,where s(t) is the pseudo-chirp excitati initial detection signal is 0. The fina (for each of the two acquired signals: direc be and , after the ti matched filtering steps.

The final step is to verify which po detection signals are consistent with one a detect and localise only the echoes correspo in the metal block. These echoes must arriv and must have the same signatures, thus w use, as a measure of verifying this, a coefficient ( [START_REF] Cornbleet | Comparison of Product Moment and Rank Correlation Coefficients in the Assessment of Laboratory Method-Comparison Data[END_REF]) window, which should majority of the false alarm echoes. This e sliding correlation coefficient window imp criterion:

, ∑ ∑ ∑
,where and are the sample mea window as it advances through the two de applying this criterion, we reduce the num echoes and highlight the useful echoes. A all the steps of the MF-DSPI method is pres

III. EXPERIMENTAL SETUP AND R A. Experimental Setup

The central frequency of the ultrasou 1MHz.The steel block that was used to verif two methods was a non-homogenous, low steel, with a coarse grain structure. Bec attenuation of the ultrasound signals is presence of randomly distributed scattere increased rate of false alarms. Also, the defe to detect and localise were longitudinal, a (parallel to the ultrasound excitation signal the difficulty of the test case scenario.

RESULTS

und transducers is fy and compare the w quality block of cause of this, the s higher, and the ers introduced the ects which we tried as seen in figure 5 ls), thus increasing block.

The steel block has two following properties (for the m the steel block of aprox. 5.52-5.

• Cavity 1 : height h t1≈26microseconds; • Cavity 2: height h t2≈28.5microsecond

B. Results for Cavity 1

Using the MF method, it is p largest) defect, followed by the in figure 6. The TOA of the ech corresponds to the real position. possible to detect the first (and backwall echo, as can be seen ho is at 26 microseconds, which .

hod. TOA of defect generated echo at seconds.

inspection and the MF with on the defect signature is figure 7). In figure 8 we use the n and the detection is very The advantages of this method consist in amplifying the useful echoes and in the removal of the false alarm echoes.. In the case of the first cavity, it is clear how the defect-generated echo is not sufficiently highlighted when using the MF method, in comparison to the approach proposed in this paper. This is explained by the time-frequency mask that enables the precise search of the exact excitation signal pattern that was generated by the emitter.

C. Results for Cavity 2

When using the classic MF method for the second, smallest defect, we managed to find only the backwall generated echo, with no real sign of the cavity's presence. Figure 9 shows only the expected backwall generated echo, at 36 microseconds. The MF with stepped frequency modulation was also used, with similar results (figure 10): the matched filter gain is not sufficient to detect the echo coming from the cavity, because of the reduced reflected energy. However, when applying the sliding correlation coefficient window criterion, we discovered that the only similar portions of the two detection signals correspond the two useful echoes: the backwall (at 36 microseconds) the defect generated echoes, detected at 29 microseconds, similar to the real position (figure 11).

IV. CONCLUSIONS This paper presents a comparison between the classical MF method and a new approach that is a combination of the dual symmetric path inspection and the matched filter, with also a stepped frequency modulation. We used these two methods to detect the useful echoes in the ultrasound inspection of a metallic steel block, and to minimize the impact of the false alarm echoes.

The improvements in terms of results are due to the following processing approaches: the symmetric path inspection exploits the similarity of useful echoes, the iterative time-frequency filtering of the received signal and its subsequent matched filtering and, lastly, the imposing of a criterion for similarity of useful echoes, consisting of a sliding correlation coefficient window.

The results show how the MF method is limited in a medium with high attenuation and in the presence of multiple false alarm-generating scatterers (coarse grain structure). The proposed approach succeeds in detecting and localising the defects, while also limiting the impact of these false alarm echoes. Also, choosing a stepped frequency modulated signal (and its frequency domain) aims to reduce multiple scattering by designing an appropriate time-frequency filter mask.

In the future works, we focus in the study of more advanced modulations and processing. The use of multielement transducer arrays is also another direction that will be pursued.

Fig. 1 .

 1 Fig. 1. The dual symmetric path inspect The modulated excitation signal used frequency modulation (a pseudo-chirp) (f following properties: • 11 chirps, with a 30KHz bandw following frequencies: 750 850KHz, 900KHz, 950KHz, 10 1100KHz, 1150KHz, 1200KHz, • chirp duration: 15 microsecon chirps: 100 microseconds; sam 10MHz; • entire signal repetition period: (enough time to avoid residual to the block of steel used -figur • signals designed and adapted scattering tendency of the mater -careful selection of frequency d

Fig. 2 .Fig. 3 .

 23 Fig. 2. Time-frequency mask built o (black rectangles aro

  d on a received signal and direction of ions. was built in the following ecting the time intervals e excitation signal pattern; lecting the frequency intervals band filters) corresponding to d centre frequencies of the 11 the excitation signal. s applied only until right after cho, as stated earlier, with an consecutive applications. For ed filtering step, whose output ation matched filtering step. e the filtered (in time-frequency d the previous iteration, i-1, the i th matched filter detection

,

Fig. 4 .

 4 Fig. 4. Block diagram for the MF-DSP

Fig. 5 .

 5 Fig. 5. Section view of the steel b

Fig. 6 .

 6 Fig. 6. Cavity 1 results for MF meth 26 microsWhen applying dual path stepped frequency modulatio enhanced at 26 microseconds (f correlation coefficient criterion accurate.

Fig. 7 .

 7 Fig. 7. Cavity 1 results for the MF echo is much more visible (the tw

F

  -DSPI method. The defect-generated o intermediate detection signals). final detection signal.

Fig. 9 .

 9 Fig. 9. MF normalised output, with only the backwall generated echo.

Fig. 10 .

 10 Fig. 10. MF-DSPI normalised output, with only backwall generated echo (the two intermediate detection signals).

Fig. 11 .

 11 Fig. 11. Normalised Final Detection Signal, with the two useful echoes (defect generated echo at 29 microseconds).