Nicolas Andreff

Philippe Martinet

Visual Servoing of a Gough-Stewart Parallel Robot without Proprioceptive Sensors

In this paper, it is shown that computer vision, used as a redundant metrology mean, allows the control of a Gough-Stewart parallel robot without using any joint sensor. This result is highly relevant for the control of parallel mechanisms hard to instrument (for instance, hydraulically actuated ones) or with large displacements (for instance, large telescopes positioning systems). It is also very interesting since it turns computer vision, usually considered as an exteroceptive sensor, into a proprioceptive one, yet preserving its exteroceptive nature and non contact measurement.

Introduction

Parallel mechanism are such that there exist several kinematic chains (or legs) between their base and their end-effector. Therefore, they may exhibit a better repeatability [START_REF] Merlet | Parallel robots[END_REF] than serial mechanisms but not a better accuracy [START_REF] Wang | On the accuracy of a Stewart platform -Part I : The effect of manufacturing tolerances[END_REF], because of the large number of links and passive joints. There can be two ways to compensate for the low accuracy. The first way is to perform a kinematic calibration of the mechanism and the second one is to use a control law which is robust to calibration errors. There exists a large amount of work on the control of parallel mechanisms (see [1] for a long list of references). In the focus of attention, Cartesian control is naturally achieved through the use of the inverse Jacobian which transforms Cartesian velocities into joint velocities. It is noticeable that the inverse Jacobian of parallel mechanisms does not only depend on the joint configuration (as for serial mechanisms) but also on the end-effector pose. Consequently, one needs to be able to estimate or measure the latter. As far as we know, all the effort has been put on the estimation of the end-effector pose through the forward kinematic model and the joint measurements. However, this yields much trouble, related to the fact that there is usually no analytic formulation of the forward kinematic model of a parallel mechanism. Hence, one numerically inverts the inverse kinematic model, which is analytically defined for most of the parallel mechanisms. However, it is known [START_REF] Merlet | An algorithm for the forward kinematics of general 6 d.o.f. parallel manipulators[END_REF][START_REF] Husty | An algorithm for solving the direct kinematics of general Gough-Stewart platforms[END_REF] that this numerical inversion requires high order polynomial root determination, with several possible solutions (up to 24 real solutions for a Gough-Stewart platform). Much of the work is thus devoted to solving this problem accurately and in real-time (see for instance [START_REF] Zhao | Direct displacement analysis of parallel manipulators[END_REF]), or to designing parallel mechanisms with analytical forward kinematic model [START_REF] Kim | Evaluation of a Cartesian parallel manipulator[END_REF][START_REF] Gogu | Fully-isotropic T3R1-type parallel manipulator[END_REF]. One of the promising paths lies in the use of the so-called metrological redundancy [START_REF] Baron | The on-line direct kinematics of parallel manipulators under joint-sensor redundancy[END_REF], which simplifies the kinematic models by introducing additional sensors into the mechanism and thus yields easier control [START_REF] Marquet | Contribution à l'étude de l'apport de la redondance en robotique parallèle[END_REF]. Computer vision being an efficient way of estimating the end-effector pose [START_REF] Dementhon | Model-based object pose in 25 lines of code[END_REF][START_REF] Lavest | Do we really need an accurate calibration pattern to achieve a reliable camera calibration[END_REF], it is a good alternative to use it for Cartesian control of parallel mechanisms. It can be done in three ways.

Vision as a sensor

The first one consists in computing the end-effector poses by vision, then in translating them into joint configurations, through the inverse kinematic model, and finally servoing in the joint space. However, such schemes should be used carefully for parallel mechanisms, since joint control does not take into account the kinematic closures and may therefore yield high internal forces [START_REF] Dasgupta | Force redundancy in parallel manipulators: theoretical and practical issues[END_REF].

Visual servoing Second, vision can be additionally used to perform visual servoing [START_REF] Espiau | A New Approach To Visual Servoing in Robotics[END_REF][START_REF][END_REF]. Indeed, instead of measuring the end-effector pose and convert it into joint values, one can directly use the image for control. Visual servoing techniques are very effective since they close the control loop on the vision sensor, which gives a direct view of the Cartesian space. This yields a high robustness to robot calibration errors. Indeed, these errors only appear in a Jacobian matrix but not in the regulated error. Essentially, these techniques generate a Cartesian desired velocity which is converted into joint velocities by the inverse Jacobian. Hence, one can translate such techniques to parallel mechanisms. It should even be rather easier than in the serial case, since the inverse Jacobian of a parallel mechanism is usually analytical. Visual servoing techniques have been applied to the control of parallel mechanisms with a reduced number of degrees of freedom in [START_REF] Koreichi | Visual servo control of a parallel manipulator for assembly tasks[END_REF][START_REF] Kallio | Threedimensional position control of a parallel micromanipulator using visual servoing[END_REF].

A novel approach However, these previous two ways consist solely in a simple adaptation of now classical control schemes, which, although probably very efficient, are not very innovative. Therefore, a novel third way to use vision, which gathers the advantages of redundant metrology and of visual servoing and avoids most of their drawbacks was presented in [START_REF] Andreff | Vision-based control of a Gough-Stewart parallel mechanism using legs observation[END_REF]. Indeed, adding redundant sensors is not always technically feasible (think of a spherical joint) and always requires either that the sensors are foreseen at design stage or that the mechanism is physically modified to install them after its building. Anyhow, there are then additional calibration parameters in the kinematic model and one needs to estimate them in order to convert redundant joint readings into a unit vector expressed in the appropriate reference frame. Moreover, observing the end-effector of a parallel mechanism by vision may be incompatible with its application. For instance, it is not wise to imagine observing the end-effector of a machining tool. On the opposite, it should not be a problem to observe the legs of the mechanism, even in such extreme cases. Thereby one would turn vision from an exteroceptive sensor to a somewhat more proprioceptive sensor. This brings us back to the redundant metrology paradigm. Extending the idea of vision as a proprioceptive sensor to its limit, we propose in this paper a visual servoing scheme which allows to control a Gough-Stewart parallel robot [START_REF] Gough | Universal tyre test machine[END_REF][START_REF] Stewart | A platform with six degrees of freedom[END_REF] (Figure 1) without using any joint sensor information. This contribution seems especially relevant to the control of parallel robots that are hard to instrument (for instance, hydraulically actuated ones) or that have large displacements (for instance, large telescopes positioning systems). Moreover, it will be seen that such a technique is easy to implement, on the opposite to the visual servoing of non-instrumented serial robots [START_REF] Marchand | Controlling an uninstrumented manipulator by visual servoing[END_REF] where tedious programming was necessary. The remainder of the paper is the following. Section 2

Vision-based kinematics

Consider the hexapod in Figure 1. It has 6 legs of varying length q i , i ∈ 1..6, attached to the base by spherical joints located in points A i and to the moving platform (end-effector) by spherical joints located in points B i . The inverse kinematic model of such an hexapod is given by ∀i ∈ 1..6,

q 2 i = ---→ A i B i T ---→ A i B i (1)
expressing that q i is the length of vector ---→ A i B i . This model can be expressed in any Euclidean reference frame. Hence, it can be expressed in the base frame R b , in the end-effector frame R e or in the camera frame R c . In the remainder, the camera reference frame will be used and denoted by a left upper-script. According to [START_REF] Andreff | Vision-based control of a Gough-Stewart parallel mechanism using legs observation[END_REF] and assuming a calibrated camera, one can express the vision-based kinematics of the hexapod expressed in the camera frame:

q i c u i = c R e e B i + c t e -c A i (2) q = c J inv c c τ c (3) with c J inv c = -   c u T 1 ( c A1× c u 1 ) T . . . . . . c u T 6 ( c A6× c u 6 ) T   (4)
where c τ c is the Cartesian velocity of the camera frame, considered as attached to the base frame and moving with respect to a fixed end-effector, expressed in itself and c u i , i = 1..6 are the unit vectors giving the pointing direction of each leg in the camera frame. Under the assumption that the legs are cylinders, those vectors can be easily detected as the intersection of the two cylinder edges in the image, while tracking such edges is rather easy [START_REF] Marchand | Feature tracking for visual servoing purposes[END_REF].

Visual servoing of the platform

In this section, the control problem is addressed: from a given configuration of the hexapod legs observed by a camera attached to the base, how to reach a desired configuration ?

Visual servoing is based on the so-called interaction matrix L T [START_REF] Chaumette | La commande des robots manipulateurs[END_REF] which relates the instantaneous relative motion T c = c τ c -c τ s between the camera and the scene, to the time derivative of the vector s of all the visual primitives that are used through:

ṡ = L T (s) T c (5)
where c τ c and c τ s are respectively the kinematic screw of the camera and the scene, both expressed in R c . Then, one achieves exponential decay of an error e(s, s d ) between the current primitive vector s and the desired one s d using a proportional linearizing and decoupling control scheme of the form:

T c = -λ LT + (s) e(s, s d ) (6)
where T c is used as a pseudo-control variable.

Here also, we will need to define a visual primitive, then form an error between its current value and its desired one, then relate in some way its time derivative to the actuation, and finally find a control relation between the error and the actuation.

Visual primitive and error

As foreseen above, the unit vectors c u i , i = 1..6 will be used as visual primitives. The visual primitives being unit vectors, it is theoretically more elegant to use the geodesic error rather than the standard vector difference. Consequently, the error grounding the proposed control law will be

e i = c u i × c u di (7)

Interaction matrix

With the same convention as in (3), one has [START_REF] Andreff | Vision-based control of a Gough-Stewart parallel mechanism using legs observation[END_REF] the following interaction matrix for each leg

ċu i = 1 q i M T i c τ c (8)
M T i = -I 3 -c u i c u T i I 3 -[ c A i + q i c u i ] × (9)
where M T i is 3 × 6 and is obviously of rank 2. An interaction matrix M T can then be obtained by stacking M T i , i = 1..6. However, it is, in our opinion, an open question whether M shall or shall not be considered as an interaction matrix. Indeed, in visual servoing the various visual primitives are the image projections of objects in space that are rigidly linked to each other, while, here, each of the legs is in relative motion with respect to the other ones. Nevertheless, effective control can be derived as shown in the following section.

Control law

Let us choose a control such that E = (e T 1 , ..., e T 6 ) T decreases exponentially, i.e. such that

Ė = -λE (10)
Then, introducing [START_REF] Gough | Universal tyre test machine[END_REF] the combination of ( 7), ( 8) and [START_REF] Gogu | Fully-isotropic T3R1-type parallel manipulator[END_REF] gives

N T i = -[ c u di ] × M T i , N T = (N 1 , ..., N 6 ) T and ∆(q) =   1 q 1 I3 . . . 1 q 6 I3   , ∆ -1 (q) = q1I3 . . . q6I3 (
∆(q)N T c τ c = -λE (12)
A control law using the joint sensor can be derived, giving the Cartesian control velocity:

c τ c = -λ N T + ∆ -1 (q)E ( 13
)
which can be transformed into the admissible control joint velocities using ( 3)

q = -λ c J inv c N T + ∆ -1 (q)E ( 14
)
where the hat means that only an estimate can be used.

Usually, in visual servoing schemes, people either choose either to estimate the interaction matrix at each iteration using the latest measurements or to estimate it only once at the desired configuration. Following this idea, we chose to feed the interaction matrix with the measured c u i 's at each iteration. However, since the joint values appear marginally in ( 8) and ( 9), we can introduce a control scheme which does not make any use of the joint values by using the median joint values (i.e. we replace q i with q i med = (q imax + q imin )/2:

q = -λ c J inv c N T + |q=q med ∆ -1 (q med )E ( 15
)
As early stated by Weiss et al. [START_REF] Weiss | Dynamic sensor-based control of robots with visual feedback[END_REF], the desired joint velocities can now be fed to an inner control loop closed around the joint sensors or directly sent in open loop to the actuators. In the latter case, the frame rate has to be high enough to cope with the actuators bandwidth. In practice, using standard off-the-shelf cameras, one can reach 100 images/second (i.e. 10 ms loop time), and with little extra effort, a 1 ms loop time can be attainable, see [START_REF] Gangloff | High speed visual servoing of a 6 DOF manipulator using multivariable predictive control[END_REF] for a 1kHz visual servoing of a serial robot using predictive control.

Results

A commercial DeltaLab hexapod was simulated,

such that b A 2k = R b cos(k π 3 +α) sin(k π 3 +α) 0 , b A 2k+1 = R b cos(k π 3 -α) sin(k π 3 -α) 0 , e B 2k = R e cos(k π 3 +β) sin(k π 3 +β) 0 , e B 2k+1 = R e cos(k π 3 -β) sin(k π 3 -β) 0 , k ∈ {0, 1, 2} with R b = 270mm, α = 4.25 • , R e =

Control validation

In all the simulations presented here and below, the initial configuration of the platform is the reference configuration where all the legs have minimal length. The goal configuration is obtained from this reference configuration by a translation by 10cm along the z axis of the platform (upward vertical) and a rotation of 15 around the x axis, thus reaching the workspace limit.

In a first simulation, the joint sensors are used for control according to [START_REF] Kim | Evaluation of a Cartesian parallel manipulator[END_REF]. Figure 2 shows that the errors on each leg converges exponentially to 0 (in the strict theoretical meaning). This does not prevent some coupling to appear in the transient phase, which also appears in the joint velocities evolution (Figure 4(a)). Figure 3(a) shows nevertheless that the desired endeffector pose is reached, as well as the desired image (Figure 3(b)). Noise was also added to the leg detection, as a random rotation of the interpretation planes defined by the optical center and the cylinder edges. Figure 4(b) shows that the control is rather robust to measurement errors. In a second simulation, the joint sensors are not used any more for control according to [START_REF] Koreichi | Visual servo control of a parallel manipulator for assembly tasks[END_REF]. Figure 5 to 7 show a similar behaviour as in the case where the joint sensors are used. The only slightly visible difference is that each component of the error in Figure 5(a) has a different convergence rate (i.e. the exponentials cross each other) while they had the same in Figure 2. This phenomenon is hence found again on the joint velocity curves (Figure 7(a)).

Conclusion

A fundamentally novel approach was proposed for controlling a parallel mechanism using vision as a proprioceptive sensor, replacing the standard joint sensors. Thus, such a control law can be used for noninstrumented parallel robots. It thus comes in complement to previous work on the vision-based control of non-instrumented serial robots. In a close future, this contribution shall be experimented. A careful attention will need be put on the image tracking of the legs. Since self-occlusions of the mechanism may appear, it will be necessary to deal with them, either by defining a vision system able to track the legs in any case (stereo-vision for instance) or by studying the robustness of the proposed control to occlusions. Moreover, removing the proprioceptive sensors disables any inner control loop devoted to servo the actual joint velocities onto the desired ones. This imposes that the visual feedback should have a bandwidth compatible with the robot dynamics, which seems attainable with standard off-the-shelf cameras. Further away, we will try to extend this control law to other kinds of parallel robots.

Acknowledgment

This study was jointly funded by CPER Auvergne 2003-2005 program and by the CNRS-ROBEA program through the MP2 project.

Figure 1 :

 1 Figure 1: A Gough-Stewart platform observed by a camera with short focal length.

  195mm, β = 5.885 • and the legs range are [345mm, 485mm].

Figure 2 :Figure 3 :

 23 Figure 2: Control using joint sensors: (a) Errors on each leg e T i e i . (b) Sum of squared errors E T E.

Figure 4 :

 4 Figure 4: Control using joint sensors: (a) Joint velocities. (b) Robustness to noise : sum of squares of the errors E T E with a noise amplitude of 0 deg, 0.01 deg, 0.05 deg and 0.1 deg.

Figure 5 :Figure 6 :

 56 Figure 5: Control without using joint sensors: (a) Errors on each leg e T i e i . (b) Sum of squared errors E T E.

Figure 7 :

 7 Figure 7: Control without using joint sensors: (a) Joint velocities. (b) Robustness to noise : sum of squares of the errors E T E with a noise amplitude of 0 deg, 0.01 deg, 0.05 deg and 0.1 deg.


Nicolas Andreff
email: nicolas.andreff@ifma.fr

Philippe Martinet
email: philippe.martinet@lasmea.univ-bpclermont.fr

VISUALLY SERVOING A GOUGH-STEWART PARALLEL ROBOT ALLOWS FOR REDUCED AND LINEAR KINEMATIC CALIBRATION

Keywords: parallel robot, visual servoing, redundant metrology, kinematic calibration

This paper focuses on the benefits of using computer vision to control a Gough-Stewart parallel robot. Namely, it is recalled that observing the legs of such a mechanism with a calibrated camera, thus following the redundant metrology paradigm, simplifies the control law. Then, we prove in this paper that such a control law depends on a reduced set of kinematic parameters (only those attached to the geometry of the robot base) and that these parameters can be obtained by solving a linear system. Moreover, we show that the camera can be calibrated without much experimental effort, simply using images of the robot itself. All this means that setting up the control system consists only in placing the camera in front of the robot.

INTRODUCTION

Parallel mechanism are such that there exist several kinematic chains (or legs) between their base and their end-effector. Therefore, they may exhibit a better repeatability [START_REF] Merlet | Parallel robots[END_REF] than serial mechanisms but not a better accuracy [START_REF] Wang | On the accuracy of a Stewart platform -Part I : The effect of manufacturing tolerances[END_REF], because of the large number of links and passive joints. There can be two ways to compensate for the low accuracy. The first way is to perform a kinematic calibration of the mechanism and the second one is to use a control law which is robust to calibration errors.

There exists a large amount of work on the control of parallel mechanisms1 . In the focus of attention, Cartesian control is naturally achieved through the use of the inverse Jacobian which transforms Cartesian velocities into joint velocities. It is noticeable that the inverse Jacobian of parallel mechanisms does not only depend on the joint configuration (as for serial mechanisms) but also on the end-effector pose.

Consequently, one needs to be able to estimate or measure the latter. As far as we know, all the effort has been put on the estimation of the end-effector pose through the forward kinematic model and the joint measurements. However, this yields much trouble, related to the fact that in general, there is no closed-form solution to the forward kinematic problem. Hence, one numerically inverts the inverse kinematic model, which is analytically defined for most of the parallel mechanisms. However, it is known [START_REF] Merlet | An algorithm for the forward kinematics of general 6 d.o.f. parallel manipulators[END_REF][START_REF] Husty | An algorithm for solving the direct kinematics of general Gough-Stewart platforms[END_REF] that this numerical inversion requires high order polynomial root determination, with several possible solutions (up to 40 real solutions for a Gough-Stewart platform [START_REF] Dietmaier | The Stewart-Gough platform of general geometry can have 40 real postures[END_REF]). Much of the work is thus devoted to solving this problem accurately and in real-time (see for instance [START_REF] Zhao | Direct displacement analysis of parallel manipulators[END_REF]), or to designing parallel mechanisms with analytical forward kinematic model [START_REF] Kim | Evaluation of a Cartesian parallel manipulator[END_REF][START_REF] Gogu | Fully-isotropic T3R1-type parallel manipulator[END_REF]. One of the promising paths lies in the use of the so-called metrological redundancy [START_REF] Baron | The on-line direct kinematics of parallel manipulators under joint-sensor redundancy[END_REF], which simplifies the kinematic models by introducing additional sensors into the mechanism and thus yields easier control [START_REF] Marquet | Contribution à l'étude de l'apport de la redondance en robotique parallèle[END_REF].

Visual servoing [START_REF] Espiau | A New Approach To Visual Servoing in Robotics[END_REF]Christensen and Corke, 2003) is known to robustify the Cartesian control of serial and mobile robots, with techniques ranging from position-based visual servoing (PBVS) [START_REF] Martinet | Vision based control law using 3d visual features[END_REF] (when the pose measurement is explicit) to image-based visual servoing (IBVS) [START_REF] Espiau | A New Approach To Visual Servoing in Robotics[END_REF]) (when it is made implicit by using only image measurements). Visual servoing techniques are very effective since they close the control loop on the vision sensor, which gives a direct view of the Cartesian space. This yields a high robustness to robot calibration errors. Indeed, these errors only appear in a Jacobian matrix but not in the regulated error.

Essentially, visual servoing techniques generate a Cartesian desired velocity which is converted into joint velocities by the robot inverse Jacobian. Hence, one can translate such techniques to parallel mechanisms as in [START_REF] Koreichi | Visual servo control of a parallel manipulator for assembly tasks[END_REF][START_REF] Kallio | Threedimensional position control of a parallel micromanipulator using visual servoing[END_REF] by observation of the robot end-effector and the use of standard kinematic models. It is rather easier than in the serial case, since the inverse Jacobian of a parallel mechanism has a straightforward expression. Moreover, for parallel mechanisms, since the joint velocities are filtered through the inverse Jacobian, they are admissible, in the sense that they do not generate internal forces. More precisely, this is only true in the theoretical case. However, if the estimated inverse Jacobian used for control is close enough to the actual one, the joint velocities will be closely admissible, in the sense that they do not generate high internal forces.The only difficulty would come from the dependency of the inverse Jacobian to the Cartesian pose, which would need be estimated, but, as stated above, vision can also do that [START_REF] Dementhon | Model-based object pose in 25 lines of code[END_REF][START_REF] Lavest | Do we really need an accurate calibration pattern to achieve a reliable camera calibration[END_REF] ! Notice that this point pleads for PBVS rather than IBVS of parallel mechanisms.

Nevertheless, the direct application of visual servoing techniques assumes implicitly that the robot inverse Jacobian is given and that it is calibrated. Therefore, modeling, identification and control have small interaction with each other. Indeed, the model is usually defined for control using proprioceptive sensing only and does not foresee the use of vision for control, then identification and control are defined with the constraints imposed by the model. This is useful for modularity but this might not be efficient in terms of accuracy as well as of experimental set-up time.

On the opposite, instead of having identification and control being driven by the initial modeling stage, one could have a model taking into account the use of vision for control and hence for identification. To do so, a new way to use vision, which gathers the advantages of redundant metrology and of visual servoing and avoids most of their drawbacks was presented in [START_REF] Andreff | Vision-based control of a Gough-Stewart parallel mechanism using legs observation[END_REF].

Indeed, adding redundant sensors is not always technically feasible (think of a spherical joint) and always requires either that the sensors are foreseen at design stage or that the mechanism is physically modified to install them after its building. Anyhow, there are then additional calibration parameters in the kinematic model and one needs to estimate them in order to convert redundant joint readings into a unit vector expressed in the appropriate reference frame. Moreover, observing the end-effector of a parallel mechanism by vision may be incompatible with its applica- tion. For instance, it is not wise to imagine observing the end-effector of a machining tool. On the opposite, it should not be a problem to observe the legs of the mechanism, even in such extreme cases. Thereby one would turn vision from an exteroceptive sensor to a somewhat more proprioceptive sensor. This brings us back to the redundant metrology paradigm.

With such an approach, the control is made easier by measuring a major part of the robot inverse Jacobian, reducing the number of kinematic parameters to be identified. We will show in this paper that these remaining parameters can be estimated by solving a linear system.

The remainder of the paper is the following. Section 2 recalls the vision-based control of the Gough-Stewart robot. Section 3 discusses the actual choice of vision for such a control. Section 4 presents the calibration procedure for the whole system. Finally, simulation results and conclusion are given respectively in section 5 and section 6.

VISION-BASED KINEMATICS

Consider the hexapod in Figure 1. It has 6 legs of varying length q i , i ∈ 1..6, attached to the base by spherical joints located in points A i and to the moving platform (end-effector) by spherical joints located in points B i . The inverse kinematic model of such an hexapod is given by ∀i

∈ 1..6, q 2 i = ---→ A i B i T ---→ A i B i (1)
expressing that q i is the length of vector ---→ A i B i . This model can be expressed in any Euclidean reference frame. Hence, it can be expressed in the base frame R b , in the end-effector frame R e or in the camera frame R c . Hereafter, the camera reference frame will be used and denoted by a left upper-script.

According to [START_REF] Andreff | Vision-based control of a Gough-Stewart parallel mechanism using legs observation[END_REF] and assuming a calibrated camera, one can express the vision-based kinematics of the hexapod expressed in the camera frame:

q i c u i = c R e e B i + c t e -c B i (2) q = c J inv c c τ c (3) with c J inv c = -   c u T 1 ( c A1× c u 1 ) T . . . . . . c u T 6 ( c A6× c u 6 ) T   (4)
where c τ c is the Cartesian velocity of the camera frame, considered as attached to the base frame and moving with respect to a fixed end-effector, expressed in itself and c u i , i = 1..6 are the unit vectors giving the pointing direction of each leg in the camera frame.

Then, one can derive a control law of the form:

e i = c u i × c u di (5) E = (e T 1 , ..., e T 6 ) T (6) P( c u i ) = I 3 -c u i c u T i (7) M T i = P( c u i ) [I 3 -[ c A i + q i c u i ] × ] (8) N T i = 1 q i [ c u di ] × M T i (9)
N T = (N 1 , ..., N 6 ) T (10) q = -λ c J inv c N T + diag(q)E (11)
where the hat means that only an estimate can be used and [] × denotes the antisymmetric matrix associated to the cross-product.

DISCUSSION

Here, the above control is discussed, with explicit regard to the sensing problem. Indeed, it does not absolutely imply that computer vision should be used for that.

Why vision should be used rather than joint sensors

There are three manners to measure or estimate the u i 's. The first one, which we discard of course immediately, is to estimate the end-effector pose with respect to the base by numerical inversion of the inverse kinematic model and then use (2) to obtain u i .

The second manner is to place joint sensors in the A i 's, so that they would deliver the pointing direction of the leg. This manner is valid since the u i 's would be measured and not estimated through a delicate numerical procedure as above. Nevertheless, it is, in our opinion, still not the correct manner. Indeed, a joint sensor delivers a value expressed in its own reference frame. To convert this value in the base frame would require either an extremely accurate assembly procedure or the identification of the relative orientation of each joint sensor frame with respect to the base frame. Moreover, additional joint offsets would need be identified.

c h e1 c h e1 c h e2 c h e2 c u
Since the leading vector of a leg is essentially a Cartesian feature, we chose to estimate it by vision. Indeed, vision is an adequate tool for Cartesian sensing, and, following [START_REF] Renaud | On vision-based kinematic calibration of a Stewart-Gough platform[END_REF], if vision is also chosen for calibration, this does not add extra calibration parameter. It will even be shown in Section 4 that using vision reduces the parameter set needed for control.

Cylindrical leg observation

Now the problem is to recover c u i from the leg observation. It may be somehow tedious, although certainly feasible, in the case of an arbitrary shape. Hopefully, for mechanical reasons such as rigidity, most of the parallel mechanisms are not only designed with slim and rectilinear legs, but, even better, with cylindrical shapes.

Except in the degenerated case where the projection center lies on the cylinder axis, the visual edge of a cylinder is a straight line (Figure 2). Consequently, it can be represented by its Binormalized Plücker coordinates [START_REF] Andreff | Visual servoing from lines[END_REF] in the camera frame. Let us note c h e1 and c h e2 the image projections of the two edges of a cylinder, that can be tracked using the results in [START_REF] Marchand | Feature tracking for visual servoing purposes[END_REF]. These two vectors are oriented so that they point from the cylinder revolution axis outwards. Then, their expression is related to the Binormalized Plücker Coordinates ( c u, c h, c h) of the cylinder axis (see Figure 3) by

image plane A c u c h c u × c h c h R θ c h e1 c h e2
c h e1 = -cos θ c h -sin θ c u × c h (12) c h e2 = + cos θ c h -sin θ c u × c h (13)
where

cos θ = √ c h 2 -R 2 / c h and sin θ = R/ c h, c h = c A × c u , c h = ( c A × c u)/ c h and R is the cylinder radius.
Then, it is easy to show that the leading vector c u of the cylinder axis, expressed in the camera frame,

writes c u = c h e1 × c h e2 c h e1 × c h e2 (14)
Notice that the geometric interpretation of this result is that c u is, up to a scale factor, the vanishing point of the two image edges, i.e. their intersection point in the image.

VISION-BASED CALIBRATION

As stated earlier in this paper, the vision-based control ( 2)-( 11) relies on the use of a calibrated camera and on some kinematic parameters. The classical approach for calibrating a camera is to use a calibration grid made of points [START_REF] Brown | Close-range camera calibration[END_REF][START_REF] Tsai | An efficient and accurate calibration technique for 3d machine vision[END_REF][START_REF] Faugeras | Camera calibration for 3d computer vision[END_REF][START_REF] Lavest | Do we really need an accurate calibration pattern to achieve a reliable camera calibration[END_REF]. However, in the present case, it is more pertinent to use the method proposed in [START_REF] Devernay | Straight lines have to be straight[END_REF]. Indeed, this method is based on the observation of a set of lines, without any assumption on their 3D structure. As can be seen in Figure 1, there are plenty of lines in the images observed by a camera placed in front of a Gough-Stewart parallel robot. Hence, the camera can be calibrated on-line without any experimental burden. Now, the only kinematic parameters the control law depends on are the attachment points of the legs onto the base expressed in the camera frame ( c A i ) and on the joint offsets. The latter appear in two places : under the form c A i + q i c u i in ( 8) and as a gain in (9). Considering the order of magnitude of c A i and q i , one can neglect small errors on the joint offsets in (8). Moreover, since the joints are prismatic it is easy to measure their offsets manually with a millimetric accuracy. This is also highly sufficient to ensure that the gain in ( 9) is accurate enough. This means that, as far as control is concerned, one only needs to identify the attachment points onto the base, but there is no need for identifying the other usual kinematic parameters: attachment points onto the mobile platform and joint offsets.

In [START_REF] Renaud | On vision-based kinematic calibration of a Stewart-Gough platform[END_REF], a calibration procedure was proposed, using legs observation, where, in a first step, the points A i were estimated in the camera frame, then in a second step were expressed in the base frame, and finally the others kinematic parameters where deduced. Essentially, only the first step of this procedure is needed.

This step is reformulated here in a more elegant way, using the Binormalized Plücker Coordinates of the cylinder edges ( 12), and minimizing an imagebased criterion.

Assuming that the attachment point A i is lying on the revolution axis of the leg and referring again to Figure 3, one obtains, for any leg i and robot configuration j, c h e1 i,j

T c A i = -R (15)
c h e2 i,j T c A i = -R (16)
Stacking such relations for n c robot configurations yields the following linear system

        c h e1 i,1 T c h e2 i,1 T . . . c h e1 i,nc T c h e2 i,nc T         c A i =       -R -R . . . -R -R       (17)
which has a unique least-square solution if there are at least two configurations with different leg orientations.

The calibration procedure is hence reduced to a strict minimum. To improve its numerical efficiency, one should only take care to use robot configurations with the larger angles between each leg orientation. However, since the c A i only appear in the interaction matrix, they do not require a very accurate estimation.

RESULTS

A commercial

R b cos(k π 3 -α) sin(k π 3 -α) 0 , e B 2k = R e cos(k π 3 +β) sin(k π 3 +β) 0 , e B 2k+1 = R e cos(k π 3 -β) sin(k π 3 -β) 0 , k ∈ {0, 1, 2} with R b = 270mm, α = 4.25 • , R e = 195mm,

Image noise

It is not immediate to model realistically the effect of image noise on detecting the visual edges of a cylinder. One can imagine to use the (ρ, θ) representation of an image line and to add noise to these two components. However, it is not certain that the two noise components are uncorrelated. Alternately, one can also determine the virtual intersections of the visual edge with the image border and to add noise to these intersections [START_REF] Bartoli | The 3d line motion matrix and alignement of line reconstructions[END_REF]). An alternative model is presented here, which takes advantage of the fact that an image line is essentially a unit vector. Thus, image noise will necessary result into a rotation of this unit vector. Consequently, one needs to define a random rotation matrix, that is to say a rotation axis and a positive rotation angle. Preliminary tests showed that simply taking this axis as a uniformly distributed unit vector and this angle as a uniformly distributed positive scalar gives a realistic behavior.

This noise model has for advantages that it is easy to implement, it does not depend on the simulated image size, and is parametered by a single scalar (i.e. the maximal amplitude of the rotation angle).

To give an idea of how to choose this maximal amplitude, an error of about ± 1 pixel on the extremities of a 300 pixel-long line segment yields a rotation angle of approximately 0.05 degree.

Calibration validation

In order to quantify the calibration procedure, the simulated robot was calibrated by moving it into its 64 extremal configurations (i.e. each leg joint is extended to its lower limit then to its upper limit). In each configuration, the visual edges of each leg were generated from the inverse kinematic model and added noise as described above, with a maximal amplitude of 0.05 degree. This calibration procedure was repeated 100 times. As a result, the median error on each attachment point is less than 1 mm.

Realistic simulation

Now, a more realistic simulation is presented where the calibration is first performed using the 64 extremal configurations, then control is launched using the calibrated values. Noise is added as above during image detection, with amplitudes of 0.01, 0.05 and 0.1 degree.

It is noticeable that the calibration errors (in terms of maximal error on each of the component of each attachment point) is respectively of 0.5, 1.4 and 10 mm.

Graphically (Figure 4), the sum of the errors on each leg E T E still decreases. Additionally, the median positioning error of the convergence tails in Figure 4 are respectively 0.1, 0.6 and 1.1 mm while the maximal error are 0.6, 1.9 and 3 mm.

Hence, the overall calibration-control process seems rather robust to image measurement errors.

CONCLUSION

A fundamentally novel approach was proposed in [START_REF] Andreff | Vision-based control of a Gough-Stewart parallel mechanism using legs observation[END_REF] for controlling a parallel mechanism using vision as a redundant sensor, adding a proprioceptive nature to the usual exteroceptive nature of vision. The present paper shows that such a method not only simplifies the control law, but also reduces the experimental effort.

Indeed, on the opposite to standard Cartesian control, no numerical inversion of the inverse kinematic model is required. Moreover, the kinematic parameter set which is effectively used during vision-based control is smaller than the one used for Cartesian control. Additionally, the kinematic calibration is turned linear with the vision-based approach.

From a practical point of view, setting-up such a control is made easier than any other ones. Indeed, on the opposite to most of the visual servoing approaches, there is no need to mount a visual target onto the robot end-effector, since the visual targets are the very robot legs. As far as calibration is concerned again, the calibration of the camera can be done with the same observation, as well as the kinematic calibration, which does not require any more any specific set-up.

Of course, all these benefits can only be obtained to a higher cost in software integration and development, which is not completely terminated at the present time, preventing us from showing experimental results.

Figure 1 :

 1 Figure 1: A Gough-Stewart platform observed by a camera with short focal length.

Figure 2 :

 2 Figure 2: Projection of a cylinder in the image.

Figure 3 :

 3 Figure 3: Construction of the visual edges of a cylinder: the cylinder is viewed from the top.

  DeltaLab hexapod was simulated, such that b A 2k = R b cos(k π 3 +α) sin(k π 3 +α) 0 , b A 2k+1 =

Figure 4 :

 4 Figure 4: Robustness to noise : sum of squares of the errors E T E with a noise amplitude of 0 deg, 0.01 deg, 0.05 deg and 0.1 deg.

  β = 5.885 • and the legs range are [345mm, 485mm].

See http://www-sop.inria.fr/coprin/equipe/merlet for a long list of references.

ACKNOWLEDGMENT

This study was jointly funded by CPER Auvergne 2003-2005 program and by the CNRS-ROBEA program through the MP2 project.


Sten Grüner
email: sten.gruener@de.abb.com

Andreas Burger
email: andreas.burger@de.abb.com

Hadil Abukwaik
email: hadil.abukwaik@de.abb.com

Sascha El-Sharkawy

Klaus Schmid
email: schmid@sse.uni-hildesheim.de

Tewfik Ziadi
email: tewfik.ziadi@lip6.fr

Anton Paule
email: anton.paule@fzi.de

Felix Suda
email: felix.suda@scopeset.de

Alexander Viehl
email: alexander.viehl@fzi.de

Demonstration of a Toolchain for Feature Extraction, Analysis and Visualization on an Industrial Case Study

Keywords: PLE, Feature Mining, Holistic Toolchain, Industrial Case Study

Transforming a clone-and-own (i.e. new product variants are created by copying and modifying existing artifacts) code structure and development process to a Software Product Line Engineering (PLE) approach is a tedious and error-prone task. Holistic tool support for such a process is highly desirable, especially to lower efforts and to speed up the transformation. Unfortunately, such a holistic toolchain for reverse engineering of variability, supporting variant-centric and platform-centric extraction approaches is not available. In this paper, we present a toolchain covering the first steps for moving a clone-and-own product development to a PLE approach. We validate the first prototype of the toolchain on a case study consisting of industrial firmware for smart motor controllers and we show that even this early prototype reduces time and effort for moving to a configurable platform approach in the sense of PLE.

I. INTRODUCTION

In the last three decades, Software Product Line Engineering (PLE) has become famous as an approach for reducing timeto-market of new products as well as development and maintenance costs of highly variable products. Additionally, the quality of the software increases by adopting PLE techniques as Fogdal et al. in [START_REF] Fogdal | Ten years of product line engineering at danfoss: lessons learned and way ahead[END_REF] highlighted for a motor controller platform. In the academic field, there is plenty of knowledge regarding PLE and practices around it, such as the Product Line Hall of Fame [START_REF] Weiss | Software product line hall of fame[END_REF], case studies, books or experiences presented at various PLE conferences. Nevertheless, adopting a specific PLE approach or pattern in industrial practice is not a trivial task and it requires a long adoption time.

One of the big drawbacks, when establishing a new product line approach in the context of existing software, is the need for holistic tool support covering all tasks needed to step-wise progress from a clone-and-own (i.e. new product variants are created by copying and modifying existing artifacts) development scheme to a PLE approach (e.g. as proposed in [?]). Such an integrated toolchain would lower the hurdle for starting the transformation process and give a company a starting point and the confidence for the migration. For sure, an integrated approach addresses a number of challenges like the step from clone-and-own to a product line strategy for new products, the discovery of hidden or not explicitly documented mechanisms to configure customer-driven variability, and the integration of an approach for selecting dedicated customer features per product variant. Facing and coping with these challenges, the aforementioned tool support rises confidence for moving to PLE approach on management level because the time for the transformation process may significantly be reduced. Likewise, the return-of-invest for adopting the PLE approach will be materialized earlier than before.

In this paper, we present the prototype of a holistic toolchain which supports a company in taking the first steps in the sketched migration process. The toolchain focuses on reverse engineering of variability by combining tools for analyzing an existing configurable software platform (platform-centric approach) with tools for analyzing currently available product variants (variant-centric approach). In order to get tangible and expressive results, the toolchain includes several visualizations of the results, coming from a management-oriented overview to dedicated technical feature-driven results. We performed a first validation of the toolchain based on an industrial firmware of smart motor controllers. The first results show the ability to reduce the time and effort for migrating a legacy code base into a PLE-ready code base.

The remainder of this paper is structured as follows: Section II discusses the state of the art and related work. Section III describes the used definition of software features, the industrial case study and the derived usage scenarios for the toolchain. Section IV introduces the toolchain and a typical workflow. Section V details the toolchain building blocks. In Section VI we present our initial evaluation results and close the paper with a summary and future work in Section VII.

XXXX ©2019 XX

II. RELATED WORK

In this paper, we present a holistic toolchain for reverse engineering of variability to support the migration process of legacy software systems to a PLE approach. The technologies used for the presented analysis are not completely novel. However, the possibility of combination of different variability extraction approaches and tools is unique as no comparable toolchain for transformation and migration tasks exists today.

Various tools have been developed to analyze different aspects of variability information, like [START_REF] Nadi | Mining kbuild to detect variability anomalies in Linux[END_REF]- [START_REF] Kästner | KconfigReader[END_REF] for mining variability information from the Linux build system. Other tools extract the variability information from C/C++-based code files [START_REF] Sincero | Efficient extraction and analysis of preprocessor-based variability[END_REF], [START_REF]TypeChef[END_REF]. Moreover, there are tools that detect variabilityintroduced dead code [START_REF] Tartler | Feature consistency in compile-time-configurable system software: facing the linux 10,000 feature problem[END_REF], family-based type checking and variable control-flow graphs [START_REF] Liebig | Scalable analysis of variable software[END_REF], analysis of feature scattering across code files [START_REF] Passos | A study of feature scattering in the linux kernel[END_REF], or continuous on-the-fly identification of feature locations in committed code blocks [START_REF] Abukwaik | Semi-automated feature traceability with embedded annotations[END_REF]. While we reuse some of the extraction capabilities, we apply a completely different analysis as we reverse engineer variability information to introduce variability management.

In general, there exist two conceptually different strategies for reverse engineering of variability information of legacy systems: On the one hand, variant-centric approaches are used for mining variants to introduce a configurable platform. Thus, it is necessary to detect common and variable code parts and to introduce variability to make these code parts configurable. Examples are BUT4Reuse [START_REF] Martinez | Bottom-up technologies for reuse: Automated extractive adoption of software product lines[END_REF]. On the other hand, platformcentric approaches for analyzing undocumented variability in SPLs which was not available before. Examples here are, from Nadi et al. [START_REF] Nadi | Where do configuration constraints stem from? an extraction approach and an empirical study[END_REF] which reverse engineer a variability model from code artifacts. This approach was extended for numerical features/conditions with fixed ranges in [START_REF] Krafczyk | Reverse engineering code dependencies: Converting integer-based variability to propositional logic[END_REF]. KernelHaven [START_REF] Kröher | Kernelhaven -an experimentation workbench for analyzing software product lines[END_REF] used the extended approach to reverse engineer variability dependencies. In this work, the bottom-up and top-down approaches are combined to analyze a product line that uses cloning and configuration techniques to realize variants.

Most of the above-mentioned tools focus on one specific approach or aspect of the analysis and have limited possibilities to interface other tools enhancing their results. Here we present a holistic toolchain based on various multi-purpose tools to address the problem of product line migration in an integrated fashion.

III. INDUSTRIAL CASE STUDY

A. Feature Definition and Kinds of Feature Tracing

The definition of a "software feature" depends on the considered use case of the software product line [START_REF] Beuche | Software product line engineering with feature models[END_REF]. After discussions with domain experts, we identified two types of features within the software system under consideration:

• Front-end features. This customer-facing type of features defines the functionality that is directly visible to an enduser and can, for example, be accessed via configuration tools of the product. These features provide direct customer value, therefore, their emergence and maintenance are in the focus of product management.

• Back-end features. This developer-facing type of features is usually not directly visible to the customer and they depend on (1) the selection of the front-end features and (2) the product-internal software and hardware architecture, e.g., the currently selected hardware platform, operational system, used compiler, etc. Typically, these features are maintained by the software development team.

Both feature types can be traced by using different techniques depending on the intended variability model, e.g., compile-time variability, link-time variability, or runtime variability. In our case, we differentiate between in-file-level (i.e., a subset of lines within a source code file) and file-level (i.e., a complete source file) feature annotations and we accordingly consider the following possibilities for their tracing:

• File-level and in-file-level embedded annotations. Storing the localization information along with the source code is the usage of embedded annotations. One possible format that we follow in the work was proposed in [START_REF] Ji | Maintaining feature traceability with embedded annotations[END_REF].

Combining feature annotations and source code allows storing and evolving both using the same tools and data sources, e.g., Integrated Development Environment (IDE) and Version Control System (VCS). The embedded annotations have no semantics in used programming language. • File-level tracing. In case link-time variability mechanisms are used, the build chain may conditionally include specific source files/libraries that are linked into the compiled executable. The feature selection information is therefore stored in the build toolchain and its specific artifacts, e.g., Makefiles or configuration scripts. • In-file-level preprocessor-based tracing. In case of utilization of some programming languages, e.g. C/C++, preprocessor directives can be used to mark source code blocks belonging to a specific software feature. This tracing type is a hybrid of the previous two types. In analogy to the annotation-based localization, it allows building a so-called 150% model containing all variantspecific implementation artifacts in one source file (e.g. a C/C++ source file with preprocessor directives). In contrast to embedded annotations, the precompiler flags have semantics within the programming language and can be configured by the build toolchain, i.e., the feature selection information is contained in build artifacts, while variability information is stored directly within the source files. Therefore, precompiler directives are usually mixed with file-level localization, s.t., a feature typically consists of files either fully included/excluded and source code blocks either activated/deactivated in the built variant.

In our case study and the feature analysis toolchain, we focus on locating and analyzing front-end features as well as finding dependencies between front-end and back-end features. Depending on the specific product family, a subset of those features has already been localized using file-level or even block-level precompiler based localization, other features are however not yet localized at all.

B. Case Study Description

For the case study, we use the firmware source code of a specific industrial motor controller (also called drive) product family consisting of about 1.2 MLoC of embedded C/C++ code. The code is compiled by a proprietary build chain to generate and compile the source code. Out of the one repository used for the case study, around twelve variants for different applications and hardware platforms of the motor controller can be compiled.

Therefore, the main non-functional requirements for the involved tools are the ability to parse C/C++ code, to process large code bases with >1 MLoC in a reasonable time and resource consumption, and to use/evaluate variability information that is contained in build toolchain artifacts.

In our previous work [START_REF] Burger | Finalist 2: Feature identification, localization, and tracing tool[END_REF], we defined the process of feature extraction to consist of feature identification (i.e., defining the feature name and its functionality), feature localization (i.e., mapping the feature to software engineering artifacts like source code blocks or files), and feature tracing (i.e., storing and documenting the localization information).

C. Usage Scenarios for the Feature Toolchain

Based on the feature tracing techniques that we introduced in Section III-A, we define the following scenarios for the proposed toolchain:

S1: Feature extraction without considering existing variant information. This scenario addresses the extraction of features out of unannotated source code without considering existing product variants. The advantage of such a scenario is its simplicity. That is, available pattern matching and Information Retrieval (IR) based tools might work on pure source code without build-specific information. However, it will probably be needed for precise extraction of information from a specific build toolchain (e.g., a compilation database in [START_REF] Burger | Finalist 2: Feature identification, localization, and tracing tool[END_REF]).

S2: Feature extraction combined with existing variant information. This scenario aims to extract features by comparing available variants, e.g., firmware variants. Such a comparison requires the extraction of variability information that is stored within the build toolchain, e.g., at least a list of compiled source files. Extraction scenarios S1 and S2 can also be combined, i.e., the features are first extracted without variant information and are cross-validated using variant information in a second step. Furthermore, considering built variants yields a mapping of available features to a specific variant.

S3: Feature visualization and metrics. In order to assess, to refine, and to monitor extracted features, there is a need for tools providing a user-friendly interface for feature annotations. Typical use cases are the visualization of feature locations across the build artifacts and the visualization of dependencies between different features for continuous feature tracing by software developers. Furthermore, a calculation of metrics on the level of features, files and folders (cf. Table 1 in [START_REF] Andam | Florida: Feature location dashboard for extracting and visualizing feature traces[END_REF]) is useful to monitor and accompany the feature evolution along the software development process. S4: Feature analysis. The analysis part of the toolchain is responsible for processing available feature localization information within the source code to discover feature dependencies and propose a feature hierarchy. One of the challenges is the consideration of the interplay between embedded annotations and preprocessor directives due to their different semantics. Ultimately, the discovered dependencies and presence conditions for features can be used as input to create a feature model, e.g., a feature tree.

IV. TOOLCHAIN OVERVIEW

In this section, we present an overview of the toolchain demonstrator for feature extraction, analysis, and visualization. We briefly describe a typical interaction sequence within the toolchain following the arrow numbers in Fig. 1 where arrows depict data flow between the tools and dashed lines represent planned, but not yet implemented functionality. The details for the invoked tools are provided in Section V.

All feature extraction scenarios described in Section III-C start with checking out the unannotated source code from a repository within the VCS into a location accessible by the build toolchain (arrow 1 ). This code contains some precompiler-based defines, but no embedded annotations.

For the specific feature extraction without considering existing variant information scenario, a set of keywords is manually extracted from the device product documentation that describes the user-facing features (arrow 2 ). Furthermore, the code is compiled (and especially preprocessed with C/C++ compiler) by the build toolchain for one variant in order to get a consistent code base (arrow 3 ). The results of compilation manifest in a build trace, a Clang compilation database, which contains the list of compiler invocations, i.e., the list of compiled source code files and active precompiler definitions. The build trace and the source code base are used for static code analysis by FINALIST 2 . It documents localized features by embedded annotations within the source code.

For the specific feature extraction with considering existing variant information scenario, the annotated code (arrow 4 ) is passed to the build toolchain that builds as many existing product variants as possible. The traces of the build chain are post-processed, s.t., only actually compiled files are sorted into the variant-specific folders. At this point, embedded annotations coming from the previous step are possibly replicated if some product variants share common source files. Folders containing relevant source files are now provided to BUT4Reuse (arrow 5 ), which extracts the similarities and differences between variants (details follow in the subsequent section). The extracted information is embedded into source code using annotations (arrow 6 , currently done manually).

Thus, the first two scenarios related to feature extraction that were mentioned in Section III-C are finished, and the extracted feature data can be saved back into the VCS (arrow 7 ).

The feature analysis scenario starts by importing the annotated source code artifacts into the respective tools: VEXA (arrow 8 ) and KernelHaven (arrow 9 ). The extracted feature dependency information is supposed to be used for the construction of a feature model (arrows 10 and arrow 11 ). Furthermore, feature dependency information extracted by BUT4Reuse can be included (arrow 12 ). We aim to combine feature dependency information in a feature model (arrow [START_REF] Abukwaik | Semi-automated feature traceability with embedded annotations[END_REF] ), e.g., as a pure::variants model.

Tools that are relevant for scenario S3 can operate on plain annotated source code as in case of FLOrIDA (arrow 14 ). Another possibility is to reuse information that is extracted by other tools as done by FeDeV. That is, it uses VEXA output containing the representation of the annotated source (arrow 15 ). Furthermore, it uses KernelHaven output that can be processed in the format of SQLite databases (arrow [START_REF] Krafczyk | Reverse engineering code dependencies: Converting integer-based variability to propositional logic[END_REF] ).

We expect an iterative usage of the toolchain, i.e., the represented sequence of tool invocations can be (partially) repeated covering several usage scenarios from Section III-C. One example is an iterative refinement of extracted software features following arrows 1 to 7 as described in [START_REF] Burger | Finalist 2: Feature identification, localization, and tracing tool[END_REF].

V. TOOL OVERVIEW

Here, we provide an overview of the individual building blocks of the demonstrator toolchain. We describe their functionality based on their respective input and output artifacts.

Many tools aim to provide an integrated solution covering multiple scenarios listed in Section III-C. Below, we list only the subset of tool functionalities that are currently used within the toolchain demonstrator (cf. solid lines in Fig. 1). Extending usage of the tool to cover their full functionality is part of future work (cf. dashed lines in Fig. 1).

A. FINALIsT 2 1) Input artifacts: Unannotated C/C++ code, list of keywords used for IR to localize the feature.

2) Functionality and user interaction: Assisted iterative feature extraction based on IR and static code analysis.

3) Output artifacts: Annotated C/C++ code. 4) Tool summary: The Feature Identification, Localization, and Tracing Tool (FINALIsT 2 ) [START_REF] Burger | Finalist 2: Feature identification, localization, and tracing tool[END_REF] supports developers by identifying, locating and documenting features within the source code. It uses an iterative semi-automated approach for feature mining by combining IR techniques and static code analysis. Within the sketched demonstrator in Fig. 1, FINALIsT 2 is used to assist developer or domain experts to identify and document features. Therefore, the tool uses an IR approach to identify a first source or header file as a starting point for the static code analysis. The IR search engine, Apache Lucene, needs a query, which can be extracted for example from a firmware manual or the user can define the query by himself. Once the starting point is identified, FINALIsT 2 starts a static code analysis by exploring incoming and outgoing dependencies of the current cluster (i.e., function calls, variable access, and file inclusion dependencies). The cluster can be then iteratively refined by the user.

B. BUT4Reuse

1) Input artifacts: Variant artifacts, e.g., annotated or unannotated C/C++ code for each variant.

2) Functionality and user interaction: Graphical overview and summary of features contained in each variant (feature list). Feature constraints (currently not used in the toolchain).

3) Output artifacts: Annotated C/C++ code containing annotations for discovered features (currently done manually).

4) Tool summary: Bottom-Up Technologies for Reuse (BUT4Reuse) [START_REF] Martinez | Bottom-up technologies for reuse: Automated extractive adoption of software product lines[END_REF], [START_REF] Martinez | Bottom-up adoption of software product lines: a generic and extensible approach[END_REF] is a generic and extensible framework implementing the different activities related to variability engineering. This mainly includes feature identification and naming, feature location, constraint discovering, and feature model synthesis. BUT4Reuse takes as input a collection of artifact variants and apply different algorithms for the mentioned activities. In this work, we used BUT4Reuse for the following two activities: 1) feature identification and naming where the objective is to analyze the input variants and identify the implementation fragments that implement the existing features. Naming aims to propose solutions for domain experts to name the identified features. 2) Feature model synthesis that extracts an organization of the identified features following the feature model notations.

To support each artifact type, BUT4Reuse uses the concept of adapter that processes the input artifact to be used by the different algorithms. In this paper and while we are considering the C/C++ source code of a collection of variants, we used a BUT4Reuse specific adapter that allows comparing the C/C++ source code of input variants. In addition to the different algorithms, BUT4Reuse is based on a set of visualization paradigms that guide the feature identification process. As shown in the next section, this visualization is useful for domain experts to name the identified feature and understand the variability inside the analyzed variants.

Summarizing the description of extraction tools (FINALIsT 2 and BUT4Reuse), it is worth mentioning that their performance was evaluated in terms of accuracy of identifying feature locations in Section VI-A.

C. VEXA 1) Input artifacts: Annotated C/C++ code containing embedded annotations and precompiler statements.

2) Functionality and user interaction: VEXA's functionality is invoked through Cypher queries, which can be executed interactively one at a time or as a complete analysis batch containing a multitude of queries. Interaction with the user is realized through a web front-end with visualization capabilities for presenting various aspects of the preprocessed source code artifacts, e.g., feature metrics and dependencies between preprocessor statements and embedded annotations.

3) Output artifacts: Graph database which stores the property graph that contains all feature localization information; discovered dependencies between preprocessor directives and embedded annotations.

4) Tool summary: The Variability Extraction and Analysis (VEXA) toolkit is a versatile collection of complementary procedures to help with many different tasks of variability extraction, feature analysis, visualization, and the calculation of user-defined metrics. Implemented as a plug-in for the "world's leading Graph Database" Neo4j1 , the VEXA toolkit leverages the powerful graph storage and processing capabilities of Neo4j to enable detailed dependency analyses of source code artifacts (e.g., #ifdef variability in C/C++ code) and reveal intricate feature connections across project artifacts along with graph visualization possibilities.

Tool's architecture rests upon two main pillars:

• The Property Graph Model. It is represented by a set of nodes and relationships that can both hold any number of attributes (key-value pairs) called properties. Nodes are entities in the graph that can be tagged with labels. Relationships always have a direction, a type, a start node, and an end node. They provide directed, named and semantically-relevant connections between two nodes. • The Cypher Query Language2 . Cypher is a declarative query language that allows for expressive querying and efficient manipulating of a property graph. The VEXA toolkit extends Cypher using the concept of user-defined procedures and functions to provide custom implementations of extraction and analysis procedures, which then can be called from Cypher directly.

The methodology behind VEXA pursues an iterative workflow, in which the user of the toolkit (a software developer or domain expert) specifies all analysis steps in a flexible way-tailored to his specific needs-using Cypher queries.

Context-specific Cypher queries can be employed to support the user in visualizing relevant dependencies between analyzed artifacts, e.g. feature locations and their relation to source files and code elements, in the form of graphs and tables. D. KernelHaven 1) Input artifacts: Annotated C/C++ code containing embedded annotations and precompiler statements.

2) Functionality and user interaction: Extraction of variability based on in-file annotations, no user interaction.

3) Output artifacts: Excel file and SQLite database containing relations between identified features. 4) Tool summary: KernelHaven3 [START_REF] Kröher | Kernelhaven -an experimentation workbench for analyzing software product lines[END_REF] is an experimentation workbench designed to simplify the realization of various analyses in the domain of static software product line analysis. Within the demonstrator, KernelHaven is used to extract variability information from C-preprocessor statements and annotations of C/C++ files and perform further analysis on this information. Thus, KernelHaven is used for the analysis of annotations as created by the FINALIsT 2 tool (cf. Section V-A) and optionally detects inconsistent, manually-written annotations. KernelHaven also provides a feature effect analysis as described in [START_REF] Nadi | Where do configuration constraints stem from? an extraction approach and an empirical study[END_REF] to compute variability dependency information among features from annotations and C-preprocessor statements. The result of the analysis is a Boolean precondition for each feature used in a code artifact, showing when its selection influences the product derivation.

A subsequent analysis component uses the dependency information to compute a dependency graph among the features. The graph contains directed edges between features and their dependent features. Annotations of the edges show whether the depending feature must not be selected (e.g., exclusive relationship), must be selected (e.g., requires relationship), or a propositional formula, if the precondition of the feature effect analysis cannot be split into one of the two previous cases.

E. FLOrIDA 1) Input artifacts: Annotated C/C++ code.

2) Functionality and user interaction: Graphical user interface to visualize and navigate through features that are scattered across the file system.

3) Output artifacts: -4) Tool summary: The Feature Location and Identification Dashboard (FLOrIDA) is used within the demonstrator for visualizing features, their metrics, and their dependencies. The tool has been thoughtfully discussed in [START_REF] Andam | Florida: Feature location dashboard for extracting and visualizing feature traces[END_REF].

F. FeDeV 1) Input artifacts: Graph database originating from VEXA tool or SQLite database originating from KernelHaven.

2) Functionality and user interaction: Interactive visualization and navigation of feature dependencies, feature annotations, and variation points within source files.

3) Output artifacts: Visualization of feature dependencies, variation points, and file systems as tables, graphs, and trees.

4) Tool summary: The Feature Dependency Visualization (FeDeV) tool is a visualization application for analysis results of KernelHaven and VEXA based on the TomSawyer Visualization framework 4 . The tool covers tabular lists for all data elements, some tree structures (e.g., to represent variation points within files, or showing a directory hierarchy) and interactive graphs to inspect the analysis results. The tool mainly focuses on visualizing the feature dependencies, feature annotations, and variation points. Each analysis source is mapped to an internal metamodel and instantiated during an import process. Currently, FeDeV is able to import, inspect and explore the analysis results of KernelHaven and VEXA.

The inspection workflow depends on the desired analysis. Dependencies of features are explored step-by-step. Starting with an empty graph, identified features can be added via table selection or a search function and composed to a featuredependency-graph. There are also dedicated commands to add features of incoming and outgoing dependencies to the graph as well as a path of dependencies up to related root features (i.e., independent features) of the selected context feature. In contrast, variation points and feature annotations detected by the VEXA can be inspected by browsing the analyzed file tree or a projection of feature annotations used by files.

A feature is represented as a node, showing its name, the number of incoming and outgoing dependencies, and a textual constraint (if defined). Dependencies are denoted as edges between feature nodes. Each dependency can have a constraint fragment, that is calculated from the actual feature's constraint and describes, which additional features must be selected to get a valid variant configuration.

VI. PRELIMINARY EVALUATION RESULTS

In the following, the preliminary results of the toolchain evaluation are discussed. Tools of the first workflow stage of feature extraction (scenarios S1 and S2) have been evaluated more thoughtfully as a foundation for the following steps.

A. Feature Extraction 1) FINALiST 2 : In previous work [START_REF] Burger | Finalist 2: Feature identification, localization, and tracing tool[END_REF], we performed no expert interviews and were able to achieve 98% accuracy on file-level (full files included in a feature) and 68% accuracy on in-file-level (certain lines of a file included in a feature) for a feature when compared to included precompiler definitions.

For this work, we performed an initial comparison of unassisted and tool-supported extraction of one randomly picked front-end and one back-end feature. The extraction was performed by non-experts in drive firmware development and cross-checked in expert interviews. The tool-assisted extraction was measured to be 69% quicker than comparable manual extraction for both features having a similar accuracy as confirmed by the development team.

2) BUT4Reuse: On the code base with 12 variants BUT4Reuse identified the scattered features that were covered as "blocks" with temporary IDs and represented them as a variant-feature matrix (see Fig. 2) where block "A" represents the code that is shared by every variant. Word cloud feature helped in recognizing and renaming the identified blocks.

In the code base, the tool identified 24 features out of around 80 front-end features. Worth to mention, the tool only finds differences between built variants, s.t., a feature identified by the tool typically contains multiple features as defined in Section III-A. Therefore, the generated insights are considered very useful and are used to validate/extend the extraction results from the FINALiST 2 tool as no additional information for feature identification like keywords is needed. B. Feature Analysis 1) VEXA: Feature analysis is performed by writing custom Cypher queries. In brevity, we present a small part of the overall analysis to demonstrate what is possible. After VEXA processed the code base, the property graph (a graph representation of the whole code base containing all embedded annotations, preprocessor directives, code statements, source files, etc.) is available and can be queried for information.

The first task was listing source code files containing specific feature annotations.The second task was defining a query to show which feature annotations contain which precompiler flags to find out and compare eventually double-annotations.

With the help of a Cypher expert, we were able to create queries to solve both tasks. The queries required intermediate steps that inserted additional information into the graph database. On one hand, it proved the flexibility of the tool. On the other hand, a good knowledge of Cypher language and VEXA property graph structure is needed to use it efficiently.

2) KernelHaven: By using KernelHaven we were able to identify multiple inconsistencies in manually injected code annotations, e.g., forgotten closing block annotation or typos. Furthermore, a specific dependency between a preprocessor-#ifdef and an embedded annotation was found and manually verified by tracing through the code base. The dependency stated that the disabling of the preprocessor statement removes all feature-annotated code blocks. A larger evaluation of feature dependencies in the code base is currently pending.

C. Feature Visualization and Metrics 1) FLOrIDA: Visualization possibilities of the FLOrIDA tool were discussed in [START_REF] Andam | Florida: Feature location dashboard for extracting and visualizing feature traces[END_REF].

2) FeDeV: We evaluated FeDeV on the output of both VEXA and KernelHaven. FeDeV provides different views like tables, trees, and graphs for manual inspection of extraction results. To simplify the visualization of large code bases, FeDeV provides a useful feature of predefined and userdefined filters to hide non-relevant features from such graphs.

Regarding VEXA results on the feature annotation and #ifdef block level, the coupling of annotated features and files is visualized graphically allowing to inspect the number of annotated code blocks and their impact on the source code file. Different layout options allow to re-center from featureto file-centric view easily. Results of KernelHaven analysis are rendered as dependency feature graphs providing color coding of edges and links provide additional information, e.g., to identify mandatory and optional features visually.

VII. SUMMARY AND FUTURE WORK

In this paper, we presented a prototype of a holistic toolchain for feature extraction, analysis, and visualization that combines variant-centric and platform-centric tools for reverse engineering of variability information. We were able to show first promising improvements in terms of reduced time and effort by iterative usage of the toolchain for feature extraction.

Future work can be separated into two dimensions: On one hand, improving the evaluation methodology by defining quantitative KPIs and performing a more reliable evaluation of the used case study. Furthermore, the case study can be extended to consider multiple clone-and-own repositories, e.g., to locate similar/same features across product groups to automatically generate 150% model files and eventually merge these into one.

On the other hand, the toolchain itself, single tool building blocks and their inputs/outputs can be improved, in particular:

• Improving precision of variant-centric feature extraction by pre-processing source files before analysis by means of a compiler or further tools, e.g., Coan 5 . • Use and combine constraint information from variantcentric extraction with feature constraints and relations. • Further steps towards a complete feature model extraction, e.g., by generating pure::variants feature models. • Merge tool results in one visualization view of feature location and dependencies between them. • A unified graphical or command-line interface.

Fig. 1 .

 1 Fig. 1. Toolchain Demonstrator Overview and Covered Usage Scenarios

Fig. 2 .

 2 Fig. 2. BUT4Reuse: The variant-feature matrix (names are obfuscated)

https://github.com/neo4j/neo4j

https://www.opencypher.org/

Publicly available at https://github.com/KernelHaven/KernelHaven

https://www.tomsawyer.com/products/visualization/

ACKNOWLEDGMENTS

This work is supported by the ITEA 3 15010 project REVaMP 2 funded by the German Federal Ministry of Education and Research (01IS16042A, 01IS16042B, 01IS16042F, 01IS16042H) as well as FUI the Ile-de-France region and BPI in France.