Antoine Clément

S Laurens

Ginette Arliguie

D Deby

-S Laurens

- G Arliguie -F

Deby

Numerical study of the linear polarization resistance technique applied to reinforced concrete for corrosion assessment

Keywords: Corrosion, béton armé, résistance de polarisation linéaire, mesures in situ, simulation numérique Corrosion, steel reinforced concrete, linear polarization resistance, on-site measurement, numerical simulation

come

Numerical study of the linear polarization resistance technique applied to reinforced concrete for corrosion assessment

Introduction

Corrosion is the main source of damage in reinforced concrete structures. Therefore, it is crucial for service life prediction to be able to assess the corrosion rate of steel. The Linear Polarization Resistance (LPR) technique theoretically provides the corrosion current density, and thus the corrosion rate of steel, by measuring the polarization resistance (R p ). According to several assumptions, the corrosion current density j corr [A.m -2 ] and the polarization resistance R p [.m 2 ] are linked by the Stern-Geary relation [START_REF] Stern | Electrochemical polarization[END_REF]:

p corr R B j  [1]
Where B [V] is a factor defined below, which depends on anodic and cathodic Tafel slopes.

Although the LPR technique is now widely used, a large dispersion is observed in R p determination. The French research project "Benchmark des poutres de la Rance" used common commercial devices and laboratory devices to assess the corrosion rate of corroded beams [START_REF] Poupard | Benchmark des Poutres de la Rance": Damage diagnosis of reinforced concrete beams after 40 years exposure in marine environment by non destructive tools[END_REF]. Results showed differences of a factor often higher than 20 between the devices tested. This lack of reliability may be explained in various ways. First, the technique is often implemented beyond the theoretical limits. It should be used only in cases of uniform corrosion induced, for example, by concrete carbonation [START_REF] Stern | Electrochemical polarization[END_REF] [START_REF] Gulikers | Theoretical considerations on the supposed linear relationship between concrete resistivity and corrosion rate of steel reinforcement[END_REF] [START_REF] Song | Theoretical analysis of the measurement of polarisation resistance in reinforced concrete[END_REF]. Moreover, the polarization should be limited (lower than 20 mV / Ecorr) in order to remain in the linear polarization range (RILEM, 2004) [START_REF] Nygaard | Corrosion rate of steel in concrete: evaluation of confinement techniques for on-site corrosion rate measurements[END_REF]. The second main issue is that the R p calculation usually assumes uniform current density distribution on a specific surface of the corroding rebar, and consequently uniform polarization. Actually, according to the physical geometry, there is no reason for current density distribution and polarization to be uniform. Furthermore, current distribution is highly influenced by environmental and geometrical factors.

The modeling of corrosion propagation in reinforced concrete has been a field of intensive research, so scientific literature can be found easily. The main theoretical considerations are reviewed in (Warkus et al., 2006a) [START_REF] Raupach | Models for the propagation phase of reinforcement corrosion -an overview[END_REF] and a sample of applications is given in [START_REF] Gulikers | Numerical models for the propagation period of reinforcement corrosion -Comparison of a case study calculated by different researchers[END_REF] (Warkus et al., 2006) [START_REF] Nasser | Influence of steel-concrete interface condition on galvanic corrosion currents in carbonated concrete[END_REF]. Comparatively, there has been little work published specifically on LPR simulations. Resistance networks are often implemented to simulate the measurement. Wojtas used a 2D network to study the ability of a guard-ring to confine the current along the rebar axis, and showed that it was not possible to obtain a reliable Rp value for the full range of corrosion current [START_REF] Wojtas | Determination of corrosion rate of reinforcement with a modulated guard ring electrode; analysis of errors due to lateral current distribution[END_REF]. In [START_REF] Feliu | Effect of Current Distribution on Corrosion Rate Measurements in Reinforced Concrete[END_REF], the current distribution is considered in the rebar cross-sectional plane. It proves not to be uniform and, in cases of active corrosion, can lead to an overestimation of current corrosion by between 10% and 30% depending on the geometry. Kranc and Sagües considered radial symmetry of the problem and simulated the measurement according to a transient method [START_REF] Kranc | Polarization current distribution and electrochemical impedance response of reinforced concrete when using guard ring electrodes[END_REF].

They studied the effect of guard ring and counter-electrode size with respect to cover depth and the accuracy of the results for local or uniform corrosion. The study indicated that the measurement was successful only in cases of uniform corrosion with an electrode size larger than the cover depth. In order to take account of the effect on polarized length of some parameters influencing the measurement (such as concrete resistivity), Tang and Fu used a 2D FEM model of a new linear device and developed a specific formula to interpret the measurement [START_REF] Tang | A rapid technique using Handheld instrument for mapping corrosion of steel in reinforced concrete[END_REF]. The combination of this new device with the formula gives results comparable to other commercial devices but much faster. A more complete study is reported in [START_REF] Janusz | Condition evaluation of concrete bridges relative to reinforcement corrosion[END_REF] with a 2D and 3D FEM model in the steady state. Several parameters, such as corrosion intensity, probe dimensions, cover depth and concrete resistivity, were investigated by focusing on potential and current mapping. However, no major measurement improvements were proposed from the numerous simulations carried out.

Despite the simulation works presented above, some questions remain as to the quantitative effects of the factors that most influence LPR measurements. In this field, the research presented below aimed to perform FEM experiments to analyze the effects of probe geometry on the polarizing current distribution for a complete 3D model, and to quantify errors on R p and j corr measurements.

Theoretical background

Corrosion

Corrosion of steel in concrete creates anodic zones on the steel surface, where the steel is oxidized, and cathodic zones where dioxygen is reduced. In cases of local or macrocell corrosion (generally induced by chlorides), the anodes and cathodes are significant distances apart. If corrosion is caused by carbonation, the anodes and cathodes are infinitely close and their locations change randomly with time. This is referred to as microcell corrosion. In that case, anodic and cathodic potentials are equal to the corrosion potential E corr and anodic and cathodic current densities are equivalent. The corresponding current density is the corrosion current density j corr . A shift ΔE from the equilibrium potential E corr results in a current density Δj. The relation between ΔE and Δj defines the polarization behavior and can be modeled by the Butler-Volmer nonlinear equation involving anodic and cathodic Tafel slopes (b a and b c , respectively, expressed in Volt per decade) [START_REF] Stern | Electrochemical polarization[END_REF] (Warkus et al., 2006b):

                            E b E b j j c a corr ) 10 ln( exp ) 10 ln( exp [2]
Where ln(10) is referred to as the natural logarithm of 10 (= 2.303). This relation is valid only in cases of microcell corrosion and if the charge transfer controls the reaction (no diffusion control is taken into account). It excludes very dense or saturated concrete, in which oxygen diffusion may be limited. The expression can be modified to encompass the latter cases (Warkus et al., 2006a), but it is not the purpose of this study.

Close to the corrosion potential, the first-order expansion of the Butler-Volmer equation leads to Eq.3, which defines the constant B presented in Eq.1:

  B E j E b b b b j j corr c a c a corr       . ) 10 ln( [3 ]
The polarization resistance R p is defined as the slope of the linear part of the polarization curve close to the corrosion potential E corr : . 1 [4 ] This relation provides the basic concept of R p measurement. Either ΔE is imposed and the response Δj is measured, or Δj is imposed and the response ΔE is measured.

  c a c a corr corr E E p b b b b j j B j E R corr        ) 10 ln(

Measurement of the polarization resistance

The LPR measurement in reinforced concrete involves three electrodes:

-the counter-electrode (CE) applying a polarizing current, which is usually controlled according to the steel potential or current density, -the working electrode (WE) which is the steel rebar to be analyzed, -the reference electrode located on the concrete surface to monitor the response of the electrochemical system to the perturbation induced by CE.

Several steady-state or transient techniques may be used to determine Rp. In the aim of controlling the steel surface polarized by the current injected through CE, some commercial devices use a complementary electrode referred to as a guard ring (GR). The purpose of the GR is to confine the polarizing current in a specific area. As mentioned above, comparative studies involving different devices have shown high dispersion in LPR measurements performed at the same points [START_REF] Poupard | Benchmark des Poutres de la Rance": Damage diagnosis of reinforced concrete beams after 40 years exposure in marine environment by non destructive tools[END_REF] [START_REF] Gepraegs | A comparative evaluation of three commercial instruments for field measurements of reinforcing steel corrosion rates[END_REF] [START_REF] Liu | Comparison of guarded and unguarded linear polarization CCD devices with weight loss measurements[END_REF]. Part of the dispersion may be explained by the sensitivity of the measurement to concrete resistivity and other environmental factors but some authors point out problems related to the confining device. Simulations using 2D resistance networks have shown that GR fails to confine the current over the full range of corrosion rates [START_REF] Wojtas | Determination of corrosion rate of reinforcement with a modulated guard ring electrode; analysis of errors due to lateral current distribution[END_REF]. Recently, the current distribution along the rebar was experimentally investigated for local corrosion [START_REF] Nygaard | Corrosion rate of steel in concrete: evaluation of confinement techniques for on-site corrosion rate measurements[END_REF]. By focusing on the confinement techniques, it was shown that current injected from GR often compromised the measurement.

Modeling and simulation of LPR measurement

The purpose of this paper is to study the effects of probe geometry on R p and j corr measurement through FEM simulations. Only uniform corrosion and steady-state measurements were considered here to assess the three-dimensional distribution of polarizing and confining currents. Simulations were performed using the "DC conductive media" module of the commercial FEM code COMSOL Multiphysics®.

Geometrical models

Three probe geometries were investigated: the two annular probes (including CE and GR) presented in Fig. 1 and Fig. 2 and one simple rectangular counter-electrode presented in Fig. 3. The two annular probes had quite similar counter-electrodes but their guard-rings were of different sizes. The probe with the smaller GR is noted G 1 (Fig. 1) and the probe with the larger GR is noted G 2 (Fig. 2). A first simulation involving only the counter-electrode of G 1 was performed. This particular simulation case will be referred to as G 1CE . For G 2 , GR current was controlled by means of two complementary reference electrodes E 1 and E 2 located between CE and GR. GR current was adjusted so as to achieve the same potentials E 1 and E 2 . It was possible to place the E 1 -E 2 axis either perpendicular or parallel to the rebar axis. Both configurations were simulated. The rectangular probe is noted G 3 . The numerical convergence was preliminary studied and achieved by refining progressively the meshing in order to make negligible current losses due to numerical approximations. It was checked by comparing integrated current densities injected in the specimen (by CE and GR) and the integrated current density on the entire rebar surface. Since the problem is conservative, all the injected current (CE+GR) has to be distributed on the rebar surface. This was achieved by mesh refinement, performed semi-automatically by the FEM code. The numbers of nodes and elements are presented in

Electrokinetics equations, boundary conditions and parameters

Concrete is assumed to be a homogeneous medium having a uniform electrical resistivity ρ [.m]. In the concrete volume, the equations governing electrical phenomena are Ohm"s law (Eq.5), linking the local current density j [A.m -2 ] and the potential gradient  [V.m -1 ], and charge conservation (Eq.6).

φ ρ

1 j    [5] 0 j .   [ 6]
The steel-concrete boundary is modeled according to the Butler-Volmer equation (Eq.2) implemented in the code. Concerning CE and GR, different conditions were imposed depending on the geometry.

Regarding G 1 , GR and CE were set at the same potential (Dirichlet condition) to achieve confinement; this potential was fixed at 10 mV beyond E corr . Regarding G 2 , Neumann conditions were imposed at the locations of CE and GR to set the polarizing and confining currents respectively. The injected polarizing current I CE was chosen so as to achieve a polarization of about +10 mV at the center of CE and GR current was adjusted so that the potential difference between E 1 and E 2 was zero. Finally, the Dirichlet condition was imposed on the G 3 counter-electrode, corresponding to 10 mV beyond E corr . The polarization value was chosen to ensure that the linearity range of the polarization curve was respected so that no effects other than the geometry influenced the measurement.

Other boundary conditions were modeled as an electrical insulation, which is equivalent to a Neumann condition where the normal current is set to zero. Numerical experiments allowed us to work with 2 different values of LPR. The actual value, noted R p , was defined according to Eq.4 and was computed exactly from simulation parameters. An apparent value of LPR, noted R pa , was computed by applying the measurement protocol recommended for on-site devices (Eq.7). If the protocol is correct, R pa and R p be similar.

a pa i Δ E Δ R  [7 ] p CE a S I i Δ  [8 ]
In Eq.7, Δi a is an average current density assuming the rebar to be uniformly polarized. It is calculated by dividing the current injected through the counterelectrode I CE by S p (Eq.8), which is the assumed steel polarized surface defined according to RILEM recommendations [5]. The polarization ΔE involved in the calculation was taken on the steel surface under the center of the probe in order to avoid the effect of the ohmic drop caused by concrete resistivity and thus to focus the analysis exclusively on geometrical effects.

Finally, a local value of current density (Δi l ) was introduced, corresponding to the current density polarizing the point of the rebar where ΔE was collected (under the center of the probe). It was directly provided by the numerical simulation that gave the current density actually polarizing each point of the rebar. If the current distribution on the steel surface under CE is uniform, then Δi a and Δi l should be similar.

Current distribution

Figures 5 to 9 show current density streamlines resulting from each simulation case implemented in this study. The result in terms of current density streamlines of the first simulation G 1CE is shown in Fig. 5. It can be observed that much of the injected current does not polarize the target zone S p since many current lines spread out of this area. The numerical experiment allows the amount of current I Sp actually collected by the target zone to be calculated quite exactly. It is computed by integrating local current densities acting on S p . Table 3 presents a comparison between the injected current I CE and the collected current I Sp . Observations made on the streamlines are confirmed by the fact that only 33% of I CE is collected on S p .

Figure 5. Current density streamlines : G 1CE

When a guard ring is used (Fig. 6), the current injected by CE appears more confined, especially in the rebar longitudinal plane. However, in the rebar transversal plane, some current lines from CE do not end on the target zone, indicating a slight under-confinement. For the probe G 2 , two simulations were carried out according to the E 1 -E 2 axis orientation. When the E 1 -E 2 axis was parallel to the rebar axis (noted G 2par ), good confinement was observed in the rebar direction (Fig. 7). As is often represented in the literature by two-dimensional illustrations, streamlines from CE extended approximately to the middle of the space between CE and GR. However, in the plane perpendicular to the rebar, some current lines from GR ended on S p , resulting in over-confinement. The consequence was that the steel surface S p considered for R pa calculation collected more current than assumed, about 36% as indicated in table 3. In contrast, in the case where the E 1 -E 2 axis was perpendicular to the rebar (noted G 2per ), a few current lines injected by CE were lost (Fig. 8), meaning that the injected current was slightly under-confined (about 4 % as indicated in table 3). Therefore, a first conclusion can be drawn here about the significance of E 1 -E 2 positioning regarding the effectiveness of the confining device. Moreover, the global confinements achieved for cases G 1 and G 2per were similar, 92 % and 96 % respectively. These values express slight under-confinements and could be considered as satisfactory, but the developments below will show that this condition is actually not sufficient.

The use of annular probes to assess the corrosion rate of linear steel bars leads to complex three-dimensional effects in the current density distribution. Fig. 9 shows the current distribution related to probe G 3 , which was simply rectangular. Since there was no confinement device, some current density streamlines naturally spread all over the concrete volume. Table 3 shows that only 57 % of the injected current was collected by the steel located under the probe. However, a greater longitudinal uniformity can be observed in the current streamlines starting from the central part of the probe, expressing a simpler current distribution compared to annular probes. 4 summarizes R pa and j corr (= B / R pa ) values deduced from each simulated probe by applying the recommended protocol and the true R p (1.16 ohm.m²) and j corr (1.5 μA/cm²) values, which were kept for each simulation case. The table also presents the local current density Δi l actually polarizing the point where the potential shift ΔE is considered (top of the rebar under the centre of the probe) for each case and the average current density Δi a resulting from the application of RILEM recommendations.

As expected, the average current density Δi a was systematically different from the local current density Δi l , due to the real three-dimensional nature of the physical problem. This resulted in a systematic mis-estimation of R p since the local current corresponding to the shift ΔE was not well approximated by the average current. Moreover, it was observed that the satisfactory global confinements achieved for G 1 and G 2per were not sufficient to correctly assess the value of R p since the recommended protocol does not take the three-dimensional distribution of the polarizing current into account. This was particularly demonstrated by the fact that, although the best confinement was achieved for G 2per (96 % versus 92 % for G 1 ), the best estimation of R p was obtained for the G 1 configuration, only because of geometrical effects. The G 1 simulation case provided an R p value that was overestimated by +21 %, while R p was overestimated by +32 % according to the G 2per configuration. Moreover, it is interesting to note that the G 3 simulation resulted in an underestimation (-26 %), which was in the same error range as G 1 and G 2per , whereas no confinement system was used. Regarding the G 2 geometry, the significance of E 1 -E 2 axis positioning was also highlighted for R p estimation since, due to the strong over-confinement of 36 %, the G 2par simulation resulted in an overestimation of R p by +71 % compared to +32 % for G 2per . In terms of corrosion rate assessment, table 4 also shows j corr estimations deduced from R pa and B (17.37 mV) values according to Eq.1. The best estimate was achieved by the G 1 configuration and actually corresponded to a significant underestimation of j corr (about -17 %). Moreover, it can be observed that the G 2per configuration provided a better estimation of the corrosion rate than the G 3 configuration whereas the relative error on R p estimation was smaller for G 3 . This result was simply due to the mathematical form of Eq.1, which gave stronger influence to R p negative errors than to R p positive errors. For example, it can be seen that, despite a strong over-estimation of R p by +71 %, the G 2par configuration gave smaller errors on the j corr estimation (about -41 %).

G G G G G Δi (μA/
The simulation results show that, even in very favorable conditions (no ohmic drop effects, homogeneous materials, etc.), the recommended protocol for on-site LPR measurement failed to precisely assess the corrosion rate. This was mainly due to the actual non-uniform distribution of the polarizing current in both longitudinal and orthoradial rebar directions, which is not considered by the usual protocols. It can be observed for all the configurations that current density is maximal under the center of the probe and decreases strongly along the rebar axis, except for G 3 where some longitudinal uniformity is observed around the center of the probe as mentioned regarding Fig. 9. In cases of high under-confinement (G 1CE , G 3 ), the average current density is significantly higher than the local value of polarizing current density under the center of the probe (Δi l ). However, in cases of slight global under-confinement (G 1 and G 2per ), the local value of the polarizing current is still higher than the average current due to the non-uniform distribution. This result shows that global under-confinement may be partially compensated by the nonuniform distribution of the polarizing current density. On the other hand, the nonuniform distribution may enhance over-confinement effects (G 2par ). The representation is limited to the extension of the polarized surface S p involved in the calculation of the apparent polarization resistance R pa . It can be clearly seen that the polarizing current distribution is not uniform in the longitudinal direction, nor in the orthoradial direction. Under the center of CE, the current density is about 0.21 μA.cm -2 at the top of the rebar while it is about 0.13 μA.cm -2 at the bottom, showing that the polarization is much greater on the top of the rebar. The white dotted line links the points where the current density equals the average current density Δi a . It clearly shows that the current density (Δi a ) involved in R p estimation is actually not the current density (Δi l ) polarizing the point of the rebar where the potential response is collected, i.e. under the center of the probe.

Conclusion

The Linear Polarization Resistance (LPR) technique is being more and more frequently used to assess the corrosion rate of steel reinforcements in concrete. To explain the lack of reliability that is often observed experimentally, numerical simulations were performed in order to improve the physical comprehension of the LPR technique. Several measurement devices using annular and rectangular probe geometries were simulated and the numerical experimentation allowed the relevance of RILEM recommendations to be tested for on-site measurements. Interesting conclusions were drawn based on these numerical experiments.

By drawing polarizing and confining current density streamlines resulting from the simulations, it was shown that the LPR measurement using annular counterelectrodes with confining devices was a real three-dimensional physical problem. Moreover, it was found that some complexity was induced by the use of guard-rings. For example, if complementary reference electrodes (E 1 and E 2 ) were used to control the confining current, unexpected effects were observed regarding their positioning with respect to rebar axis. An optimal configuration was found by positioning the E 1 -E 2 axis perpendicular to the rebar axis, providing a slight global under-confinement.

If the E 1 -E 2 axis was positioned parallel to the rebar axis, strong over-confinement was produced.

However, although the confining devices succeeded in limiting global current spreading in some geometrical configurations, the distribution of the polarizing current density at the steel surface was clearly not uniform in either the longitudinal or the orthoradial direction. The major consequence is that the assumption of an average current density uniformly polarizing the steel surface is not relevant, and the calculated LPR, deduced from this assumed current density, is wrong. Regarding the optimal configuration highlighted in this numerical study, although the global confinement was almost perfect, the polarization resistance, assessed according to RILEM recommendations, was still overestimated by more than 20 % and the corrosion rate was underestimated by about 17 %. This error generated by applying RILEM recommendations was due to the existence of a local maximum of the polarizing current distribution which was not taken into account by the protocol. This local current maximum effect compensates the under-confinement and enhances the over-confinement. To improve the RILEM protocol, efforts should be made towards a better estimation of the current density which actually polarizes the point of the rebar where the potential response is collected.

These results also raise some questions about the relevance of the annular geometry of the probes usually used for on-site LPR measurement. For example, the rectangular counter-electrode experimented in this numerical study presented a more uniform current distribution along the rebar axis, indicating a probably easier interpretation although there was no confinement device. Lastly, to emphasize the true difficulty of real on-site LPR measurements, it has to be recalled that these results, highlighting some theoretical limits of the usual protocol, were achieved from numerical simulations carried out in very favorable conditions: stationary measurement, no ohmic drop, uniform corrosion, homogeneous materials, etc. This study focused on geometrical effects but complementary research is currently being conducted to understand the effects of the various other influential factors and thus to improve measurement protocols.

Figure 1 .

 1 Figure 1. Probe dimensions G 1 (mm)

Figure 2 .

 2 Figure 2. Probe Geometry G 2 (mm)

Figure 4 .

 4 Figure 4. Example of geometrical model involving G 2 (mm)

Figure 6 .

 6 Figure 6. Current density streamlines : G 1

Figure 7 .Figure 8 .

 78 Figure 7. Current density streamlines : G 2par

Figure 9 .

 9 Figure 9. Current density streamlines: G3 Table4summarizes R pa and j corr (= B / R pa ) values deduced from each simulated probe by applying the recommended protocol and the true R p (1.16 ohm.m²) and j corr (1.5 μA/cm²) values, which were kept for each simulation case. The table also presents the local current density Δi l actually polarizing the point where the potential shift ΔE is considered (top of the rebar under the centre of the probe) for each case and the average current density Δi a resulting from the application of RILEM recommendations.

Figure 10 .

 10 Fig.10 presents the longitudinal distribution of the polarizing current density computed on the top of the rebar for the different configurations simulated. The dashed line symbolizes the average current (Δi a ) assumed to polarize the steel rebar uniformly according to RILEM recommendations. Longitudinal distribution of the current density polarizing the top of the rebar

Fig. 11

 11 Fig.11 was drawn to help the comprehension of the three-dimensional distribution of the polarizing current resulting from the numerical experimentation.The representation is limited to the extension of the polarized surface S p involved in the calculation of the apparent polarization resistance R pa . It can be clearly seen that the polarizing current distribution is not uniform in the longitudinal direction, nor in the orthoradial direction. Under the center of CE, the current density is about 0.21 μA.cm -2 at the top of the rebar while it is about 0.13 μA.cm -2 at the bottom, showing that the polarization is much greater on the top of the rebar. The white dotted line links the points where the current density equals the average current density Δi a . It clearly shows that the current density (Δi a ) involved in R p estimation is actually not the current density (Δi l ) polarizing the point of the rebar where the potential response is collected, i.e. under the center of the probe.

Figure 11 .

 11 Figure 11. Distribution of the polarizing current density on S p for G2per

Table 1 .

 1

	Probe geometry	G	G	G
	Elements	69696	75157	69787
	Nodes	15298	16516	15392

Table 1 .

 1 Mesh information

Table 2 .

 2 Table 2 summarizes all the simulation parameters. Simulation parameters

	Concrete resistivity ρ	Concrete cover	Corrosion rate j	E	Anodic Tafel slope b	Cathodic Tafel slope b	B (mV)
	200 Ω .m	3 cm	1.5 µA/cm²	-707 mV/SHE	60 mV/dec	120 mV/dec	17.37

  Table 3 confirms this observation since 92 % of I CE is collected on S p .

Table 3 .

 3 Current injected by CE and actually collected by the surface S p

	Simulation case	Comment	I (μA)		(%)
	G	CE only	8.04	2.65	33
	G	CE + GR	4.87	4.48	92
	G	E -E axis parallel	4.88	6.64	136
	G	E -E axis perpendicular	4.88	4.68	96
	G	Rectangular CE	19.28	10.96	57

I (μA) I / I

Table 4 .

 4 R p and j corr estimations and errors

	cm²)	0.22	0.26	0.27	0.21	0.23
	Δi (μA/cm²)	0.43	0.21	0.16	0.16	0.31
	R (ohm.m²)	0.57	1.40	1.98	1.53	0.85
	R (ohm.m²)			1.16
	Error on R estimation (%)	-51	+ 21	+ 71	+ 32	-26
	Estimated j (μA/cm²)	3.05	1.24	0.88	1.14	2.04
	Actual value of j (μA/cm²)			1.5
	Error on j estimation (%)	+ 103.2	-17.3	-41.5	-24.3	+ 36.2


Abstract-In this paper, we present a free software written in Java, YARTISS, which is a real-time multiprocessor scheduling simulator. It is aimed at comparing user-customized algorithms with ones from the literature on real-time scheduling. This simulator is designed as an easy-to-use modular tool in which new modules can be added without the need to decompress, edit nor recompile existing parts. It can simulate the execution of a large number of concurrent periodic independent task sets on multiprocessor systems and generate clear visual results of the scheduling process (both schedules and tunable metrics presentations). Other task models are already implemented in the simulator, like graph tasks with precedence constraints and it is easily extensible to other task models. Moreover, YARTISS can simulate task sets in which energy consumption is a scheduling parameter in the same manner as Worst Case Execution Time (WCET).

I. INTRODUCTION

In order to evaluate the efficiency of a new approach in realtime systems, software simulation against other algorithms are commonly used. Due to the lack of a standard simulation tool approved by the real-time community, most of the researchers tend to create their own. This situation raises some concerns. On one hand, the presented results are hard to be validated without careful examination of the simulation tool. So these results might be biased toward the proposed approach either by adapted generation of testing tasks or by biased implementation against the compared algorithms. On another hand, reasons as out-of-date simulation tools or lack of good documentation can incite researchers to create new tools, which will lead to repetitive algorithms' implementations specially the common ones (e.g. RM, DM, EDF) while consuming the time and effort of researchers. Moreover, if a standard platform succeeds to emerge, one can compare his own policy with a very complicated one without having to understand the very specificity and optimizations of this one. Finally, the simulation protocols could be standardized, and more easily describable by the use of such a reference tool.

In this paper, we introduce YARTISS, a new simulation tool for real-time systems. Genericity is its main feature, by which we hope to overcome the problems mentioned before. New users are allowed to add their own implemented algorithms easily, with no need to understand how the simulator is built or works. We do not pretend to propose a perfect simulator, however we tried during its development to learn from our past tries [START_REF] Masson | RTSS v1 and v2[END_REF], [START_REF] Fauberteau | RTMSIM[END_REF]. YARTISS is written in the Java programming language, which is very popular nowadays and offers valuable attributes regarding portability. In order to ensure independence between the different features of the simulator and to reduce the possibilities of massive failures among them, we used modern programming paradigms, like module oriented programming and Java unit tests (JUnit) oriented development.

We tried to develop YARTISS keeping in mind that in order for a simulator to became a reference tool, it should have the following properties: 1) the software must be available under an open source license which gives any researcher the freedom to analyze, verify or modify its implementation ; 2) the Application Programming Interface (API) of the software must be well documented and the developer who wants to add or modify an algorithm should not have to read the entire source code in order to understand its behavior ; 3) each part of the simulator (its core, the tasks generator, the results analyzer, ...) must be independent from each other, and easily replaceable by an external module ; and 4) the simulator has to be easy to use in a way that a non-developer researcher can be able to use it. Due to its generality and modularity, we hope that YARTISS makes a valuable contribution to the long process of developing a standard simulation tool recognized by the real-time scheduling research community.

We expose our motivations in Section II. We review related works in Section III. Section IV presents the simulator functionalities. The program architecture is described in Section V. Case studies which demonstrate the extensibility of the tool are presented in Section VI. How to get the tool is explained in Section VII. Future works are discussed in Section VIII and finally we conclude in Section IX.

II. MOTIVATIONS: A BRIEF HISTORY OF YARTISS

Our first try in writing a real-time system simulator was called RTSS [START_REF] Masson | RTSS v1 and v2[END_REF] and developed between 2005 and 2008. The tool was first developed to test some algorithms to handle temporal fault tolerance and was later extended in order to test aperiodic tasks handling algorithms [START_REF] Masson | Userland Approximate Slack Stealer with Low Time Complexity[END_REF], [START_REF]Handling non-periodic events in real-time java systems[END_REF]. Lots of modifications had been made in a hurry with some assumptions on the behavior of existing classes without documentation. Then modifying anything could result in errors in another completely different parts. Moreover, although the tool was initially programmed in Java, it began to rely more and more on bash scripts to be launched and to transform output into human readable files. Based on this first tool, a second one, RTMSim [START_REF] Fauberteau | RTMSIM[END_REF], was developed between 2008 and 2011 in the purpose to simulate multiprocessor platforms [START_REF] Fauberteau | Laxity-Based Restricted-Migration Scheduling[END_REF]. The general key ideas were kept, but the first tool had become such complicated and unmaintainable that we had to start it over. Of course, all validated parts of RTSS which were of no interest at the time, were not reimplemented and so were lost (e.g. an implementation of D OV ER [START_REF] Koren | D over : An Optimal On-Line Scheduling Algorithm for Overloaded Uniprocessor Real-Time Systems[END_REF]). A third try was made in early 2011, RTSS v2 [START_REF] Masson | RTSS v1 and v2[END_REF], which was basically a rebuild of RTSS including energy consuming tasks and used for [START_REF] Chetto | Fixed priority Scheduling strategies for Ambient Energy-Harvesting embedded systems[END_REF]. Unfortunately, even if it is more usable today than the first RTSS, it suffered from the same problems of documentation, modularity and usability to simulate and exploit results of large scale simulations. Moreover, it seems difficult to extend it to simulate multiprocessor platforms.

So we came to the development of a new software: YARTISS. From the start, we aimed to produce a tool where the task model, the number of processors and behavior such as the energy consumption model are as easy as possible to modify. Another point on which we focused our attention is the usability of the user interface to produce human readable traces. Our goal was to develop a simulator able to produce evaluations as well as to debug our energy-related algorithms. When we wanted to use YARTISS for an another purpose, namely the simulation of directed graph model of real-time tasks which is a model of tasks with precedence constraints and concurrency (see [START_REF] Qamhieh | A Parallelizing Algorithm for Real-Time Tasks of Directed Acyclic Graphs Model[END_REF]), this was done without any problems, validating its extensibility.

III. RELATED WORKS

It exists a lot of tools to simulate or visualize instrumented real-time systems execution traces. Due to space limitation, we cannot provide here an extensible list of existing tools. For the instrumented execution analyzer tools, one can refer to [START_REF] Kato | A Loadable Real-Time Scheduler Suite for Multicore Platforms[END_REF], [START_REF] Holenderski | Grasp: Tracing, visualizing and measuring the behavior of real-time systems[END_REF]. Among open simulation tools, we can cite MAST [START_REF] Harbour | MAST: Modeling and analysis suite for real time applications[END_REF], Cheddar [START_REF] Singhoff | Cheddar: a Flexible Real Time Scheduling Framework[END_REF], STORM [START_REF] Urunuela | STORM: a Simulation Tool for Real-time Multiprocessor Scheduling Evaluation[END_REF] and FORTAS [START_REF] Courbin | FORTAS: Framework fOr Real-Time Analysis and Simulation[END_REF]. MAST permits to model distributed real-time systems and offer tools to e.g. test their feasibility or perform sensitivity analysis. Cheddar is written in Ada, handles the multiprocessor case and provides many implementations of scheduling, partitioning and analysis algorithms. It also comes with a user-friendly Graphical User Interface (GUI). Unfortunately, no API documentation is available to help with the implementation of new algorithms. Moreover, the choice of the Ada language reduces the potential additional developers number. Finally, FORTAS and STORM are tools which, as YARTISS, are written in Java, had modular architectures and permits to simulate task sets on multiprocessor architectures. They both represent very valuable contributions in the effort to provide open and modular tools and they are good candidates in our opinion to be widely used. Unfortunately, even if it is in its current state more usable than our previous tools, FORTAS seems to suffer from the same issues: its development is not open to other developers for now, we can only download .class files, no documentation is yet provided and it seems that no

IV. FUNCTIONALITIES

The two main features of our simulator are the simulation of the execution of one task set scheduled by a specific scheduling policy and the large-scale comparison of several scheduling policies in different scenarios, which implies its third feature: the random task sets generation.

A. Single Task Set Simulation

Through the GUI, we can load a task set either from a file, by random generation or entering its parameters manually. We can parametrize the desired simulation and run it by the click of a button. Several views are then proposed. The simulation parameters are the task set, the number of processors, the scheduling algorithm and the energy profile.

1) Task Models: YARTISS offers an open architecture that greatly facilitates the integration of different task models. The current version proposes two models, the first one is the Liu and Layland task model augmented with energy related parameters. All the tasks are independents and one task is characterised by its WCET C i , its worst case energy consumption E i , its period T i and its deadline D i . The second one is the Graph task model which is a common real-time task model on multiprocessor systems. It is used to implement systems consisting of number of missions in which there exist dependencies controlling their execution flow. In this model, a graph G i is a collection of real-time tasks {τ i,1 , τ i,2 , τ i,q }, sharing the same deadline D i and period P i of the graph, and they differ in their WCET C i,j . The directed edges between the tasks of the graph determine their precedence constraints, and since each task in the graph might have more than one successor and predecessor, concurrent execution can be generated. We will see in Section VI-C that it is easy to propose other task models.

2) Uniprocessor / Multiprocessor: Using the simulator, one can implement and test his own multiprocessor algorithms and partitioning policies. Some multiprocessor scheduling algorithms were implemented to test this feature like EDF and FP.

3) Energy Profile: Unlike many other simulators, this one permits to model the production and the consumption of energy in the system. It permits the user to model an energy harvester like a battery or a capacitor with limited or unlimited capacity. It can also model a renewable energy source by a charging function. The user can implement and use his own energy profiles. Figure 1 shows the GUI. Note that the view used to print the energy level can easily be augmented to print other metrics, such as system slack times for example.

a) Energy Source Model: We have implemented an energy source profile that models a renewable energy source represented by a battery with limited capacity and a linear charging function. This model is not the only possible one, the user can add his own profile by implementing the interface and injecting it into the engine of the simulator in few lines of code and without the need to open packages. An example is given in Section VI-B.

b) Consumption Model: It is important to note that for some works, energy consumption of a task must be modeled independently from its WCET [START_REF] Jayaseelan | Estimating the Worst-Case Energy Consumption of Embedded Software[END_REF]. This is why our simulator provides the ability to specify a consumption profile for each task of the system or choose one global profile applied to all tasks. A consumption model is represented by a function and must be able to provide the amount of energy consumed between two dates during the tasks execution i.e. the integral of the consumption function. Implemented models so far are: Linear consumption (not realistic but permits to establish some interesting preliminary conclusions) and Early instantaneous consumption where all the energy cost of a task is consumed as soon as a task is scheduled. This later model is assumed to represent the worst case scenario. As the energy source profile, a new consumption model can be added without having to open the simulator packages. An example is given in Section VI-B.

4) Scheduling Policy: The main purpose of the simulator is to test scheduling algorithms, compare them and show their performances and efficiency. Much attention has been focused on the design of this part of the simulator to make it as generic as possible so that users can add, override and inject new scheduling policies easily. There are currently twenty algorithms implemented including classic algorithms (RM, DM, EDF uni-and multiprocessor), heuristics for the energy constrained scheduling problem and policies for precedence graph model based on Least-Laxity-First (LLF). As with other parameters of the simulator run-time environment, the user can add and link his own algorithms in some lines of code without open core packages. An example is given in Section VI-A.

B. Run Large Scale Simulations

A major utility of the simulator is the large scale comparison of several algorithms or scheduling policies. It is done in the same way of a simple single simulation but on a large set of systems on different scenarios. The comparison is based on statistics that currently can be the number of failure or missed deadlines, the system lifetime, the amount of time spent at maximum energy level E max and minimum level E min and the average duration of idle period and busy periods. One can add his own metrics as demonstrated in Section VI-E. Multiple simulations are run concurrently by using the java multi-threading concept and so the duration of simulations is hardly reduced, taking advantage of hardware parallelism. We show in Figure 2 examples of charts which can be displayed with YARTISS.

C. Task Sets Generation

Performing large-scale tests requires a large set of task systems. To be credible, we have to use sufficiently varied systems to cover the possible task systems space. The simulator provides the ability to choose a generator according to desired scenarios and algorithms. The current version includes a generator inspired by the UUniFast-Discard algorithm [START_REF] Bini | Measuring the Performance of Schedulability Tests[END_REF] adapted to energy constraints. This algorithm generates task sets that respect the CPU utilization (U = Ci Ti ) and the energy utilization (U e = Ei Ti×P r ) imposed by the user. The basic version was not energy aware. We had to adapt it to produce time feasible and energy feasible systems. The principle is to distribute the load imposed on the tasks which compose the system. When we add energy cost to the task and an energy load to the system we end up with two parameters to vary and two conditions to satisfy. The algorithm in its current version distribute U and U e in the same way on the tasks then tries to find the pair (C i , E i ) which satisfies all the conditions namely U i , U e and P r < Ei Ci -P r < E max . The operation is repeated a few times and keeps the pair that approaches most the imposed conditions, finally, the algorithm returns a time and potentially1 energy feasible system. The user can use the described generator as he can write and use his own.

D. Graphical User Interface

To facilitate the use of the simulator by a large number of users, we provide our application with a GUI to make the features mentioned above available in an interactive and intuitive way. After the simulation of a single system with an energy profile and a scheduling policy, the user can follow and analyze the schedule on three different views: a time chart, a processor view and the energy curve which shows the evolution of energy (as mentioned before, other data can be monitored and print on this view).

In order to run simulations and get the results of a comparison of scheduling policies, the application offers a view that allows the user to select the scheduling policies to be compared, the energy scenarios and to run simulations. Thus the user can see the results as graph per scenario or per comparison criterion. This view offers also a debugging tool in which the user can analyze the result of comparison system by system and can optionally display the time chart of each system and in each scheduling policy. This can help to detect behaviors that differ in one algorithm to another. Then this simulator can produce results on a large scale of randomly generated task systems in order to evaluate a scheduling policy, but also easily explore properties of a new algorithm, find counter examples on hypothesis we can make by easily isolating degenerate cases. For example, in the case of energy scheduling, no optimal algorithm exists yet. In order to test empirically if a new algorithm is, an approach consists in running it on a large number of task systems, and ask the simulator to present only the systems where this algorithm fails whereas other heuristics succeed.

V. ARCHITECTURE

To meet the requirements specified in Section II, we have ensured that the design is as generic and open as possible by applying the appropriate design patterns and modular programming practices. We cut the project in four main modules: the engine or core module, the service module responsible for handling input/output with the engine, a module for GUI and finally a framework module that contains general tools necessary for the application. This module separation follows the classical Model-View-Controller design pattern (see Figure 3) which permits to isolate the core application part from its presentation and thus permits the engine to be generic and easily integrable in other tools.

A. Engine Module

The Simulation class, responsible of running a simulation, takes as parameters a container which embeds a scheduling policy, an energy profile and a set of tasks. An UML diagram of this module is given in Figure 4. The simulator is eventtriggered: on receipt of an event the scheduler is called to update the running tasks. It then calls the scheduling policy to choose the tasks to execute and the associated processors. This module so defines interfaces needed to execute (i.e. the scheduling policy) the energy source model and task energy consumption model. The interface implementation is not directly linked to the simulation object. In order to build an energy profile, for example, one have to register an instance of this class in a factory. This factory is responsible to create new instances when needed and completely hides the implementation. This allows anybody to create his own scheduling policy or his own task consumption model in a transparent way: one only has to write the model code and register an instance of his class by calling a method of the factory in order to make the new class available through the GUI. Case study are given in Section VI in order to demonstrate this assertion.

B. Service Module

This module makes the interface between the simulator core and the user interfaces. It serves the necessary data to the GUI and gets back the user modifications from it. It also enables to prepare the simulation parameters, or to set up a large scale test. This module component has been made in such a way it permits to reuse the same classes for an other interface. (e.g. a textual user interface).

C. Framework Module

This is a toolbox module that contains generic classes and functions in order to facilitate the code writing. This module p u b l i c c l a s s MainDemoSP { p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) { S c h e d u l i n g P o l i c y F a c t o r y . r e g i s t e r P o l i c y ( new LLF ( ) ) ; DesktopMain main = new DesktopMain ( ) ; main . s e t V i s i b l e ( t r u e ) ; } } c l a s s LLF e x t e n d s A b s t r a c t M u l t i P r o c S c h e d u l i n g P o l i c y { @Override p u b l i c S t r i n g g e t P o l i c y N a m e ( ) { r e t u r n " LLF " ; } @Override p u b l i c I T a s k S e t c r e a t e T a s k S e t ( ) { r e t u r n new A b s t r a c t T a s k S e t ( new C o m p a r a t o r < I T a s k > ( ) { @Override p u b l i c i n t compare ( I T a s k t 1 , I T a s k t 2 ) { l o n g l a x i t y 1 = t 1 . g e t D e a d l i n e ( )t 1 . g e t R e m a i n i n g C o s t ( ) ; l o n g l a x i t y 2 = t 2 . g e t D e a d l i n e ( )t 2 . g e t R e m a i n i n g C o s t ( ) ; i n t cmp = ( i n t ) ( l a x i t y 1l a x i t y 2 ) ; i f ( cmp ==0) r e t u r n ( i n t ) ( t 1 . g e t P r i o r i t y ( )t 2 . g e t P r i o r i t y ( ) ) ; r e t u r n cmp ; Listing 1. How to add a scheduling policy makes good use the Java concurrency API and capacities of modern multiprocessor to accelerate the execution of several simulations. It follows the producer consumer design pattern in order to permit e.g. to run several simulations in the same time, sending the result of each one to the consumer which computes statistics and updates the GUI. This is also used for the task set generation. Several producers can run in concurrency, sending the produced tasks to consumers which write them in files. This speeds up the generation and simulation of large scale tests.

D. View Module

This module contains the necessary classes for the GUI.

VI. CASE STUDIES

We demonstrate in this section that it is easy to tune the simulator to address specific needs.

A. Adding a Scheduling Policy

To add a new scheduling policy, e.g. LLF, one first needs to add the simulator's .jar files to a new project in his favorite IDE and then to provide an implementation of the interface ISchedulingPolicy. The policies are named to identify them among all others. The method getPolicyName() must so return the policy's name. To permit the scheduling policy factory to instantiate the new class, one must implement the method newInstance() that returns a new instance of his policy class.

Then he specifies the task set model by implementing the method createTaskSet(), giving him the choice to use the available task models or to create a new one according to how tasks must be sorted. ITaskSet is an iterable of ITasks that sorts tasks and returns a sorted set of activated tasks at time t. For LLF, tasks must be sorted by their laxity. To decide which tasks to execute and on which processor the method chooseNextTasks() must be implemented. Listing 1 shows the code needed to use LLF as an external module with the simulator.

B. Adding an Energy Profile

The same methodology can be applied to add a new energy consumption profile. Listing 2 shows the code needed to use a logarithmic consumption profile, still as an external module.

C. Adding a Traffic Model

To add a new task model, one has to implement the interface ITask and register the class into the Schedulable factory. The current version of the interface describes a standard Liu and Layland task. It can be used in its current state to model another kind of tasks like we do with graph tasks and tasks with precedences without open the packages. If it is not sufficient, one can extend it to make it more suitable to his needs. For example, to implement uncertain task model where the tasks execution times are specified into an interval, one can implement the interface ITask and modify the behavior of some methods to permit the exceeding of WCET by manipulating the remainingCost() method and the conditions of jobs end. Due to space limitation, we cannot give the code here, but it will be added to the demonstration package code suite (see Section VII).

D. Using an External Module to Generate Tasks

One of the advantages of the simulator is that it works with files of standard format like XML. It lets us use external tools if needed to generate tasks by converting the output file with XSL transformation to get an input file understandable by our simulator.

E. Adding More Metrics

If one wants to count the number of preemptions, for example, he has to modify the class Simulator to check each of tasks begin and end events to detect preemptions and increment a counter in the statistics container. Then, to show the new metric on GUI he must modify the class Metric to add the new one and the necessary algorithms to compute maximum, minimum and average. Clearly, this is not a good design. This point is discussed in Section VIII.

VII. DISTRIBUTION

The project is available from the GForge collaborative development environment hosted at https://svnigm.univ-mlv. fr/projects/yartiss/. This environment provides a subversion server allowing anonymous checkouts, documentation hosting, RSS feeds subscriptions, and public forums. A web page dedicated to YARTISS is also available at http://yartiss.univ-mlv.fr. In addition to a general presentation of the tool, it proposes a demo applet version which allows interested readers to try YARTISS directly from their web browser and an application form to allow anybody to share external modules.

VIII. FUTURE WORKS

The actual release offers many important and expandable features but the simulator is still under development. Some parts of the project have been made in a hurry which has prevented them to be as clean as they could. For example, the implementation of comparison metrics is strangely coupled with simulation classes and if we want to add a new metric we will be forced to open the engine module and modify internal classes as described in Section VI-E. This may be dangerous and not acceptable architecturally. Improvements are planned to address such weaknesses, like we have done with energy profiles and scheduling policies. Some other future works are planned: 1) We want to provide a command line user interface to allow the use of our simulator without the graphic environment to permits its use inside automated scripts and/or through a distant machine. This should be done easily because of the adopted architecture and responsibilities separation. 2) If we use XML format mostly in all inputs and outputs in order to be able to reuse other external tool functionalities, this feature must be generalized to the simulation results in order to permit their visualization with an external tool (e.g. GRASP [START_REF] Holenderski | Grasp: Tracing, visualizing and measuring the behavior of real-time systems[END_REF]). 3) An additional work is needed on the description of processors and we need to add the ability to execute on heterogeneous and independent processors in terms of computational power, memory and energy consumption. This could also lead to integrate research on distributed systems. 4) Finally, concerning the energy part, we must integrate the Dynamic Voltage and Frequency Scaling (DVFS) model in order to be compliant with most recent works in this area.

IX. CONCLUSION

In this paper we presented YARTISS, a real-time multiprocessor scheduling simulator. A consequent effort has been made to make it as extensible as possible. To justify the need for an open and generic tool, we presented the history of YARTISS development. Then we briefly presented existing simulation tools. We have described the three main functionalities of YARTISS: 1) simulate a task set on one or several processors with monitoring the system energy consumption, 2) concurrently simulate a large number of task sets and present the results in a user friendly way that permits to isolate interesting cases, and 3) randomly generate a large number of task sets. Then, in order to demonstrate the modularity and extensibility of our tool, we presented its architecture and five case studies that show how to add functionalities, in most cases without having to open the project archive. Finally we gave the instructions to test YARTISS and presented some improvement features we will implement.

We hope that this software can become a first step toward a widely adopted simulation tool through the real-time scheduling community.

Figure 1 .

 1 Figure 1. Energy and Multiprocessor Simulation views

Figure 2 .

 2 Figure 2. Concurrent large scale simulations: histogram and curves views

Figure 3 .

 3 Figure 3. Modules connexion UML Diagram

Figure 4 .

 4 Figure 4. The engine module UML diagram

  } } ) { @Override p u b l i c S o r t e d S e t < I T a s k > g e t A c t i v e T a s k s ( l o n g d a t e ) { S o r t e d S e t < I T a s k > a c t i v e T a s k s = new T r e e S e t < I T a s k > ( c o m p a r a t o r ) ; f o r ( I T a s k t : t h i s ) i f ( t . i s A c t i v e ( ) ) a c t i v e T a s k s . add ( t ) ; r e t u r n a c t i v e T a s k s ; } } ; } @Override p u b l i c P r o c e s s o r [ ] c h o o s e N e x t T a s k s ( P r o c e s s o r [ ] p r o c e s s o r s , I T a s k S e t t a s k S e t , I E n e r g y P r o f i l e e n e r g y P r o f i l e , l o n g d a t e , E v e n t G e n e r a t o r evGen ) { i n t i = 0 ; f o r ( I T a s k t a s k : t a s k S e t . g e t A c t i v e T a s k s ( d a t e ) ) { i f ( i < p r o c e s s o r s . l e n g t h ) { l o n g h l c e t = e n e r g y P r o f i l e . howLongCanExecute ( t a s k ) ; i f ( h l c e t <= 0 ) { evGen . g e n e r a t e E v e n t ( " e n e r g y _ f a i l u r e " , t a s k , d a t e , n u l l ) ; p r o c e s s o r s [ i ] . s e t N e x t T a s k ( n u l l ) ; } e l s e { evGen . g e n e r a t e E v e n t ( " c h e c k _ e n e r g y _ s t a t e " , t a s k , d a t e + 1 , n u l l ) ; p r o c e s s o r s [ i ] . s e t N e x t T a s k ( t a s k ) ; } } i ++; } f o r ( ; i < p r o c e s s o r s . l e n g t h ; i ++){ p r o c e s s o r s [ i ] . s e t N e x t T a s k ( n u l l ) ; } r e t u r n p r o c e s s o r s ; } @Override p u b l i c I S c h e d u l i n g P o l i c y n e w I n s t a n c e ( ) { r e t u r n new LLF ( ) ; } }

1 p u b l i c c l a s sListing 2 .

 2 MainDemo { p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) { 3 S c h e d u l i n g P o l i c y F a c t o r y . r e g i s t e r P o l i c y ( new LLF ( ) ) ; C o n s u m p t i o n P r o f i l e F a c t o r y . r e g i s t e r C o n s u m p t i o n P r o f i l e ( new LogConsumption ( ) ) ; 5 DesktopMain main = new DesktopMain ( ) ; main . s e t V i s i b l e ( t r u e ) LogConsumption implements I E n e r g y C o n s u m p t i o n P r o f i l e { 11 @Override p u b l i c S t r i n g getName ( ) { r e t u r n " l o g " ; } @Override p u b l i c L i s t < Double > g e t P a r a m e t e r s ( ) { r e t u r n n u l l ; } 13 @Override p u b l i c v o i d s e t P a r a m e t e r s ( L i s t < Double > p a r a m s ) {} 15 @Override p u b l i c l o n g getConsumed ( l o n g wcet , l o n g wcee , l o n g r o m a i n i n g T i m e C o s t , l o n g d u r a t i o n ) { 17 d o u b l e a = w c e tr o m a i n i n g T i m e C o s t ; d o u b l e b = a + d u r a t i o n ; 19 i f ( b > w c e t ) b = w c e t ; i f ( ( b-a ) <= 0 ) r e t u r n 0 ; 21 l o n g r e s u l t = ( l o n g ) Math . l o g ( b / a ) ; i f ( r e s u l t > wcee ) r e s u l t = wcee ; 23 r e t u r n r e s u l t ; } 25 @Override p u b l i c I E n e r g y C o n s u m p t i o n P r o f i l e c l o n e P r o f i l e ( ) { 27 r e t u r n new LogConsumption ( ) ; } 29 } How to add a new energy profile

  Single Task Set Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV-A1 Task Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV-A2 Uniprocessor / Multiprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV-A3 Energy Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV-A4 Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV-B Run Large Scale Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV-C Task Sets Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV-D Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . YARTISS: A Tool to Visualize, Test, Compare and Evaluate Real-Time Scheduling Algorithms Younès Chandarli * † , Frédéric Fauberteau ‡ , Damien Masson * , Serge Midonnet † and Manar Qamhieh † ESIEE Paris, 2 bld Blaise Pascal, BP 99, 93162 Noisy-le-Grand CEDEX, France † Université Paris-Est Marne-la-vallée, 5 bld Descartes, Champs sur Marne, 77454 Marne-la-Vallée Cedex 2, France ‡ CEA List, LaSTRE, Point Courrier 94, Gif-sur-Yvette, F-91191 France

		Introduction
	II	Motivations: A Brief History of YARTISS
	III	Related Works
	IV	Functionalities IV-A	Université Paris-Est, LIGM UMR CNRS 8049,

*

Until now there is no feasibility test that takes into account energy constraints, we hope to have the possibility to present some key ideas to RTSOPS, conjointly organized with ECRTS and WATERS