Guanglei Wu

Stéphane Caro
email: stephane.caro@ls2n.fr

Torsional Stability of a U-joint based Parallel Wrist Mechanism Featuring Infinite Torsion

Keywords: dynamic stability, parallel wrist mechanism, monodromy matrix, Floquet theory, torsional vibrations

In this paper, the dynamic stability problem of a parallel wrist mechanism is studied by means of monodromy matrix method. This manipulator adopts a universal joint as the ball-socket mechanism to support the mobile platform and to transmit the motion/torque between the input shaft and the end-effector. The linearized equations of motion of the mechanical system are established to analyze its stability according to the Floquet theory. The instable regions are presented graphically in various parametric charts.

Introduction

The parallel wrist mechanisms are intended for camera-orientating [START_REF] Gosselin | The Agile Eye: a high-performance three-degree-of-freedom camera-orienting device[END_REF], minimally invasive surgical robots [START_REF] Li | Design of spherical parallel mechanisms for application to laparoscopic surgery[END_REF] and robotic joints [START_REF] Asada | Kinematic and static characterization of wrist joints and their optimal design[END_REF], thanks to their large orientation workspace and high payload capacity. Besides, another potential application is that they can function as a tool head for complicated surface machining [START_REF] Wu | Design and transmission analysis of an asymmetrical spherical parallel manipulator[END_REF], where an unlimited torsional motion is desired to drive the cutting tools in some common material processing such as milling or drilling. For this purpose, a wrist mechanism [START_REF] Wu | Design and transmission analysis of an asymmetrical spherical parallel manipulator[END_REF] as shown in Fig. 1 was proposed with a number of advantages compared to its symmetrical counterparts, such as enhanced positioning accuracy [START_REF] Wu | Mobile platform center shift in spherical parallel manipulators with flexible limbs[END_REF], infinite rotation [START_REF] Asada | Kinematic and static characterization of wrist joints and their optimal design[END_REF], structural compactness and low dynamic inertia [START_REF] Wu | Dynamic modeling and design optimization of a 3-DOF spherical parallel manipulator[END_REF]. The design of the manipulator is simplified by using a universal (U) joint supported by an input shaft to generate infinite input/output rotational motion. On the other hand, the U joint suffers from one major problem, namely, it transforms a constant input speed to a periodically fluctuating one, which may induce vibrations and wear. This paper will investigate the dynamic stability problem, focusing on the aspect of the torsional stability.

To the best of the authors' knowledge, Porter [START_REF] Porter | A theoretical analysis of the torsional oscillation of a system incorporating a hooke's joint[END_REF] was the first to investigate this problem, where a single-degree-of-freedom linearized model was built to plot the stability chart by using the Floquet theory [START_REF] Floquet | Sur les équations différentielles linéaires à coefficients périodiques[END_REF]. Later, similar modeling approaches were adopted to derive the nonlinear equations for the stability analysis of U joint [START_REF] Porter | Non-linear torsional oscillation of a system incorporating a hooke's joint[END_REF][START_REF] Éidinov | Torsional vibrations of a system with hooke's joint[END_REF][START_REF] Asokanthan | Torsional instabilities in a system incorporating a hooke's joint[END_REF][START_REF] Chang | Torsional instabilities and non-linear oscillation of a system incorporating a hooke's joint[END_REF][START_REF] Bulut | Dynamic stability of a shaft system connected through a hooke's joint[END_REF]. Moreover, multi-shaft system consisting of multiple shafts interconnected via Hooke's joints can also be handled using the previous various approaches [START_REF] Zeman | Dynamik der drehsysteme mit kardagelenken[END_REF][START_REF] Kotera | Instability of torsional vibrations of a system with a cardan joint[END_REF]. Besides, lateral and coupled stability problem of the universal joint were studied [START_REF] Ota | Lateral vibrations of a rotating shaft driven by a universal joint: 1st report, generation of even multiple vibrations by secondary moment[END_REF][START_REF] Saigo | Self-excited vibration caused by internal friction in universal joints and its stabilizing method[END_REF][START_REF] Desmidt | Coupled torsion-lateral stability of a shaft-disk system driven through a universal joint[END_REF], too. According to the literature, the previous studies focus on single or multiple Ujoint mechanisms. On the other hand, a U joint working as a transmitting mechanism in a parallel mechanism has not received the attention, which will be the subject in this work. From the reported works, common approaches to analyze the stability problem of the linear/nonlinear dynamic model of the system include Floquet theory, Krylov-Bogoliubov method, Poincaré-Lyapunov method, etc.. As the relationship between the input and output shaft rotating speeds of the U joint is periodic, the Floquet theory will be an effective approach to analyze the stability problem, which will be adopted in this work.

This paper investigates the dynamic stability analysis problem of the wrist mechanism by means of a monodromy matrix method. To this end, a linear model consisting of input and output shafts interconnected via a Hooke's joint is considered, and the linearized equations of motion of the system are obtained. Numerical study is carried out to assess the system stability and the effects of the parameters. Instable regions are identified from various parametric charts.

Wrist Mechanism Architecture

Figure 1 depicts the wrist mechanism, an asymmetrical spherical parallel manipulator (SPM). The mobile platform is composed of an outer and inner rings connected to each other with a revolute joint, the revolute joint being realized with a revolve bearing. The orientation of the outer ring is controlled by two limbs in-parallel, and it is constrained by a fully passive leg that is offset from the center of the mobile platform to eliminate the rotational motion around the vertical axis. Through a universal joint, the decoupled rotation of the inner ring is generated by the center shaft, which also supports the mobile platform to improve the positioning accuracy.

The architecture of the wrist mechanism is displayed in Fig. 2. Splitting the outer ring and the two parallel limbs as well as the passive one, the remaining parts of the manipualtor can be equivalent to a U-joint mechanism. The center shaft is treated as the driving shaft and the inner ring is treated as a driven disk. The bend angle, i.e., the misalignment angle, is denoted by β , and the input/output angles are named as γ 1 /γ 2 , respectively.

Equation of Motion of Torsional Vibrations

The equations of motion for the U-joint mechanism shown in Fig. 2 is deduced via a synthetical approach [START_REF] Bulut | Dynamic stability of a shaft system connected through a hooke's joint[END_REF]. In accordance, the driving shaft and the driven disk are considered as two separate parts, as displayed in Fig. 3, where the cross piece connecting the input/output elements is considered as massless.

The equation of motion of torsional vibrations of the driving part can be written as

J I γ1 = -c 1 γ1 -k 1 γ 1 + M I (1)
where γ 1 is the rotational coordinate of J I , and M I is the reaction torque of the input part of the Hooke's joint. Moreover, k 1 and c 1 depict the torsional stiffness and viscous damper of the driving shaft, respectively. On the other hand, the driven part is under the effect of the reaction torque M O , for which the dynamic equation is written as where γ 2 is the rotational coordinate of J O , and k 2 , c 2 stand for the torsional stiffness and viscous damper of the driven shaft. Moreover, the relationship between the input torque and the output one of the Hooke's joint can be written as

c 2 γ2 + k 2 γ 2 = M O = -J O ( γ2 + ωo ) (2)
M O = M I η(t) , η(t) = cos β 1 -sin 2 β sin 2 (Ω 0 t + γ 1 ) (3)
where Ω 0 denotes the constant velocity of the driving shaft, henceforth, the following equations of motion are derived

J I γ1 + c 1 γ1 + k 1 γ 1 -η(t)c 2 γ2 -η(t)k 2 γ 2 = 0 (4) J O ( γ2 + ωo ) + c 2 γ2 + k 2 γ 2 = 0 (5) with ωo = η(t) γ1 + η(t)(Ω 0 t + γ1 ) (6)
Let τ be equal to Ω 0 t + γ 1 . Some dimensionless parameters are defined as follows:

Ω = Ω 0 k 1 /J I , ζ = c 1 2 √ k 1 J I , µ = c 2 c 1 , ν = J O J I , χ = k 2 k 1 = 1 η(τ) 2 (7)
Equations. ( 4) and ( 5) can be linearized and cast into a matrix form by discarding all the nonlinear terms, namely,

γ1 γ2 + 2ζ Ω -2µζ Ω η(τ) 2η (τ) -2ζ Ω η(τ) 2µζ Ω 1 ν + η 2 (τ) γ1 γ2 + 1 Ω 2 -χ Ω 2 η(τ) η (τ) -1 Ω 2 η(τ) χ Ω 2 1 ν + η 2 (τ) γ 1 γ 2 = 0 -η (τ) (8)
where primes denote differentiation with respect to τ, thus, Eq. ( 8) consists of a set of linear differential equations with π-periodic coefficients.

Dynamic Stability Analysis

The homogeneous parts of Eq. ( 8) should be considered sequentially to analyze the dynamic stability of the manipulator. Equation ( 8) can be expressed as::

γ γ γ + D γ γ γ + Eγ γ γ = 0 (9) with γ γ γ = γ1 γ2 T , γ γ γ = γ1 γ2 T , γ γ γ = γ 1 γ 2 T (10a) D = 2ζ Ω -2µζ Ω η(τ) 2η (τ) -2ζ Ω η(τ) 2µζ Ω 1 ν + η 2 (τ) (10b) E = 1 Ω 2 -χ Ω 2 η(τ) η (τ) -1 Ω 2 η(τ) χ Ω 2 1 ν + η 2 (τ) (10c)
which can be represented by a state-space formulation, namely,

ẋ(t) = A(t)x(t) (11)
with

x(t) = γ γ γ γ γ γ , A(t) = 0 2 I 2 -E -D (12)
whence A(t) is a 4 × 4 π-periodic matrix. According to Floquet theory, the solution to equation system [START_REF] Kotera | Instability of torsional vibrations of a system with a cardan joint[END_REF] can be expressed as

Φ Φ Φ(τ) = P(τ)e τR ( 13
)
where P(τ) is a π-periodic matrix and R is a constant matrix, which is related to another constant matrix H, referred to as monodromy matrix, with R = ln H/π. If the fundamental matrix is normalized so that P(0) = I 4 , then H = P(π). The eigenvalues λ i , i = 1, 2, 3, 4, of matrix H, referred to as Floquet multipliers, govern the stability of the system. The system is asymptotically stable if and only if the real parts of all the eigenvalues λ i are non-positive [START_REF] Chicone | Ordinary Differential Equations with Applications[END_REF]. Here, the matrix H is obtained numerically with the improved Runge Kutta Method [START_REF] Szymkiewicz | Numerical Solution of Ordinary Differential Equations[END_REF] with a step size equal to 10 -6 , and and its eigenvalues are calculated to assess stability of the system. The monodromy matrix method is a simple and reliable method to determine the stability of parametrically excited systems.

Numerical Study on Torsional Stability

This section is devoted to numerical stability analysis, where the stability charts are constructed on the Ω 0 -β and k 1 -β parametric planes to study the effect of parameters onto the system stability. From the CAD model of the robotic wrist, µ = 1, ν = 10, J I = 0.001 kg • m 2 , c 1 = 0.001 Nm/(rad/s).

Figure 4 depicts the stability chart Ω 0 -β to detect the instability of the U-joint mechanism, with a constant stiffness k 1 = 10 Nm/rad, where the dotted zones represent the unstable parametric regions. When the rotating speed Ω 0 of the driving shaft is lower than 11π rad/s, this system is always stable when the misalignment angle β is between 0 and 30 • . On the contrary, angle β should be smaller than 5 • to guarantee dynamic stability of the parallel wrist mechanism when Ω 0 is equal to 19π rad/s. Similarly, the influence of the torsional stiffness of the driving shaft and the misalignment angle to the stability is illustrated in Fig. 5, with the driving shaft speed Ω 0 = 19π rad/s. It is apparent that the higher the torsional stiffness of the input shaft, the more stable the parallel robotic wrist. The system is stable when k 1 > 25 Nm/rad.

Conclusion

This paper dealt with the dynamic torsional stability analysis of a parallel wrist mechanism that contains a universal joint. Differing from the symmetrical counterparts, the asymmetrical architecture of this robotic wrist ensures an infinite torsional movement of the end-effector under a certain tilt angle. This unique feature allows the wrist mechanism to function as an active spherical joint or machine tool head, with a simple architecture.

The stability problem of the wrist mechanism due to the nonlinear input-output transmission of the universal joint is studied, where a linear model consisting of input and output shafts interconnected via a Hooke's joint is considered. The linearized equations of motion of the system are obtained, for which the stability problem is investigated by resorting to a monodromy matrix method. The approach used to analyze the torsional stability of the parallel robotic wrist is numerically illustrated, wherein the instable regions are presented graphically. Moreover, some critical parameters, such as torsional stiffness and rotating speeds, are identified. Future work includes the complete parametric stability analysis of the system as well as its lateral stability.

Fig. 1 .

 1 Fig. 1. CAD model of the parallel wrist mechanism.

Fig. 2 .

 2 Fig. 2. Kinematic architectures of the wrist mechanism and its U joint.

Fig. 3 .

 3 Fig. 3. The driving and driven parts of the U-joint mechanism.

Fig. 4 .

 4 Fig. 4. Effects of the driving shaft speed Ω 0 and bend angle β onto the torsional stability of the parallel wrist with stiffness k 1 = 10 Nm/rad (blue point means torsional dynamic instability).

Fig. 5 .

 5 Fig. 5. Effects of the driving shaft stiffness k 1 and bend angle β onto the dynamic torsional stability with speed Ω 0 = 19π rad/s.

Acknowledgement

The reported work is supported by the Doctoral Scientific Research Foundation of Liaoning Province (No. 20170520134) and the Fundamental Research Funds for the Central Universities (No. DUT16RC(3)068).


Abhilash Nayak

Stéphane Caro

Philippe Wenger

A Dual Reconfigurable 4-rRUU Parallel Manipulator

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

A Dual Reconfigurable 4-rRUU Parallel Manipulator

Abhilash Nayak1 , Stéphane Caro2 and Philippe Wenger 2 Abstract-The aim of this paper is to introduce the use of a double Hooke's joint linkage to reconfigure the base revolute joints of a 4-RUU parallel manipulator (PM). It leads to an architecturally reconfigurable 4-rRUU PM whose platform motion depends on the angle between the driving and driven shafts of the double-Hooke's joint linkage in each limb. Even when the angle is fixed, the manipulator is reconfigurable by virtue of the different operation modes it can exhibit. By keeping the angle as a variable, the constraint equations of the 4-rRUU PM are derived using Study's kinematic mapping. Subsequently, the ideal of constraint polynomials is decomposed as an intersection of primary ideals to determine the operation modes of the 4-rRUU PM for intersecting and parallel revolute joint axes in the base and the moving platform.

I. INTRODUCTION

Reconfigurability in a PM extends its employability for a variety of applications. A lower mobility PM with dof< 6 is reconfigurable if it has different configuration space regions with possibly different type or number of degrees of freedom. These regions are known as the operation modes of the PM and were first exemplified by Zlatanov et al. [START_REF] Zlatanov | Constraint Singularities as C-Space Singularities[END_REF] for the 3-URU DYMO robot exhibiting five different types of platform motion. Its closely related SNU 3-UPU [START_REF] Walter | A complete kinematic analysis of the SNU 3-UPU parallel robot[END_REF] and Tsai 3-UPU [START_REF] Walter | Kinematic analysis of the TSAI 3-UPU parallel manipulator using algebraic methods[END_REF] PMs were analyzed by Walter et al. with a complete characterization of their operation modes along with the transition poses. Most of the operation modes of the 3-URU or the 3-UPU PMs are physically distinguishable unlike the 3-[PP]S PMs for which the first two joints in each limb generate a motion equivalent to two coplanar translations followed by a spherical joint. 3-RPS [START_REF] Schadlbauer | The 3-rps parallel manipulator from an algebraic viewpoint[END_REF], 3-PRS [START_REF] Nurahmi | Operation modes and singularities of 3-PRS parallel manipulators with different arrangements of p-joints[END_REF] and 3-SPR PMs [START_REF] Nayak | Comparison of 3-RPS and 3-SPR Parallel Manipulators Based on Their Maximum Inscribed Singularity-Free Circle[END_REF] are such manipulators that exhibit two operation modes each with coupled motion. Other reconfigurable PMs include the 3-RER PM (E denotes a planar joint) found to have 15 3-dof operation modes [START_REF] Kong | Reconfiguration analysis of a 3-DOF parallel mechanism using euler parameter quaternions and algebraic geometry method[END_REF] and the 4-RUU PM with vertical base and platform revolute joint axes possessing three operation modes [START_REF] Nurahmi | Reconfiguration analysis of a 4-RUU parallel manipulator[END_REF].

Besides, a PM can be reconfigurable also by changing the position and/or orientation of one or more of its constituent joints. This type of reconfigurability is named architectural reconfigurability in this paper. MaPaMan [START_REF] Srivatsan | On the position kinematic analysis of mapaman: a reconfigurable three-degrees-of-freedom spatial parallel manipulator[END_REF] is one such manipulator in which the strut can be oriented to have two different architectures of the same PM where it can transition between roll-pitch-heave and roll-pitch-yaw degrees of freedom. Gan et al. [START_REF] Gan | Optimal design of a metamorphic parallel mechanism with reconfigurable 1T2R and 3R motion based on unified motion/force transmissibility[END_REF] introduced a novel reconfigurable {stephane.caro, philippe.wenger}@ls2n.fr revolute joint and proposed a metamorphic 3-rRPS PM. In this paper, a double Hooke's joint linkage is used as a reconfigurable revolute joint and is used to demonstrate different types of reconfigurability of a 4-RUU PM.

The double Hooke's joint linkage is a well-known special over-constrained 6R-mechanism, where the first three and the last three joint axes are mutually perpendicular. It is also known as a Double Cardan Joint and is ubiquitous as a steering column in automobiles. Its architecture is fairly simple compared to a general over-constrained 6R mechanism which makes it easier to derive the input-output relations. There have been different approaches in the literature to derive its input-output relations proving that it is a constant velocity transmitter when the angle between the input shaft and the central yoke is equal to the angle between the central yoke and the output shaft [START_REF] Baker | Displacementclosure equations of the unspecialised doublehooke's-joint linkage[END_REF], [START_REF] Dietmaier | Simply overconstrained mechanisms with rotational joints[END_REF], [START_REF] Mavroidis | Analysis of overconstrained mechanisms[END_REF]. The constant-velocity transmission property of a double-Hooke's joint is exploited in this paper to reconfigure the first revolute joint axis in each limb of a 4-RUU PM.

The organization of the paper is as follows: Section II presents the architecture of the dual reconfigurable 4-rRUU PM along with the architecture of its constituent double-Hooke's joint linkage. Section III deals with the derivation of constraint equations and the determination of operation modes of 4rRUU PMs for some specific orientations of the base and revolute joint axes. Section IV concludes the paper and puts forth some open issues associated with the construction of a functional 4-rRUU PM prototype.

II. THE 4-rRUU PARALLEL MANIPULATOR A. Manipulator Architecture

The architecture of the dual reconfigurable 4-rRUU PM with a square base and a platform is shown in Fig. 1 and its constituent double-Hooke's joint linkage is shown in Fig. 2.

A reconfigurable revolute joint (rR) and two universal joints (UU) mounted in series constitute each limb of the 4-rRUU PM. Point L i , i = 1, 2, 3, 4 lies on the pivotal axis of the double-Hooke's joint linkage as shown in Fig. 2. Point A i lies on the first revolute joint axis of the 4-rRUU PM and it can be obtained from point L i by traversing a horizontal distance of l i along the first revolute joint axis. Points B i and C i are the geometric centers of the first and the second universal joints, respectively. Points L i and C i form the corners of the square base and the platform, respectively. F O and F P are the coordinate frames attached to the fixed base and the moving platform such that their origins O and P lie at the centers of the respective squares. The revolute-joint axes vectors in i-th limb are marked s ij , i = 1, 2, 3, 4; j = 1, ..., 5. Vectors s i1 and s i2 are

A 3 B 3 C 3 A 1 B 1 C 1 A 2 B 2 C 2 B 4 C 4 z P y P P F P x P s 44 s 45 A 4 L 4 L 1 L 2 L 3 A A z O y O O F O x O r 0 r 1 p q s 42
φ 1 φ 6 O 0 O 6 β L i A i M O T O R l i
Fig. 2: Double Hooke's joint always parallel, so are vectors s i3 and s i4 . For simplicity, it is assumed that the orientation of vector s i1 expressed in coordinate frame F O is the same as that of s i5 expressed in coordinate frame F P . The position vectors of points L i , A i , B i and C i expressed in frame F k , k ∈ O, P are denoted as k l i , k a i , k b i and k c i , respectively. r 0 and r 1 are half the diagonals of the base and the moving platform squares, respectively. p and q are the link lengths.

B. Double-Hooke's joint linkage

The double Hooke's joint linkage is shown in Fig. 2. The first three and the last three revolute joint axes intersect at points O 0 and O 6 , respectively. The first revolute joint is driven by a motor with an input angle of φ 1 and the last revolute joint rotates with an output angle of φ 6 and their axes intersect at point L i , i = 1, 2, 3, 4. It is noteworthy that for a constant-velocity transmission, the triangle O 0 O 6 L i must be isosceles with O 0 L i = O 6 L i . The angle between the input and the output shafts is denoted as β ∈ [0, π]. Since the double-Hooke's joint is known to be a constantvelocity transmitter, the following input-output relationship holds [START_REF] Baker | Displacementclosure equations of the unspecialised doublehooke's-joint linkage[END_REF], [START_REF] Dietmaier | Simply overconstrained mechanisms with rotational joints[END_REF], [START_REF] Mavroidis | Analysis of overconstrained mechanisms[END_REF]:

φ 6 = -φ 1 (1)
Figure 3 shows the top view of the 4-rRUU PM without the links. For architectural reconfigurability, the reconfigurable

β 3 β 1 β 2 β 4 y O O F O x O A 3 A 1 A 2 A 4 s 31 s 21 s 11 s 41 L 4 L 1 L 2 L 3
Fig. 3: Possible orientations of the base revolute joint revolute joint axis in the base is allowed to have a horizontal orientation β i , i = 1, 2, 3, 4. It is noteworthy that β i will be changed manually in the prototype under construction.

III. OPERATION MODE ANALYSIS A. Constraint Equations

Since the reconfigurable revolute joint is actuated, a RUU limb must satisfy the following two constraints:

1) The second revolute joint axis, the fifth revolute joint axis and link BC must lie in the same plane. In other words, the scalar triple product of the corresponding vectors must be null:

g i : (b i -c i ) T (s i2 × s i5 ) = 0, i = 1, 2, 3, 4 (2)
2) The length of link BC must be q:

g i+4 : ||b i -c i || -q = 0, i = 1, 2, 3, 4 (3)
Since the length of link BC does not affect the operation modes of the 4-rRUU PM, only the principal geometric constraint from Eq. ( 2) is considered. To express it algebraically, the homogeneous coordinates of the necessary vectors are listed below:

0 l i = R z (λ i ) [1, r 0 , 0, 0] T (4a) 0 a i = 0 l i + R z (λ i + β i ) [0, 0, l i , 0] T (4b) 0 b i = 0 a i + R z (λ i + β i ) [0, p cos(θ i ), 0, p sin(θ i )] T (4c) 0 c i = F R z (λ i )[1, r 1 , 0, 0] T , ( 4d
) 0 s i2 = R z (λ i + β i ) [0, 0, 1, 0] T , ( 4e
) 0 s i5 = F R z (λ i + β i )[0, 0, 1, 0] T , i = 1, 2, 3, 4. (4f)
where R z (•) is the homogeneous rotation matrix about the zaxis, λ i for the i-th limb is given by

λ 1 = 0, λ 2 = π 2 , λ 3 = π, λ 4 = 3π 2
and θ i is the actuated joint angle. F is the transformation matrix consisting of Study parameters x j and y j , j = 0, 1, 2, 3:

F = 1 ∆        ∆ 0 0 0 d 1 r 11 r 12 r 13 d 2 r 21 r 22 r 23 d 3 r 31 r 32 r 33        (5)
with

∆ = x 0 2 + x 1 2 + x 2 2 + x 3 2 = 0 and r 11 = x 0 2 + x 1 2 -x 2 2 -x 3 2 r 12 = -2 x 0 x 3 + 2 x 1 x 2 r 13 = 2 x 0 x 2 + 2 x 1 x 3 r 21 = 2 x 0 x 3 + 2 x 1 x 2 r 22 = x 0 2 -x 1 2 + x 2 2 -x 3 2 r 23 = -2 x 0 x 1 + 2 x 2 x 3 r 31 = -2 x 0 x 2 + 2 x 1 x 3 r 32 = 2 x 0 x 1 + 2 x 2 x 3 r 33 = x 0 2 -x 1 2 -x 2 2 + x 3 2 d 1 = -2 x 0 y 1 + 2 x 1 y 0 -2 x 2 y 3 + 2 x 3 y 2 , d 2 = -2 x 0 y 2 + 2 x 1 y 3 + 2 x 2 y 0 -2 x 3 y 1 , d 3 = -2 x 0 y 3 -2 x 1 y 2 + 2 x 2 y 1 + 2 x 3 y 0 .
Thus, Eq. ( 2) is derived for each limb algebraically by substituting t i = tan( θi 2 ) and w i = tan( βi 2 ), i = 1, 2, 3, 4. The constraint polynomials g i , i = 1, 2, 3, 4 form the following ideal 1 :

I = g 1 , g 2 , g 3 , g 4 ⊆ k[x 0 , x 1 , x 2 , x 3 , y 0 , y 1 , y 2 , y 3 ] (6)
To simplify the determination of the operation modes, the 4-rRUU PM is split into two 2-rRUU PMs [START_REF] Nurahmi | Reconfiguration analysis of a 4-RUU parallel manipulator[END_REF] by considering two ideals:

I (I) = g 1 , g 3 (7a) I (II) = g 2 , g 4 (7b)
Even after substituting the design parameters, it was impossible to calculate the primary decomposition of ideals I (I) and I (II) for a general β i and it remains an open issue. Consequently, some special configurations of the 4-rRUU PM are considered and their operation modes are determined as follows:

B. Operation Modes of some Specific 4-RUU PMs 1)

β 1 = β 2 = β 3 = β 4 = π 2 :
For the PM shown in Fig. 4, the constraint equations are derived from Eqs. ( 2) and (4) as 1 The ideal generated by the given polynomials is the set of all combinations of these polynomials using coefficients from the polynomial ring k

[x 0 , x 1 , x 2 , x 3 , y 0 , y 1 , y 2 , y 3 ] [14].
g 1 := -pt 1 2 + p x 0 x 2 + 2 pt 1 x 0 x 3 + 2 pt 1 x 1 x 2 + pt 1 2 -p x 1 x 3 + 2 t 1 2 + 2 x 2 y 2 + (2 t 1 2 + 2)x 3 y 3 = 0 (8a) g 2 := -pt 2 2 + r 0 t 2 2 -r 1 t 2 2 + p + r 0 -r 1 x 0 x 2 + 2 t 2 px 0 x 3 + 2 t 2 px 1 x 2 + (pt 2 2 -r 0 t 2 2 -r 1 t 2 2 -p -r 0 -r 1 )x 1 x 3 + 2 t 2 2 + 2 x 2 y 2 + (2 t 2 2 + 2)x 3 y 3 = 0 (8b) g 3 := -pt 3 2 + p x 0 x 2 + 2 pt 3 x 0 x 3 + 2 pt 3 x 1 x 2 + pt 3 2 -p x 1 x 3 + 2 t 3 2 + 2 x 2 y 2 + (2 t 3 2 + 2)x 3 y 3 = 0 (8c) g 4 := -pt 4 2 -r 0 t 4 2 + r 1 t 4 2 + p -r 0 + r 1 x 0 x 2 + 2 t 4 px 0 x 3 + 2 t 4 px 1 x 2 + (pt 4 2 + r 0 t 4 2 + r 1 t 4 2 -p + r 0 + r 1 )x 1 x 3 + 2 t 4 2 + 2 x 2 y 2 + (2 t 4 2 + 2)x 3 y 3 = 0 (8d)
The primary decomposition of ideals I (I) and I (II) shown in Eq. ( 7) leads to three sub-ideals each. Among them, the third sub-ideals I 3(I) and I 3(II) correspond to a mixed mode and are of little importance in this context. The other two sub-ideals I k(I) and I k(II) , k = 1, 2 are as follows:

I (I) = I 1(I) ∩ I 2(I) ∩ I 3(I) ,
where

I 1(I) = x 0 , x 1 , x 2 y 2 + x 3 y 3 I 2(I) = x 2 , x 3 , x 0 y 0 + x 1 y 1 (9a) I (II) = I 1(II) ∩ I 2(II) ∩ I 3(II) ,
where

I 1(II) = x 0 , x 1 , x 2 y 2 + x 3 y 3 I 2(II) = x 2 , x 3 , x 0 y 0 + x 1 y 1 (9b)
As a result, the first two operation modes of the 4-rRUU PM shown in Fig. 4 are:

I 1 =I 1(I) ∪ I 1(II) = x 0 , x 1 , x 2 y 2 + x 3 y 3 (10a) I 2 =I 2(I) ∪ I 2(II) = x 2 , x 3 , x 0 y 0 + x 1 y 1 (10b)
Substituting the condition x 0 = x 1 = x 2 y 2 + x 3 y 3 = 0 in the transformation matrix in Eq. ( 5) yields:

F 1 =         1 0 0 0 - 2y 3 x 2 -1 0 0 2(x 2 y 0 -x 3 y 1 ) 0 x 2 2 -x 2 3 2x 2 x 3 2(x 2 y 1 + x 3 y 0 ) 0 2x 2 x 3 -x 2 2 + x 2 3         (11)
From the transformation matrix, it can be observed that the operation mode is a 4-dof Schönflies mode in which the translational motions are parametrized by y 0 , y 1 and y 3 and the rotational motion is parametrized by x 2 , x 3 and x 2 2 + x 2 3 = 1. In this operation mode, the platform is upside down with the z P -axis pointing in a direction opposite to the z O -axis. The rotational motion is about x O -axis.

Similarly, substituting the condition x 0 = x 1 = x 2 y 2 + x 3 y 3 = 0 in the transformation matrix in Eq. ( 5) yields:

F 2 =         1 0 0 0 - 2y 1 x 0 1 0 0 -2(x 0 y 2 -x 1 y 3 ) 0 x 0 2 -x 1 2 -2 x 0 x 1 -2(x 0 y 3 + 2 x 1 y 2 ) 0 2 x 0 x 1 x 0 2 -x 1 2         (12
) In this case, the operation mode is also a 4-dof Schönflies mode in which the translational motions are parametrized by y 1 , y 2 and y 3 and the rotational motion is parametrized by x 0 , x 1 and x 2 0 + x 2 1 = 1. The platform is in upright position with rotational motion about x O -axis. 2) and (4) as follows:

g 1 := -pt 1 2 + p x 0 x 2 + 2 pt 1 x 0 x 3 + 2 pt 1 x 1 x 2 + pt 1 2 -p x 1 x 3 + 2 t 1 2 + 2 x 2 y 2 + (2 t 1 2 + 2)x 3 y 3 = 0 (13a) g 2 := -pt 2 2 + p x 0 x 1 + 2 pt 2 x 0 x 3 -2 pt 2 x 1 x 2 + -pt 2 2 + p x 2 x 3 + 2 t 2 2 + 2 x 1 y 1 + (2 t 2 2 + 2)x 3 y 3 = 0 (13b) g 3 := -pt 3 2 + p x 0 x 2 + 2 pt 3 x 0 x 3 + 2 pt 3 x 1 x 2 + pt 3 2 -p x 1 x 3 + 2 t 3 2 + 2 x 2 y 2 + (2 t 3 2 + 2)x 3 y 3 = 0 (13c) g 4 := -pt 4 2 + p x 0 x 1 + 2 pt 4 x 0 x 3 -2 pt 4 x 1 x 2 + -pt 4 2 + p x 2 x 3 + 2 t 4 2 + 2 x 1 y 1 + (2 t 4 2 + 2)x 3 y 3 = 0 (13d)
The primary decomposition of ideals I (I) and I (II) shown in Eq. ( 7) leads to three sub-ideals each, of which the two sub-ideals I k(I) and I k(II) , k = 1, 2 are as follows:

I (I) = I 1(I) ∩ I 2(I) ∩ I 3(I) ,
where

I 1(I) = x 0 , x 1 , x 2 y 2 + x 3 y 3 I 2(I) = x 2 , x 3 , x 0 y 0 + x 1 y 1 (14a) I (II) = I 1(II) ∩ I 2(II) ∩ I 3(II) ,
where I 1(II) = x 0 , x 2 , x 1 y 1 + x 3 y 3 I 2(II) = x 1 , x 3 , x 0 y 0 + x 2 y 2 (14b)

As a result, the first two operation modes of the 4-RUU PM are:

I 1 =I 1(I) ∪ I 1(II) = x 0 , x 1 , x 2 , y 3 (15a) I 2 =I 2(I) ∪ I 2(II) = x 1 , x 2 , x 3 , y 0 (15b)
Substituting the condition x 0 = x 1 = x 2 = y 3 = 0 in the transformation matrix in Eq. ( 5) yields:

F 1 =            1 0 0 0 2y 2 x 3 -1 0 0 - 2y 1 x 3 0 -1 0 2y 0 x 3 0 0 1            (16)
From the transformation matrix, it can be deduced that the operation mode is a 3-dof pure translational mode parametrized by y 0 , y 1 and y 2 when x 3 = 1. In this operation mode, the platform is upside down with the z P -axis pointing downwards.

Similarly, substituting the condition x 1 = x 2 = x 3 = y 0 = 0 in the transformation matrix in Eq. ( 5) yields:

F 2 =            1 0 0 0 - 2y 1 x 0 1 0 0 - 2y 2 x 0 0 1 0 - 2y 3 x 0 0 0 1            (17)
In this case, the operation mode is also a 3-dof translational mode parametrized by y 1 , y 2 and y 3 when x 0 = 1. Since the rotation matrix is identity, the platform is in upright position with z P -axis pointing upwards. Fig. 6: A dual reconfigurable 4-rRUU PM with vertical base revolute joint axes

3) Vertical base and platform revolute joint axes: The double-Hooke's joint allows a planar transmission and hence the 4-rRUU PM can have any orientation of the base revolute joints such that β i ∈ [0, π]. Additionally, with the help of a L-fixture, it is possible to have a vertical orientation of the base revolute joint axes as shown in Fig. 6.

Reconfiguration analysis of this mechanism already exists in the literature [START_REF] Nurahmi | Reconfiguration analysis of a 4-RUU parallel manipulator[END_REF], where it was shown to have three operation modes. The first operation mode is a 4-dof Schönflies mode in which the platform is upside down and the rotational axis is parallel to z O -axis. The second operation mode is a 4-dof Schönflies mode with the rotational axis parallel to z Oaxis, but in this case, the posture of the platform is upright. The third operation mode is a 2-dof coupled motion mode and is less relevant from a practical view point.

IV. CONCLUSIONS AND FUTURE WORK

A dual reconfigurable 4-rRUU PM consisting of a reconfigurable revolute joint based on the double-Hooke's joint linkage was presented in this paper. It was shown how a double-Hooke's joint linkage can be exploited to impart an architectural reconfigurability to a 4-RUU PM. The resulting dual reconfigurable 4-rRUU PM was shown to exhibit at least the following operation modes: a pure translational operation mode and Schönflies motion modes with different axes of rotation depending on the orientation of base revolute joint axes.

As a part of the future work, the operation modes will be determined as a function of the angle β which will assist in recognizing all possible platform motion types of the 4-rRUU PM for β ∈ [0, π]. Furthermore, a detailed design of the 4-rRUU PM will be performed in order to construct a functional prototype exhibiting different types of reconfigurability. It should be noted that in the prototype, the orientation of the revolute joint axes in the moving platform will have to be changed manually and the choice of a joint to have all planar orientations is still an open issue.

Fig. 1 :

 1 Fig. 1: A 4-rRUU parallel manipulator

Fig. 4 :

 4 Fig. 4: A 4-rRUU PM with horizontal and intersecting base revolute joint axes

Fig. 5 :

 5 Fig. 5: A 4-RUU PM with horizontal and parallel base revolute joint axes 2) β 1 = β 3 = π 2 , β 3 = β 4 = 0: For the PM shown in Fig. 5 with w 1 = w 3 = 1 and w 2 = w 4 = 0, the

Abhilash Nayak is with École Centrale de Nantes, Laboratoire des Sciences du Numérique de Nantes (LS2N), 1 rue de la Noë, UMR CNRS 6004, 44321 Nantes, France abhilash.nayak@ls2n.fr

Stéphane Caro and Philippe Wenger are with CNRS, Laboratoire des Sciences du Numérique de Nantes (LS2N), École Centrale de Nantes, 1 rue de la Noë, UMR CNRS 6004, 44321 Nantes, France

ACKNOWLEDGMENT

This work was conducted with the support of both Centrale Nantes and the French National Research Agency (ANR project "Kapamat" #ANR-14-CE34-0008-01). We would also like to show our gratitude to Rakesh Shantappa, a former Master's student at Centrale Nantes for his help with the CAD models.


Renan Sales Barros

Jordi Borst

Steven Kleynenberg

Céline Badr

Rama-Rao Ganji

Hubrecht De Bliek

Landry-Stéphane Zeng-Eyindanga

Henk Van Den Brink

Charles Majoie

Henk Marquering

Sílvia Delgado Olabarriaga

Remote Collaboration, Decision Support, and On-Demand Medical Image Analysis for Acute Stroke Care

Keywords: Acute Care, Cloud Computing, Decision Support, High Performance Computing, Medical Image Analysis, Remote Collaboration, Stroke, Telemedicine

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Acute ischemic stroke is the leading cause of disability and fourth cause of death [START_REF] Go | Heart disease and stroke statistics -2013 update: a report from the American Heart Association[END_REF].

In acute ischemic stroke, a blood clot obstructs blood flow in the brain causing part of the brain to die due to the lack of blood supply. The amount of brain damage and the patient outcome is highly related to the duration of the lack of blood flow ("time is brain"). Therefore, fast diagnosis, decision making, and treatment are crucial in acute stroke management.

Medical data of a stroke patient is collected during the transport by ambulance to the hospital (e.g. vital signs, patient history, and medication). At arrival, various types of image data are acquired following protocols that involve opinions and decisions from various medical experts. Sometimes, a patient needs to be transferred to a specialized hospital and, in this case, it is important that all the data collected in the ambulance and at the referring hospital is available to the caregivers that will continue the treatment. Often, various medical specialists need to collaborate based on available information for determining the correct diagnosis and choosing the best treatment. Usually, this collaboration is based on tools that are not connected to each other and, because of that, they may not deliver the necessary information rapidly enough.

In addition to these challenges, the amount of patient medical data is growing fast [START_REF] Hallett | Cloud-based Healthcare: Towards a SLA Compliant Network Aware Solution for Medical Image Processing[END_REF]. This fast increase is especially observed in radiological image data, which is also a consequence of new medical imaging technologies [START_REF] Alonso-Calvo | Cloud computing service for managing large medical image data-sets using balanced collaborative agents[END_REF][START_REF] Shini | Cloud based medical image exchange-security challenges[END_REF]. The management, sharing, and processing of medical image data is a great challenge for healthcare providers [START_REF] Alonso-Calvo | Cloud computing service for managing large medical image data-sets using balanced collaborative agents[END_REF][START_REF] Shini | Cloud based medical image exchange-security challenges[END_REF] and they can be greatly improved by the usage of cloud technologies [START_REF] Kagadis | Cloud computing in medical imaging[END_REF]. Cloud technologies also enable collaboration and data exchange between medical experts in a scalable, fast, and cost-effective way [START_REF] Kagadis | Cloud computing in medical imaging[END_REF]. Mobile devices, remote collaboration tools, and on-demand computing models and data analysis tools supported by cloud technologies may play an important role to help in optimizing stroke treatment and, consequently, improve outcome of patients suffering from stroke.

In this paper, we present a cloud-based platform for Medical Distributed Utilization of Services & Applications (MEDUSA). This platform aims at improving current acute care settings by allowing fast medical data exchange, advanced processing of medical image data, automated decision support, and remote collaboration between physicians through a secure responsive virtual space. We discuss a case study implemented using the MEDUSA platform for supporting the treatment of acute stroke patients, presenting the technical details of the prototype implementation and commenting on its initial evaluation

2

Related Work

The development of cloud-based platforms for collaboration and processing of medical data is a challenging task. Many authors [START_REF] Shini | Cloud based medical image exchange-security challenges[END_REF][START_REF] Kagadis | Cloud computing in medical imaging[END_REF][START_REF] Jeyabalaraja | Cloud Computing in Medical Diagnosis for improving Health Care Environment[END_REF][START_REF] Pino | A Survey of Cloud Computing Architecture and Applications in Health[END_REF] put forward that these platforms hold the potential to define the future of healthcare services. Also, the analysis of medical data can be an important way to improve quality and efficiency in healthcare [START_REF] Jee | Potentiality of big data in the medical sector: focus on how to reshape the healthcare system[END_REF][START_REF] Murdoch | The inevitable application of big data to health care[END_REF]. The work presented in [START_REF] Kanagaraj | Proposal of an open-source cloud computing system for exchanging medical images of a hospital information system[END_REF][START_REF] Yang | Implementation of a medical image file accessing system on cloud computing[END_REF] focuses on the development of a cloud-based solution aimed at only the storage and sharing of medical data. In other words, they propose solutions based on cloud infrastructures to facilitate medical image data exchange between hospitals, imaging centers, and physicians. A similar solution is presented in [START_REF] Koufi | Ubiquitous access to cloud emergency medical services[END_REF], however focusing on medical data sharing during emergency situations. A cloudbased system is presented in [START_REF] Zhuang | Efficient and robust large medical image retrieval in mobile cloud computing environment[END_REF] for storage of medical data with an additional functionality that enables content-based retrieval of medical images. Still focusing on cloud-based data storage and sharing, [START_REF] Hua | A Cloud Computing Based Collaborative Service Pattern of Medical Association for Stroke Prevention and Treatment[END_REF] presents a solution to help managing medical resources for the prevention and treatment of chronic stroke patients.

In addition to storage and sharing, some studies also include the possibility of using the cloud infrastructure for processing of medical data. A simple cloud-based application is presented in [START_REF] Sharieh | Using cloud computing for medical applications[END_REF] to monitor oxygenated hemoglobin and deoxygenated hemoglobin concentration changes in different tissues. Cloud computing is also used in [START_REF] Parsonson | A cloud computing medical image analysis and collaboration platform[END_REF] not only to support data storage and sharing, but also to visualize and render medical image data. In [START_REF] Dorn | A cloud-deployed 3D medical imaging system with dynamically optimized scalability and cloud costs[END_REF] the authors also propose a cloud application for rendering of 3D medical imaging data. This application additionally manages the cloud deployment by considering scalability, operational cost, and network quality.

Complete cloud-based systems for medical image analysis are presented in [START_REF] Chiang | Bulding a cloud service for medical image processing based on service-orient architecture[END_REF][START_REF] Huang | Medical information integration based cloud computing[END_REF][START_REF] Ojog | A Cloud Scalable Platform for DICOM Image Analysis as a Tool for Remote Medical Support[END_REF]. However, in these systems, image upload and download is manually performed by the user, while the system focuses on the remote processing, storage, and sharing of medical image data. The MEDUSA platform not only provides cloud-based storage, sharing, and processing of medical image data, but also real-time communication between medical experts, real-time collaborative interaction of the medical experts with the medical data, and a real-time decision support system that continuously processes patient data and displays relevant notifications about the patient condition.

The MEDUSA platform also includes a cloud management layer that coordinates the use of resources in the cloud infrastructure. Other studies also present some cloud management features. In [START_REF] Ahn | Autonomic computing architecture for real-time medical application running on virtual private cloud infrastructures[END_REF] the authors propose a cloud architecture that reserves network and computing resources to avoid problems regarding load-balancing mechanisms of cloud infrastructures and to reduce the processing delays for the medical applications. Also, [START_REF] Hallett | Cloud-based Healthcare: Towards a SLA Compliant Network Aware Solution for Medical Image Processing[END_REF] proposes an algorithm to optimize the organization of medical image data and associated processing algorithms in cloud computing nodes to increase the computing performance. Finally, [START_REF] Alonso-Calvo | Cloud computing service for managing large medical image data-sets using balanced collaborative agents[END_REF] presents a cloud-based multi-agent system for scalable management of large collections of medical image data.

The project presented in [START_REF] Holtmann | Medical Opportunities by Mobile IT Usage-A Case Study in the Stroke Chain of Survival[END_REF] tries to speed up current stroke care by integrating and sharing data from stroke patients using mobile networks. In this scenario, a hospital can, for instance, be prepared with the right resources before the arrival of the patient. This project also includes decision support, which suggests a predefined path through the emergency procedures according to the structure of mandatory and other supplementary healthcare protocols. However, differently from MEDUSA, this project does not include any image processing based feature.

Acute Stroke Care

Currently, treatment decision of stroke patients is increasingly driven by advanced imaging techniques. These imaging techniques consist of non-contrast computed tomography (ncCT), computed tomography angiography (CTA), and computed tomography perfusion (CTP). Because of the extensive usage of imaging techniques, it is common to produce gigabytes of image data per patient. The primary treatment for patients with acute ischemic stroke is intravenous administration of alteplase (thrombolysis). Patients who are not eligible for treatment with alteplase or do not respond to the treatment can be treated by mechanical removal of the blood clot via the artery (thrombectomy). Thrombectomy is only available in specialized hospitals and often a patient must be transferred for treatment.

This transfer is arranged via telephone and imaging data created in the initial hospital is not available for the caregivers in the specialized hospital until the patient and imaging data arrive via the ambulance. On a regular basis it happens that the imaging data was wrongly interpreted in the initial hospital and that the patient is not eligible for thrombectomy. Also, often new imaging acquisitions have to be redone due to broken DVDs, wrong data, or insufficient quality. These problems result in futile transfers and loss of valuable time.

MEDUSA Platform

The MEDUSA platform was designed to support remote collaboration and high performance processing of medical data for multiple healthcare scenarios. The platform is accessible to final users through the MEDUSA Collaboration Framework (MCF), which is a web application that is compatible with any web browser that supports HTML5. The MCF is a special type of MEDUSA application that provides to the users an entry point to access other MEDUSA applications. A cloud management layer controls the deployment and execution of all MEDUSA applications in one or more cloud providers. Figure 1 illustrates the architectural design of the MEDUSA platform.

MEDUSA Cloud Applications

The MEDUSA platform has a number of cloud applications that are available in all healthcare scenarios: Audit Trail, which reports the events generated by the other MEDUSA applications; User Manager, which allows assigning roles to users and defining which MEDUSA applications they can use; and Video Call, which allows communication between users of the MEDUSA platform.

Cloud Management Layer

MEDUSA Cloud Applications

MEDUSA Collaboration Framework User Manager

Video Call Audit Trail …

Cloud Provider

The MEDUSA applications are started as part of a MEDUSA session. Multiple users in a session can interact with these applications, and these interactions are visible to all the users in the session. The handling of multiple user interactions is done by each MEDUSA application. The applications in the MEDUSA platform can be web applications or regular desktop applications. The desktop applications are integrated in the MEDUSA platform through a virtualization server that uses the technologies described in [START_REF] Joveski | Semantic multimedia remote display for mobile thin clients[END_REF] and [START_REF] Joveski | MPEG-4 solutions for virtualizing RDP-based applications[END_REF]. The multi-user interaction of the desktop applications is handled by the virtualization server.

Cloud Provider

The MEDUSA applications can be deployed in different cloud providers. Currently, these applications are being deployed in the High Performance Real-time Cloud for Computing (HiPeRT-Cloud) of Bull. The HiPeRT-Cloud is mainly designed for realtime computationally-intensive workloads. This solution is fully compatible with the Cloud Computing Reference Architecture of the National Institute of Standards and Technology (NIST) and provides infrastructure services under any cloud broker solution. The HiPeRT-Cloud is used in the MEDUSA platform because it provides solutions for handling complex applications in the field of real-time computational and dataintensive tasks in the cloud.

Cloud Management Layer

In order to take advantage of the on-demand, flexible, high-performance, and cost-effective options that cloud providers can offer, the cloud management layer, implemented by Prologue, manages the cloud deployment in the MEDUSA platform. This layer orchestrates the allocation and release of resources on the cloud provider's infrastructure. It also oversees the lifecycle of the deployed resources, ensures their availability and scalability, and links the desktop applications from the virtualization server back to the MCF. The cloud management layer is designed according to the Service-Oriented Architecture model and its functionalities are accessible through a Representational State Transfer Application Programming Interface (REST API). The cloud management layer also incorporates a monitoring service that operates by accessing directly the deployed virtual machines (VMs). The technology behind the cloud management layer is aligned with the NIST architecture and based on the Open Cloud Computing Interface specifications.

In the MEDUSA context, technical requirements for computing, storage, network, and security resources have been identified for each MEDUSA application to be deployed. All requirements are then translated into machine-readable code that is used to provision the cloud resources.

The components of the MEDUSA platform are hosted on the cloud through a security-aware, need-based provisioning process. By supporting on-demand hybrid and multi-cloud deployments, as well as monitoring, load balancing, and auto-scaling services through an agent embedded in each VM, the cloud management layer thus ensures a high resilience of the MEDUSA platform.

Security

The security of the MEDUSA platform is currently mainly based in the use of digital certificates, which are used to authenticate MEDUSA applications (VMs), to secure the data exchanges through the network, and to provide strong authentication of MEDUSA users.

The VMs containing the applications are deployed dynamically, and thus server certificates need to be created dynamically, during the deployment. A web service was developed to provide dynamic generation of server certificates for the different VMs in the MEDUSA platform. These server certificates must be created during the deployment of the VMs and there must be one certificate per application and VM (identified by the IP address).

Regarding the user authentication, an authentication module is called when a user opens a MEDUSA session. This module authenticates a user by checking the provided credentials against the user management component, which has access to a special internal directory containing the certificates used for strong authentication of MEDUSA users.

The MEDUSA platform also uses robust image watermarking and fingerprinting methods to prevent and detect unauthorized modification and leaking of medical images by authorized users by. However, due to legal regulations, an important requirement when dealing with medical images is the capability reconstructing the original image data. Because of this, reversible or semantic-sensitive techniques for watermarking and fingerprinting can be used in the MEDUSA platform. These techniques enable to completely recover the original image data or at least the recovery of the regions of these images that are relevant for the user or application.

MEDUSA Stroke Prototype

The MEDUSA platform was designed to support various medical scenarios. Here, we focus on a prototype for supporting acute stroke care. The MEDUSA Stroke Prototype (MSP) is built by combining the default MEDUSA applications with three applications specifically configured to support the treatment of stroke patients: Advanced Medical Image Processing, Decision Support System, and 3D Segmentation Renderer. All the applications of the MSP are executed in VMs running on the HiPeRT-Cloud. The cloud management layer is in charge of the deployment of these VMs.

Advanced Medical Image Processing

For supporting the assessment of the severity of a stroke, several medical image processing algorithms (MIPAs) have been developed. These algorithms perform quantitative analysis of the medical image data and the result of these analyses can be used to support the treatment decisions. The output of these algorithms are, for example, the segmentation of a hemorrhage in the brain [START_REF] Boers | Automatic Quantification of Subarachnoid Hemorrhage on Noncontrast CT[END_REF], the segmentation of a blood clot [START_REF] Santos | Development and validation of intracranial thrombus segmentation on CT angiography in patients with acute ischemic stroke[END_REF], and the segmentation of the infarcted brain tissue [START_REF] Boers | Automated cerebral infarct volume measurement in follow-up noncontrast CT scans of patients with acute ischemic stroke[END_REF]. The MIPAs are linked together into processing pipelines with well-defined input, output, and policies that control their execution. The execution of these pipelines is automatically orchestrated to deliver the lowest execution time based on a set of optimization strategies (e.g. task parallelism, data parallelism, and GPU computing).

The MIPAs are implemented as plugins for the IntelliSpace Discovery (ISD) platform, an enterprise solution for research, developed by Philips Healthcare. Figure 2 shows the output of the plugin for infarct volume calculation in the ISD. The collection of MIPAs specially developed to support acute stroke care that are included in the ISD constitutes the Advanced Medical Image Processing application of the MSP. The ISD is a Windows desktop application developed by using the .NET Framework. The development of the MIPAs is also based in the .NET Framework. For GPUbased computations, OpenCL 1.1 was used. OpenCL is a framework for the development and execution of programs across platforms consisting of different types of processors such as CPUs, GPUs, etc. OpenCL.NET was used to integrate OpenCL with the .NET. Framework.

The data generated by the MIPAs are exported to the DSS by using JavaScript Object Notation (JSON) files through WebSockets. (Anonymized) Patient information is sent to the MIPAs by using the tags of the medical image data used as input. The information about the current session is directly sent to the ISD and forwarded to the MIPAs.

Decision Support System

The Decision Support System (DSS) by Sopheon provides real-time process support to medical professionals collaborating on the stroke case. The DSS is rule-based: the rules specify the conditions under which actions are to be advised (delivered as notifications). The Decision Support rules are part of a medical protocol and thus defined and approved by medical professionals.

In the MSP, the DSS runs a set of rules specifically designed for dealing with stroke patients. It gathers real-time input from vital sign sensors and MIPAs. For instance, a rule could state that an infarct volume larger than 70 milliliters is associated with a poor outcome for the patient. When the DSS detects an infarct volume value of e.g. 80 milliliters, it will display the notification associated with this condition. DSS also selects relevant information from the data generated by the MIPAs and forwards it to the audit trail and to the 3D Segmentation Renderer.

The DSS runs on Node.js, which is a platform built on Google Chrome's JavaScript runtime. The DSS is deployed on Fedora, which is an operating system based on the Linux kernel.

3D Segmentation Renderer

The 3D Segmentation Renderer by Sopheon is responsible for displaying 3D segmentations generated by the MIPAs. This application was developed by using the WebGL library, which enables to render 3D graphics in the browser without installing additional software. Figure 3 shows the GUI of this application rendering the segmentation of brain tissue (in green and blue) and the segmentation of the infarcted region (in red).

Initial Evaluation

As this is an on-going project, the discussion presented below is based upon an evaluation of the first fully-integrated prototype.

The MSP integrates very heterogeneous applications, which run on different operational systems (Windows, Linux) and use different development technologies (Java, OpenCL, C#, C++). These applications are seamlessly available for the user from a single interface. Also, the deployment of the applications is transparently handled by the platform. This solution is provided in a smooth and transparent manner, hiding the complex details from the user.

In the MEDUSA platform, the data and user input need to cross several software layers, which might introduce overheads and decrease performance. However, such poor performance was not noticed in the initial MSP prototype. For instance, the Advanced Medical Image Processing application, which requires data exchange between different architectural components, was almost instantaneously ready for use without noticeable interaction delays.

The MSP implements a complete acute stroke use case, which has been demonstrated live in various occasions. Impressions have been collected informally to assess the potential value of this prototype system. Table 1 compares the current stroke care situation in the Netherlands versus the stroke care that could be supported by the MEDUSA platform based on the functionalities currently present in the MSP.

Because of its complexity, a detailed and quantitative evaluation of the MEDUSA platform involves several software components and requires a careful planning. The design of this evaluation was already defined in the first year of the project. It is scheduled to take place during the last 6 months of the MEDUSA project (end of 2015). Concerning the image processing functionality, most of the MIPAs included in the MSP are too computationally expensive to be executed on a local machine according to the time constraints of an acute stroke patient. HPC capabilities delivered by cloud computing were crucial to improve the processing of these algorithms from hours to minutes, making them suitable for acute stroke care. For instance, the time to run the method used to reduce noise in CTP data was reduced from more than half an hour to less than 2 minutes [START_REF] Barros | High Performance Image Analysis of Compressed Dynamic CT Perfusion Data of Patients with Acute Ischemic Stroke[END_REF].

Discussion and Conclusion

The development of the MEDUSA platform started in 2013. Back then, this kind of cloud-based solutions was not common. Today, however, there is a clear trend in the healthcare industry towards the usage of cloud computing, collaboration, and automated analyses of medical data. In addition, when dealing with processing of medical data constrained by the requirements of acute care situations, a lot of benefits can be derived from the use of cloud computing: scalability, pay-per-use model, high performance computing capabilities, remote access, etc. There are innumerous technical challenges for enabling the execution and communication of software components in a platform like MEDUSA. Regarding stroke care, the software components execute in different computing devices (CPUs, GPUs, etc.) and based on different software platforms (web, Linux, Windows, etc.). In the MEDUSA platform these challenges are tackled using SOA approach and a virtualized infrastructure. Because of the variety of application types, a uniform way of establishing communication between the MEDUSA applications has not been developed yet. Nevertheless, the direct communication between applications based on the exchange of well-defined file formats through WebSockets was demonstrated to be effective, without a negative impact in the development and integration of these applications. The current functionalities present in the MSP have the potential to improve several aspects of current stroke care.

The MEDUSA platform is still under development. Thus, most of the components to implement security are still not completely integrated in the platform yet. Defining and developing the security aspects of a platform like MEDUSA is also a very challenging task, since it is necessary to cope with different legal constraints, in particular across countries. The development process of the MEDUSA platform includes the implementation and validation of the platform in three different hospitals. This validation is currently being carried out in one hospital. Preliminary evaluation of the platform indicates that the solution is promising and has potential large value for improving treatment of these patients.

Fig. 1 .

 1 Fig. 1. The MEDUSA platform architecture.

Fig. 2 .

 2 Fig. 2. Plugin for automated measurement of the cerebral infarct volume in the ISD.

Fig. 3 .

 3 Fig. 3. 3D segmentation renderer showing the segmentation of brain tissue (green and blue) and the infarction in the brain (red).

Table 1 .

 1 Current stroke care vs. stroke care with MEDUSA.

		current	with MEDUSA
	Data availability	images are not available	images are available online
	Time to access data	transport by car of physical media (minutes to hours)	online data transfer (few seconds)
	Potential value for	automated quantitative analysis not used	results of MIPAs readily available as
	decision	yet for clinical decision	decision parameters
	Infrastructure	static, proprietary, fixed scale	pay-per-use, scalable, and portable to different cloud providers
	Remote collaboration	by phone	by video-conference with access to the patient data

Acknowledgments. This work has been funded by ITEA2 10004: MEDUSA.


Maha Kooli

Henri-Pierre Charles

Clement Touzet

Bastien Giraud

Jean-Philippe Noel

Smart Instruction Codes for In-Memory Computing Architectures Compatible with Standard SRAM Interfaces

This paper presents the computing model for In-Memory Computing architecture based on SRAM memory that embeds computing abilities. This memory concept offers significant performance gains in terms of energy consumption and execution time. To handle the interaction between the memory and the CPU, new memory instruction codes were designed. These instructions are communicated by the CPU to the memory, using standard SRAM buses. This implementation allows (1) to embed In-Memory Computing capabilities on a system without Instruction Set Architecture (ISA) modification, and (2) to finely interlace CPU instructions and in-memory computing instructions.

I. INTRODUCTION

In-Memory Computing (IMC) represents a new concept of data computation that has been introduced to overcome the von Neumann bottleneck in terms of data transfer rate. This concept aimes to reduce the traffic of the data between the memory and the processor. Thus, it offers significant reduction of energy consumption and execution time compared to the conventional computer system where the computation units (ALU) and the storing elements are separated. Hardware security improvements can also be expected thanks to this system architecture (e.g., side channel attacks, etc).

The IMC concept has just started to be the focus of recent research works. The objective of our research works is to focus on different technological layers of an IMC system: silicon design, system architecture, compilation and programming flow. This enables to build a complete IMC system that can be then industrialized. In previous publications, we introduced our novel In-Memory Power Aware CompuTing (IMPACT) system. In [START_REF] Akyel | DRC 2: Dynamically Reconfigurable Computing Circuit based on memory architecture[END_REF], we presented the IMPACT concept based on a SRAM architecture and the possible in-memory arithmetic and logic operations. In [START_REF] Kooli | Software Platform Dedicated for In-Memory Computing Circuit Evaluation[END_REF], we proposed a dedicated software emulation platform to evaluate the IMPACT system performance. The results achieved in these papers show a significant performance improvement of the IMPACT system compared to conventional systems. In the present research work, we focus on a new important step of the design of a complete IMPACT system, in particular the communication protocol between the memory and the Computation Processor Unit (CPU).

Fig. 1 presents a comparison of the communication protocol for a conventional system, for a GPU system and for our IMPACT system. In a conventional system based on von Neumann architecture, the traffic between the memory and the CPU is very crowded. Several instruction fetches and data transfers occupy the system buses during the computation (Fig. 1.a). In systems that are integrating accelerators (e.g., GPUs), the computation is performed in parallel, whereas only a single instruction fetch is needed. However, data transfers are still required over the data bus (Fig. 1.b). The traffic of our IMPACT system is completely different from the previous systems. No data transfer over the system buses is required since the computation is performed inside the memory. In addition, only one instruction transfer towards the memory is required (Fig. 1.c). Indeed, the IMPACT system presents a new concept that completely changes the memory features by integrating computation abilities inside the memory boundary. Therefore, the usual communication protocol between the memory and CPU is not fully compatible with the specific IMPACT system architecture. Thus, it has to be redefined to manage the new process of instruction executions.

In this paper, we push one step further our research works on IMPACT system by:

• Introducing a novel communication protocol between the CPU and the memory that is able to manage the transfer of the IMPACT instructions to the memory. • Defining the ISA that corresponds to this protocol. The reminder of this paper is organized as follows. Section II provides a summary of the architecture and the communication protocol used in conventional system. Section III discusses related works. Section IV introduces the IMPACT instruction codes and the communication protocol. In section V, we provide a possible solution to integrate the proposed IMPACT instructions inside an existing processor ISA. Finally, section VI concludes the paper.

II. BACKGROUND

In most traditional computer architecture, the memory and the CPU are tightly connected. Conventionally, a microprocessor presents a number of electrical connections on its pins dedicated to select an address from the main memory, and another set of pins to read/write the data stored from/or into that location. The buses which connect the CPU and the memory are one of the defining characteristics of a system. These buses need to handle the communication protocol between the memory and the CPU. The buses transfer different types of data between components. In particular, we distinguish, as shown in Fig. 2, three types:

• Data bus: It has a bidirectional functionality. It enables the transfer of data that is stored in the memory towards the CPU, or vice versa. • Address bus: It is an unidirectional bus that enables the transfer of addresses from CPU to the memory. When the CPU needs a data, it sends its corresponding memory location via the address bus, the memory then sends back the data via the data bus. When the processor wants to store a data in the memory, it sends the memory location where it will be stored via the address bus, and the data via the data bus. When the program is executed, for each instruction the processor proceeds by the following steps:

1) Fetch the instruction from memory: The CPU transmits the instruction address via the address bus, the memory forwards then the instruction stored in that location via the data bus. 2) Decode the instruction using the decoder: The decoding process allows the CPU to determine which instruction will be performed. It consists in fetching the input operands and the opcode, and moving them to the appropriate registers in the register file of the processor. 3) Access memory (in case of read/write instructions): For 'read' instruction, this step consists in sending a memory address on the address bus and receiving the value on the data bus; The 'write' instruction consists in sending a data with the data bus. Then, this data is copied into a memory address, sent by the address bus. The control bus is used activate the write or read mode. 4) Execute the instruction. 5) Write-back (in case of arithmetic/logic instructions): the ALU performs the computation and write back the result in the corresponding register.

III. RELATED WORKS A. In-Memory Computing

Processing in-Memory (PiM), Logic in-Memory (LiM) and IMC architectures have been widely investigated in the context of integrating processor and memory as close as possible, in order to reduce memory latency and increase the data transfer bandwidth. All these architectures attempt to reduce the physical distance between the processor and the memory.

In Fig. 3, we represent the main differences between PiM, LiM and IMC architectures. PiM [START_REF] Gokhale | Processing in memory: The Terasys massively parallel PIM array[END_REF] [4] [START_REF]UPMEM[END_REF] consists in putting the computation unit next to the memory while keeping the two dissociated. It is generally implemented in stand alone memories fabricated with a DRAM process. LiM and IMC architectures are based on embedded memories fabricated with a CMOS process. LiM [START_REF] Matsunaga | MTJ-based nonvolatile logic-in-memory circuit, future prospects and issues[END_REF] enables distributing non-volatile memory elements over a logic-circuit plane. IMC consists in integrating computation units inside the memory boundary, and represents a different concept that completely changes the memory behavior by integrating some in-situ computation functions located either before or after sens amplifiers circuits. As a result, the communication protocol between the memory and the processor has to be redefined. Compared to LiM, IMC enables non-destructive computing in the memory, i.e., the operand data are not lost after computation. Some recent research works start to explore and evaluate the performance of this concept. It has been applied both on volatile memories [START_REF] Jeloka | A 28 nm configurable memory (TCAM/BCAM/SRAM) using push-rule 6T bit cell enabling logic-in-memory[END_REF] [8] [START_REF] Aga | Compute caches[END_REF] and non volatile memories [START_REF] Wang | DW-AES: A Domain-Wall Nanowire-Based AES for High Throughput and Energy-Efficient Data Encryption in Non-Volatile Memory[END_REF] [START_REF] Li | Pinatubo: A processing-in-memory architecture for bulk bitwise operations in emerging non-volatile memories[END_REF].

Most of the existing IMC studies focus on the IMC hardware design. The system buses have never been presented, nor interactions between the CPU and the memory. Moreover, no ISA to implement the IMC system architecture has already been defined. All these points clearly limit the conception of a complete IMC system. In this paper, we focus on the communication protocol between the memory and the CPU for the IMPACT system and we define the ISA. This study is a basic step in the development of a complete IMC system on different technological layers from the hardware to the software. In addition, the IM-PACT system is able to support operations with multi-operand selection. Thus, the classic format of instruction (opcode + two source operand addresses + a destination address) cannot be used due to limitations in the bus size.

CPU

SRAM bus

Additional Logic

On-chip Memory

CPU Additional Logic

Off-chip Memory

Logic in Memory

B. Communication Protocols in Computing Systems

The communication protocol between the memory and CPU has been widely presented and discussed in different works [START_REF] Vahid | Embedded system design: a unified hardware/software introduction[END_REF] [13] [START_REF] Null | The essentials of computer organization and architecture[END_REF]. This protocol is implemented and managed using buses. Existing system buses (data bus, address bus, control bus) are generally used to transfer the data or the addresses, but not the instructions. For the IMPACT system, the CPU should communicate the instruction to the memory so that the memory executes/computes this instruction. In the existing computer architecture, the buses are designed to enable only read and write operations, but not arithmetic and logic operations. This paper introduces a new communication protocol that is able to efficiently manage the interaction between the CPU and the IMPACT memory with a full compatibility with the existing buses.

IV. IMPACT MEMORY INSTRUCTION CODES

In this Section, we define the different IMPACT memory instruction codes that will be transmitted by the processor to the memory via the system buses. The challenge is to make the IMPACT system architecture as close as possible to a conventional system architecture, i.e., we aim to bring the less possible changes to the conventional system implementation in order to facilitate the integration of the IMPACT system to existing system architectures. In addition, it allows to propose a system that is able to interweave the execution of conventional CPU instructions and IMPACT instructions.

A. IMPACT Specific Operations

IMPACT system is based on the SRAM architecture to perform operations inside the memory macro thanks to an array composed of bitcells with dedicated read ports. The IMPACT system circuitry enables the same logic and arithmetic operations as a basic ALU. It also presents new specific features that are:

• Multi-Operand Operations: The IMPACT system circuitry is able to perform logic and memory operations not only on two operands as for conventional systems, but on multiple operands. In fact, this feature is achieved thanks to the multi-row selector, which enables to generate a defined selection pattern (e.g., one line out of four, halftop of the rows, etc). • Long-Word Operations: The IMPACT system circuitry is able to perform arithmetic/logic/memory operations on words whose size can be up to the physical row size of the memory. The operand size is no longer limited by the register size (that is much more smaller that the maximum memory row size).

B. IMPACT Instruction Formats

Regarding these specific features of the IMPACT operations, we propose two new formats that enable to build the IMPACT memory instruction codes.

(a) Multi-Operand Instruction Format: (b) Two-Operand Instruction Format:

Opcode Address

Mask SP Output SI Opcode Address 1 Address 2 SP Output SI

1) Multi-Operand Instruction Format:

The multi-operand format enables to define the structure of the instruction that performs a multi-operand operation. In fact, in conventional system architecture, the instruction size is usually of 32 bits [START_REF]MIPS32 Architecture[END_REF]. Thus, they do not enable to encode all the addresses of the multiple operands. Therefore, we propose to define a pattern that enables to select the lines that store the operand data of the given operation. This pattern is built thanks to a pattern code (defined by both an address and a mask) driving a specific row-selector.

To implement this instruction, we propose a multi-operand format, as shown in Fig. 4.a, that encodes:

-The opcode of the operation. In Fig. 6, we provide the list of the logic multi-operand operations that the IMPACT system is able to execute. -The row selector address.

-The row selector mask.

-The output address, where the computation result is stored. -A Smart Instruction (SI) bit to inform the memory about the instruction type: an IMPACT or a conventional instruction. -A Select Pattern (SP) bit to enable/disable the pattern construction using the row-selector.

In Fig. 5, we provide an example of the operating mode of the IMPACT system when it is executing a logic 'OR' operation with multi-operand. As input, the system take the instruction composants (opcode, pattern code, etc). Based on the bits of the pattern code address and mask, the specific row selector of the IMPACT memory builds a regular pattern to select the multiple memory lines. In this row selector, we create a sort of path (i.e., a tree) filled regularly by '0' and '1' bits. Then, the rule consists in looking after the bits of the mask: if the bit is '1', we select the two branches in the tree, if the bit is '0', only the branch corresponding to the address bit is selected. This method allows then to build regular output patterns. These patterns can then be refined by adding/deleting a specific line. For that, we define specific IMPACT operations ('PatternAdd' and 'PatternSub'). As shown in Fig. 5, the pattern can be also stored in the pattern register in case we require to refine it or to use it in the future. We assume that this refinement process could take some additional clock cycles to build the required pattern, however for certain applications where the pattern is used several times, the gain would be considerable. Once the pattern is build, the last step of the instruction execution consists in selecting the lines in the SRAM memory array that correspond to '1' in the pattern, and performing the operation. The advantage of this format consists in not explicitly encoding all the operand addresses inside the instruction. To the best of our knowledge, there is no computer architecture that defines such instructions using this pattern methodology.

2) Two-Operand Instruction Format: The two-operand instruction format represents the conventional format of instructions with maximum two source addresses. This format is used for the long-word operations. The source address represents the address of the memory row on which the operation will be performed. As shown in Fig. 4.b, the two-operand instruction format encodes:

-The opcode of the operation. In Fig. 6, we provide the list of all the operations that the IMPACT system is able to execute. -The addresses of the first and second operand.

-The output address, where the computation result is stored. -SI bit to inform the memory about the instruction type:

an IMPACT or a conventional instruction. -SP bit to activate/dis-activate the pattern construction using the row-selector. In this format the pattern construction should be disable for all the instructions.

C. IMPACT Communication Protocol

In mainstream memories, the system buses are used to communicate between the memory and the CPU during the execution of different instructions of the program (that are stored in the code segment of the memory). In the IMPACT system, the instructions are built on the fly during the compilation by the processor respecting the formats defined in Subsection IV-A. Then, they are transferred from the processor to the memory via the standard SRAM buses (data and address buses). The compilation aspect and communication between the program code and the processor are not detailed in the present paper. In this Section, we present the implementation of the IMPACT instructions on the data and the address buses.

For the proposed communication protocol, we consider a data bus of 32-bits size, an address bus of 32-bits size. Then, we propose a specific encoding of the instruction elements over the two buses. As shown in Fig. 7, we make use of the data and the address buses to encode the opcode, the source addresses, the output address, and additional one-bit SP and SI signals.

implementation does not change the implementation of conventional system. The communication protocol is able to address both the IMPACT and the SRAM memories.

1) Data Bus: The data bus encodes the opcode on 7 bits. In fact, the IMPACT operations are hierarchically ranked as shown in Fig. 6. Then, the data bus encodes the source addresses, each over 12 bits, leading to a maximum 4096 words of IMPACT memory. In case of two-operand format, we encode successively the two operand addresses. In case of multi-operand format, we encode the address and the mask of the pattern code. The last bit of the data bus is occupied by the SP signal as described in Subsection IV-B.

2) Address Bus: The address bus encodes the output address over 12 bits in the Least Significant Bit (LSB). It also reserves one bit, in the Most Significant Bit (MSB) for the smart instruction signal in order to inform the memory about the arriving of an IMPACT instruction.

V. IMPLEMENTATION AT ISA LEVEL

We propose, in this Section, a possible solution to built the proposed IMPACT instruction codes from the instruction set architecture (ISA) of a given processor. The solution consists in using an existing processor ISA without integrating new instructions or opcodes. In particular, we use the store instruction to monitor the IMPACT operations (arithmetic/logic). The IM-PACT opcode, as well as its operands, will be encoded inside the operands (i.e., registers) of the conventional instruction. In Fig. 8, we provide, for an IMPACT addition operation, the compilation process to create the corresponding IMPACT assembly code. First, the compiler generates instructions that encodes the addresses of the IMPACT opcode as well as the operands inside specific registers. These instructions will be transferred via the system buses respecting the conventional communication protocol. Then, the compiler generates the store instruction with the previously assembled specific registers. This store instruction is then transferred to the memory through the system buses respecting the IMPACT communication protocol defined in Subsection IV-C.

The advantage of this solution consists in its facility to be compatible with the processor ISA (no problem in case of version changes). However, the compilation process will be quite complex since it requires to generate a preliminary list of instructions needed then to generate IMPACT instruction using the store instruction. Further solutions to integrate the proposed IMPACT memory instruction code in the ISA are possible. However, they require to change the processor ISA by integrating one or more new instructions (e.g., 'IMPACTAdd'). The compilation process will be then simpler since it does not require to generate the preliminary list of instructions. However, this solution could have some problems of compatibility with future ISA versions.

VI. CONCLUSION

This paper discusses the integration of the In-Memory Computing capabilities into a system composed of a processor and a memory without changing the processor implementation and instruction set. This is acheived by inverting the von Neuman model: instead of reading instructions from memory, the CPU communicates the instructions, in certain formats, to the IMPACT memory via the standard SRAM buses.

The proposed approch allows to benefit from the huge speedup in terms of execution time and energy consumption offered by the IMPACT system, but also to easily interweave conventional CPU instructions and in-memory computing instructions. One main advantage of this approach is to have a similar data layout view on both CPU and IMPACT side. Whereas, other conventional approaches (e.g., GPUs) need to copy data and change the layout at run-time.

As future works, we aim to continue characterizing applications on high level, and to develop the compiler for this system. High level optimizations of classical programming languages or new programming paradigms are also under investigation.

Fig. 1 .

 1 Fig. 1. Comparison between the Communication Protocols of (a) Conventional System (von Neumann), (b) System with Accelerators GPUs (von Neumann with Single Instruction Multiple Data (SIMD)) and (c) IMPACT Systems (non von Neumann).

Fig. 3 .

 3 Fig. 3. Comparison between IMC, LiM and PiM Architectures.

Fig. 4 .

 4 Fig. 4. Description of IMPACT Instruction Formats.

Fig. 5 .Fig. 6 .

 56 Fig. 5. Illustration of a Multi-Operand Instruction (OR) requiring a Pattern Code.

Fig. 7 .

 7 Fig. 7. Example of Data and Address Buses Use to Encode IMPACT and Conventional Instructions.

Fig. 8 .

 8 Fig. 8. Implementation of IMPACT Store Instruction.

Address Bus Central Memory CPU ALU Decoder Reg PC Control Bus Data Bus

	• Control bus: It is a set of additional signals defining the
	operating mode, read/write, etc.
	Fig. 2. Conventional Computing System Architectures.


Henri-Pierre Charles

CONCLUSION & PERSPECTIVES

| 5

BRING THE COMPUTATION INTO MEMORY

When data start to look like motorists in the traffic jam during the rush hour… (data@memory ↔ data@comp_unit)

•••

  …it's time to consider teleworking, in other word the in-memory computing …meanwhile in IMC world! The largest part of power consumption of logic and arithmetic operations is due to the memory access! POWER WALL  The way to perform basic operations has to be restudied  A lot of applications should be improved in performance logic/arith. op. vs memory access energy  100Computing in dedicated units: • High data transfer between the ALU & the memory  Power hungry  Interconnect & memory security issues • In-memory computing: • Reduced data transfer  Energy-efficient  Execution time acceleration  Security reinforcements (limitation of the side channel attacks (on buses) Enable in-memory operations • Reduce latency & energy consumption due to data transfer • SRAM bit cell array allows: • Long word arithmetic/logic operations not limited by register size, but with memory line size • Multi-row selection for some logic operations • Simultaneous storing in different addresses DATE'18 | Henri-Pierre Charles | 22/03/2018 K. C. Akyel, et al. ICRC, 2016

  new communication protocol between the CPU and the IMPACT memory  Compatible with existing system architecture (conventional system bus)  Enable interleaving the CPU & the in-memory instruction execution • Work on the compiler:  Generate the assembly code respecting the communication protocol  Interleave the IMC & CPU instruction execution • Based on the performance evaluation  Optimize the data set-up in the memory • Data alignment in the IMC • Data interleaving

• Evaluate high level benchmarks -on going • ../.. IMPACT ROADMAP | 16 Maximum two input operands IMPACT OPERATIONS AKA OPCODES DATE'18 | Henri-Pierre Charles | 22/03/2018

			Not
		Memory	Set
			Reset
	Logic	Shift	Shift Left Shift Right
	& Memory		Xor
	Operation		Nxor
		Logic	And Or
			Nor
			Nand
		Memory line size word	Addition
	Arithmetic Operation	8 bits words 16 bits words 32 bits words	Substraction Increment Decrement
		64 bits words	Comparison

DATA INTERLEAVING: A TEST CASE typedef unsigned char ImgLine _attribute_((ext_vector_type(N))); typedef ImgLine Image[M];

-1: if IMPACT instr.

A select pattern bit to enable/disable the pattern