Loïc Besnard
email: loic.besnard@irisa.fr

Pedro Pinto
email: p.pinto@fe.up.pt

Imane Lasri

João Bispo
email: jbispo@fe.up.pt

Erven Rohou
email: erven.rohou@inria.fr

João M P Cardoso

A Framework for Automatic and Parameterizable Memoization

Keywords: memoization, compiler optimizations, source-to-source

Improving execution time and energy efficiency is needed for many applications and usually requires sophisticated code transformations and compiler optimizations. One of the optimization techniques is memoization, which saves the results of computations so that future computations with the same inputs can be avoided. In this article we present a framework that automatically applies memoization techniques to C/C++ applications. The framework is based on automatic code transformations using a source-to-source compiler and on a memoization library. With the framework users can select functions to memoize as long as they obey to certain restrictions imposed by our current memoization library. We show the use of the framework and associated memoization technique and the impact on reducing the execution time and energy consumption of four representative benchmarks.

Motivation and significance

Improving execution time and energy efficiency is of paramount importance in many applications. A possible optimization that can be used for such improvements is memoization [START_REF] Michie | memo" functions and machine learning[END_REF], which is the technique of saving the results of computations so that future computations can be skipped. Performance can be improved by caching execution results of memoizable functions, and retrieving them instead of recomputing a result when a new call is performed with repeated inputs. In this work we introduce a memoization framework, integrated in the ANTAREX tool flow [START_REF] Silvano | The ANTAREX tool flow for monitoring and autotuning energy efficient HPC systems[END_REF], which can automatically apply this technique to memoizable functions.

We define memoizable functions [START_REF] Suresh | Intercepting Functions for Memoization: A Case Study Using Transcendental Functions[END_REF][START_REF] Suresh | Compile-Time Function Memoization[END_REF] as pure functions, i.e., deterministic and without side effects, with three additional constraints imposed by our current implementation of memoization. First, functions must have between 1 and 3 parameters of the same type T . This limitation arises from our current choice of hash function, which combines all the arguments and, as such, requires them to have the same bit length. After combining all arguments with XOR operations, we take the high-order and the low-order bits of the result and combine them again using a XOR, leaving us with half the original bits. We repeat this process until we arrive to the number of bits required to index the hash table, masking any bits if necessary. The second constraint is that functions must return data of the same type T . Finally, the third constraint is that T is one of int, float or double.

In applications with memoizable functions in critical code sections, memoization may provide important execution time reductions and energy consumption savings. Our memoization framework relies on internal tables that store the results of previous computations and replace future calls by table lookups. The elements of the internal tables are indexed with a hash calculated from the call arguments of the memoized function.

A memoization approach can start by profiling the application and by identifying the contribution of memoizable functions to the overall execution of the application. A profiling step may also provide values to setup an initial version of the internal table of the memoization technique. Our framework allows loading internal tables before application runs (e.g., with profiling data) and/or update them at runtime (allowing adaptation to execution contexts not considered during the profiling phase). This solution may enable savings in multiple kinds of applications and allow users to write runtime adaptivity strategies to make applications more resilient to context changes and able to achieve predetermined execution thresholds.

The memoization technique can be integrated into any C or C++ application that has memoizable functions or methods. Based on the selected memoizable functions, our framework generates a new version of the application enhanced with memoization support by relying on the Clava1 source-tosource compiler. The framework is also responsible to generate the C library that contains the core of the memoization implementation, which is linked with the newly generated application. The compilation process of Clava is controlled by the LARA [START_REF] Cardoso | Performance-driven instrumentation and mapping strategies using the lara aspect-oriented programming approach[END_REF] Domain-Specific Language (DSL). With this setup, it is also possible to use LARA to perform analyses and transformations on the code, e.g., where and how to apply the memoization technique in this specific case. The main modular unit in LARA code is the aspect, which can be considered as a function, with input and outputs, but that has the capability of interacting with the internal representation of the application source code. When several aspects are developed to achieve a specific goal, we have a LARA program, which we often refer to as a strategy.

Our memoization framework is based on the memoization approach presented in [START_REF] Suresh | Compile-Time Function Memoization[END_REF], that uses a dynamic library and applies memoization at binary level. Our framework has been generalized for C++, adds extensions that allow application flexibility, adds options regarding table loading and table runtime updating, and is applied at the level of the application source code.

Software description

The software solution presented in this paper relies on two different components which are combined to easily enhance an application with memoization support. The first component is Clava, a source-to-source compiler able to automatically generate a new version of the application code with the necessary changes to support memoization. This is performed through a series of LARA aspects the user can call and parameterize, all distributed as part of the Clava memoization library.

The second component is the memoization C library itself, which is generated from a configuration file that identifies the functions on which to apply memoization. The library is compiled and linked against the version of the input application that has been modified by Clava. As shown in Figure 1, the use of this memoization solution consists of three steps: 1) source-to-source compilation; 2) generation and compilation of the memoization library; and 3) compilation of the application linked with library. Consider the memoizable C function foo shown in Figure 2. This is a pure function which takes a single float parameter and returns data of the same type. The source-to-source step consists of two phases, with the first phase being the addition of another function to the program. This new function wraps the target function and includes the memoization logic to interface to the memoization library. This wrapper is also illustrated in Figure 2. The second phase replaces all calls (it is possible to specify a LARA aspect that applies memoization to only certain call sites) to the original function, foo, with calls to its corresponding wrapper, foo wrapper. This technique works for C and C++ functions as well as for C++ methods, and takes into account name mangling, function overloading, and references to objects.

The user can, through LARA aspects or manually, further change the application to interact with the memoization library. For instance, the memoization library exposes a set of variables to control its internal behavior. To dynamically stop and restart the memoization for a specific function, it is possible to change the variable Memoize <mname>, where <mname> corresponds to the mangled name of the target function. Similarly, to control the table update policies the user can change the variables alwaysReplace <mname> and FullyOffLine <mname>. This can be used to control the runtime behavior of the memoization library with respect to the update of the internal table.

The generation and compilation of the memoization library start from the function identifications file (funs-static.def). The LARA library for memoization, besides changing the source of the application, generates this file. In this article, we propose the use of memoization through Clava, by relying on aspects programmed with the LARA DSL. However, it is also possible to use the standalone library2 without relying on LARA and the Clava compiler. To do so, the user must manually write the function identifications file (funs-static.def), change the source code to include the wrappers and replace calls from the original calls to the wrappers. The rest of the flow remains the same: generate the library and link it when compiling the application.

The advantage of using LARA strategies is that the memoization library is integrated into the application without performing manual modifications of the source code. The code generated by Clava is then compiled and linked with the associated generated memoization library.

In order to enhance an application with memoization with LARA strategies, users can call the library aspects and define a number of parameters.

First, it is possible to define the size of the internal table that stores the computation data. This decision becomes a tradeoff that can be fine-tuned according to the needs of the current application or scenario. A larger table holds more data but requires more memory. On top of that, depending on the underlying architecture, the size of the table may impact cache performance. Second, one can specify a file from which to load a previously initialized memoization table. If none is specified, the program starts with an empty table. This allows building memoization tables from one execution to the following and keep the most frequently requested outputs. For this feature, we can also specify a file on which the results of the execution are saved. Finally, if one intends to use the approximation capabilities, it is also possible to configure the library at this step to disregard a number of bits from the input representation of the arguments to the memoized function.

Technique Details

The first operation of the wrapper is to perform a lookup to check whether the output for the provided input is already stored. The lookup operation will hash the input to get the correct slot in the internal table. If this position is empty, the lookup fails and returns false, signaling a miss. If this happens, the original target function is called and the correct value is returned. On the other hand, if the table slot is not empty, we compare the stored input with the input of the current call. If these values are the same, which we consider a hit, the lookup function sets the output value and returns successfully. The wrapper will then return this value. If the inputs are not equal we have a collision, meaning that two different inputs were hashed into the same slot.

In this case, the lookup function returns false. Once again, the return value is computed by calling the original function, which is eventually returned.

The correct value is always returned whether there was a hit, a miss or a collision. The table update logic happens after the correct output value has been computed (or fetched from the table), so it is inconsequential to the safeness of the technique. Figure 3 shows two flowcharts describing the overall memoization technique (on top) and the lookup process (on bottom). Clava is a source-to-source compiler, written in Java, that uses Clang3 as a front-end to parse C and C++ source code. The compiler maintains an internal representation of the application which is analyzed and transformed according to the strategies defined in the input LARA code. Clava includes multiple LARA libraries that can be used for different purposes, including the memoization framework presented in this article.

Software Architecture

The Library Generator is a sed script that takes the function definitions file (*.def) and several code templates to generate the final customized code of the memoization library. This code can then be compiled into a library.

The library itself maintains a table for each memoized function as well as the associated variables for runtime control and the interface functions. These are the functions called from each of the wrappers inserted with the Clava memoization strategies.

The final application retains the original functionality. In the source code, the difference is that it has a wrapper for each target function. This wrapper is called instead of the original and performs calls to the generated memoization library.

Software Functionalities

The memoization framework presented in this paper allows users to semiautomatically enhance an application with memoization support. The typical user intervention is related to the configuration options and to the selection of the functions to memoize. However, function selection can be also performed without user intervention as the LARA library also provides code to automatically detect memoizable functions and methods. This option returns the list of detected memoizable functions and users can decide whether to apply memoization on these returned functions.

1 import antarex . memoi . Memoization ; The LARA library integrated into the Clava compiler has several aspects that are used to apply memoization to different types of functions: mathematical functions (from math.h), C functions and C++ functions. For each of these, there are LARA aspects that allow the user to memoize a function with default parameters or by defining all the needed parameters. Additionally, the library includes an aspect that automatically performs memoization on all math.h functions, and aspects that apply memoization to C++ functions and methods taking into account function overloading.

Since our framework includes source-to-source compilation, it is possible to write sophisticated analysis and transformation strategies using LARA aspects. This can be used, for instance, to select which functions to memoize using any user-devised heuristics on top of the list of possible memoizable function returned by the library.

Another feature of our memoization library is the possibility of using approximation when dealing with floating point numbers. This essentially removes a number of (user-specified) bits from the inputs to the function, grouping together close numbers and returning the same output for those.

More precisely, we remove a number of the least significant bits of the mantissa. In scenarios where some loss of accuracy is tolerable (e.g., in some cases of image processing) this can provide further reductions in execution time and energy consumption.

All of these features enhance an application with the capability of taking advantage of repeating inputs on some specific and critical functions, while still being able to accommodate changes, since the table can be dynamically updated. Furthermore, users can explore runtime strategies to decide when to change the update policies of the table or completely turn memoization off, thanks to the variables that expose this type of control for each target function.

Illustrative Examples

This section presents an example of a LARA aspect that illustrates the interface between the user and the memoization library described in the previous section.

Consider an example of a C application that uses the mathematical functions cos, acos and sqrt. Moreover, the profiling of the application shows that there is a large number of calls to a user function called myfunc. Figure 5 shows a LARA aspect, named Launcher, that can be used to apply memoization. First, we import the class that contains the memoization aspects (line 1). Then, the functions to be memoized are identified (lines 5-6), preceded by an initialization (line 4) and followed by a finalization stage (line 7). This is all the LARA code user needs to write to enhance a C/C++ application with memoization.

The execution of the aspect will produce (1) a new version of the application in which all the references to FOO (FOO is one of cos, acos, sqrt, myFunc) are replaced by FOO wrapper, and (2) the funs-static.def file that contains a line per memoized function as shown in Figure 6. Each line encodes all the required parameters for the generation of the memoization C library.

The Memoize Function aspect is a helper aspect that automatically sets some default parameters when calling other, more general aspects. For instance, line 4 of Figure 6 exposes some of the parameters that can be specified on those more general aspects. It specifies that it is a C user function (value 2), followed by the name of the function (myfunc) and its associated wrapper (myfunc wrapper), and the identification that this function has 3 inputs arguments of double type. Other parameters are provided to control the memoization framework: in particular the 2 last ones (no, 65536) are used to specify the policy to manage possible conflicts when updating the table (replace or not) and to define the size of the internal table. LARA aspects are provided to the user to set these parameters, but in the presented example we call simpler versions that use default values.

For example, Figure 7 shows an example of the implementation of one of the LARA aspects that are part of the memoization library. This is library size and we tested with tables holding 256 and 65,536 elements. The second parameter is whether to perform table updates in case of hash collisions. For this experiments we do not consider the setup of tables prior to the execution of the application. Thus, when the memoization-enhanced program starts executing, its tables are empty and start being filled as requests are performed. It is possible that two different inputs for the same function produce the same hash value, which leads to a collision. Our strategy in this example is to either ignore the collision and not change the table, or replace the previous entry with the newest one.

Our benchmark applications are:

• atmi [6] is a library for modeling steady-state and time-varying temperature in microprocessors, with examples using j0, j1, exp and sqrt.

• equake is an application extracted from SPEC OMP. It has calls to the mathematical functions sin, cos and sqrt in its critical region.

• fft is a Fast Fourier transform implementation extracted from the BenchFFT4 benchmark suite. It calls the functions sin and cos.

• rgb2hsi is a benchmarking kernel that converts images from RGB model to HSI model. It calls cos, acos, sqrt, and a pure user function.

The tests have been performed on an Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz and the C/C++ codes were compiled using GCC with -O3.

To address possible concerns that this technique may be too dependent on which inputs it is tested on, we have used several different inputs for the fft and rgb2hsi benchmarks. For fft, we tried three numbers of samples (100000000, 200000000, 300000000) and three frequencies (123.6, 256.89, 88.7). For rgb2hsi, we used eight different images. The other benchmarks were tested with a single input due to the lack of available workloads.

Table 1 presents the speedups obtained with the four tested memoziation configurations, over the original version (i.e., without memoization). Table 2 presents, for the same configurations, the energy consumption improvements over the original. This was measured using a utility tool that relies on Intel RAPL counters. Values below 1 represent a reduction in energy consumption.

For instance, for the atmi benchmark with a 65536-nu configuration, we only consume 71% of the original (0.71 in the table ).

Overall, the use of our memoization framework allows us to achieve considerable reductions in both execution time and energy consumption. This is confirmed with the Mean line, which presents the geometric mean across benchmarks of the results obtained with each tested configuration. Considering execution time, the worst average result is a 0.97× slowdown when using a small table and no update (in the case of collisions). On the other hand, a larger table with updates enabled, achieves an average speedup of 1.16×.

With respect to the atmi and rgb2hsi benchmarks, a larger table has a positive impact, while this does not happen in the other two benchmarks.

atmi and rgb2hsi show only a small number of hits (i.e., results found on the table) on the 256 table, which grows considerably when the table size is increased, while on the equake and fft benchmarks this growth is not as large. This can happen because of the way inputs to the memoized functions change over time and how many different values these inputs take.

We note that enabling update in the case of hash collision improves the obtained results. This is the case with every benchmark tested, except with atmi in the case of using a large table. When updating is disabled, it is possible to initially fill the table with inputs that are among the least frequently requested during the rest of the execution. This is somewhat corrected by turning on the ability to update in case of collision, since most frequent inputs should be able to push out other, less-frequent, inputs and remain in the table for most of the execution. However, in the specific case of atmi, the Bessel functions show an increasing number of collisions when updating is enabled, which seems to indicate that two frequent inputs are colliding and continually pushing each other off the table, causing misses and forcing the recalculation of their corresponding outputs.

The fft benchmark shows a performance degradation when using memoization without updates, regardless of the table size. When looking at more detailed execution data (not presented here), it is possible to see that there is a single hit for cos (out of 200,000,000 calls) and 0 hits for sin (out of 100,000,000 calls). This means the tables are initially filled with inputs that are not requested again in the future, causing an overhead which slightly degrades the original performance. On the other hand, when the updates are enabled, these initial values are eventually overwritten by more frequent inputs. The number of hits increases to 137,227,265 and 74,893,090 for cos and sin, respectively.

The rgb2hsi benchmark shows a severe drop in performance when using a small table without update on collisions. This benchmark benefits greatly from both a larger table and updates to remove less frequent values from the table. The number of hits increases by over 6× by simply using the larger table, in the case of no update. This may happen when inputs are distributed In practice we do not frequently use tables as small as 256 elements.

However, this illustrates the tradeoffs a user can perform to fine tune this framework to the current needs. In some scenarios, such as when targeting embedded systems with limited resources, a smaller table could be needed due to memory restrictions. Considering there are no other variables on the experiments other than how memoization is applied, we can confidently say the shown differences are caused by the technique.

Conclusions

This article presented a framework to automatically apply memoization to C/C++ applications. The resulting applications store outputs of pure functions mapped by their inputs. If these pure functions are called with the same inputs, the framework returns the stored value instead of recomputing it. Hence, this technique may lead to execution time and energy consumption improvements by simply avoiding unnecessary computations in scenarios where critical functions are called with repeating inputs. Our framework consists of two main components. First, a source-to-source compiler that modifies input C/C++ applications by targeting memoizable functions and replacing their calls with calls to wrappers that interface with a C memoization library. This library, the second component of our framework, maintains all the data structures and contains memoization logic needed to enhance applications with this optimization. The source-to-source compiler can be controlled by the user to perform analyses and decide which functions to target. We showed the impact of the memoization technique in four representative benchmarks and the usefulness of our software by measuring reductions in execution time and energy consumption.

Figure 1 :

 1 Figure 1: Tool flow of the proposed memoization framework.

Figure 2 :

 2 Figure 2: A memoizable C function and its wrapper.

Figure 3 :

 3 Figure 3: Flowcharts describing the overall memoization technique and the lookup process.

Figure 4

 4 Figure 4 shows an overview of the architecture our memoization framework. The four main components can be divided into two groups, generation and execution. The generation group, with Clava and the Library Generator, is responsible for generating the execution group, composed by the augmented application code and the memoization library. The dashed arrows indicate that one component generates another and the solid arrows indicate runtime interactions between components.

Figure 4 :

 4 Figure 4: Main components of the proposed memoization solution.

Figure 5 :

 5 Figure 5: An example of LARA Launcher aspect defined for memoization.

Figure 6 :

 6 Figure 6: An example of funs-static.def file.

1

  aspectdef M e m o i z e _ M e t h o d _ o v e r l o a d i n g _ A R G S of the selected type original version as well as four different memoized versions representing a combination of two parameters. The first parameter is the internal table

Table 1 :

 1 Speedups of the memoization versions over the original version. Each of the four columns corresponds to memoized benchmarks with two different parameters, table size and collision update policy (nu for no update, and u for update). The last line of the table presents the geometric mean of the speedups per configuration.

	Benchmark	256-nu	256-u	65536-nu	65536-u
	atmi	1.01	1.02	1.46	1.26
	equake	1.02	1.06	1.01	1.04
	fft	0.98 ± 0.01	1.13 ± 0.02	0.98 ± 0.02	1.12 ± 0.02
	rgb2hsi	0.89 ± 0.02	1.13 ± 0.10	1.18 ± 0.06	1.22 ± 0.08
	mean	0.97 ± 0.06	1.08 ± 0.05	1.14 ± 0.22	1.16 ± 0.10

Table 2 :

 2 Energy consumption improvements of the memoization versions over the original version. Each of the four columns corresponds to memoized benchmarks with two different parameters, table size and collision update policy (nu for no update, and u for update).Values below 1 represent a reduction in energy consumption. The last line of the table presents the geometric mean of the improvements per configuration.

	Benchmark	256-nu	256-u	65536-nu	65536-u
	atmi	1.02	1.01	0.71	0.83
	equake	0.96	0.93	0.95	0.94
	fft	1.03 ± 0.03	0.89 ± 0.03	1.04 ± 0.03	0.90 ± 0.03
	rgb2hsi	1.20 ± 0.03	0.95 ± 0.08	0.88 ± 0.04	0.86 ± 0.05
	mean	1.05 ± 0.11	0.94 ± 0.05	0.89 ± 0.14	0.88 ± 0.04
	in such a way that most calls use the same set of inputs, but this set is large
	enough so that it cannot fit into a small table.

Table 3

 3 presents the results of a two-tailed, paired-sample t-test performed on the execution time measurements of the fft and rgb2hsi benchmarks (the two benchmarks tested with multiple inputs). Tests on the energy results follow the same pattern. This statistical test was applied to compare the results of each memoization configuration against the results of the original version (i.e., without memoization), when running with different inputs (9 fft configurations and 8 rgb2hsi images). There is a single configuration (highlighted in the table) on which we cannot claim statistical significance

Table 3 :

 3 Results of a two-tailed, paired-sample t-test. = 0.05, the testing of the rgb2hsi benchmark with a table of 256 elements and no update in case of collisions. For the other seven out of eight configurations, the t-test considers the data to be statistically different.

	Benchmark	256-nu	256-u	65536-nu	65536-u
	fft	t = 3.50	t = 6.45	t = 2.91	t = 6.01
	(df = 8)	p = 0.008	p = 0.000	p = 0.020	p = 0.000
	rgb2hsi	t = 3.63	t = 2.02	t = 2.50	t = 2.53
	(df = 7)	p = 0.008	p = 0.083	p = 0.041	p = 0.039
	with α

https://github.com/specs-feup/clava

https://gforge.inria.fr/projects/memoization

https://clang.llvm.org/

http://www.fftw.org/benchfft

Acknowledgments

This work was partially funded by the ANTAREX project through the EU H2020 FET-HPC program under grant no. 671623. Bispo acknowledges the support provided by Fundação para a Ciência e Tecnologia (FCT), through the Postdoctoral scholarship SFRH/BPD/118211/2016.

code and not the code a user needs to write. This is used to target C++ methods and allows the user to specify all memoization parameters. This example defines the memoization (lines 1-13) of a C++ method (aMethod) of a class (aClass) with nbArg parameters of the same type as the returned type (pType).

After some verifications, which are not presented in this example, the target method is searched in lines 17-24. In case of success, the code of the wrapper is added (line 28) to produce the memoization library, and the code of the application is modified for calling the generated wrapper (line 30), which is also declared as a new method of the class.

Impact

In order to show the impact of our memoization framework we have applied it to four C/C++ programs. For each program we have tested the


Olivier Chiello

Adrien Le Bellec

Marie-Agnès Pallas

Patricio Munoz

Valérie Janillon

Characterisation of wheel/rail roughness and track decay rates on a tram network

Keywords: Noise mapping, CNOSSOS-EU method, Light rail, Rolling noise, Tram noise, Wheel/rail roughness, Track decay rate, Tram track I-INCE Classification of Subject Number: 10

From the beginning of 2019, the new CNOSSOS-EU method shall be used for strategic noise mapping in application of Directive 2002/49/EC instead of national noise prediction methods. For the railway part, the operators are responsible for providing input data describing the different noise sources characterising the railway system. Concerning the rolling noise, the vehicle and the track have to be distinguished by providing specific transfer functions and wheel/rail roughness spectra. For conventional railways, default values are given in the CNOSSOS-EU method and national operators generally have experimental data at their disposal to evaluate these new input parameters. This is not the case for tram networks, for which very few measurements exist, notably concerning the wheel and rail roughness or the track transfer function. In 2018, Acoucité and IFSTTAR performed an acoustic test campaign on a French tram network in order to propose tram input data from pass-by measurements corresponding to various sites and vehicles. In this paper, the results concerning the direct measurements of wheel/rail roughness and track decay rates (a key parameter for the assessment of the track transfer function) are presented and discussed. The main differences with data corresponding to conventional railways are highlighted.

INTRODUCTION

The European Directive 2002/49/EC [1] dated 25 June 2002 makes it compulsory for Member States to create noise maps in order to assess the exposure to environmental noise. These maps are made available to the public and allow the implementation of action plans to reduce noise and to estimate the impact of new infrastructures on the noise environment. They take into account noise emissions related to transport and industry. Their implementation is mandatory for urban areas with more than 100000 inhabitants and for major roads, railways and airports. This directive specifies common noise indicators for determining exposure to noise. Pending the adoption of a common assessment method, Member States were allowed to use their national method. For example, in France, the NMPB2008 prediction method has been used [START_REF]NF S31-133: Acoustique -Bruit dans l'environnement -Calcul des niveaux sonores[END_REF]. Recently, the common method, called CNOSSOS-EU for "Common Noise Assessment Methods in Europe" [3] has been published in the Official Journal of the European Union on 19 May 2015 to harmonise the production of noise maps among all EU countries. The first noise maps based on this method are expected in 2019.

Concerning the calculation of the propagation of noise in the environment, the changes made by the new CNOSSOS method compared to the French method are not fundamental. This is not the case for the calculation of noise emission terms, particularly those corresponding to rail transport. There are indeed two major changes. On the one hand, the different sources of railway pass-by noise (rolling noise, traction noise and aerodynamic noise) must be distinguished: their respective acoustic powers must be specified in the model. Furthermore, the rolling noise term must be estimated from the specific contributions of the vehicle and the track, themselves calculated from wheel/rail roughness and transfer functions characterising the track and the vehicle "vibro-acoustic efficiency" (see Figure 1). The method gives tabulated values in appendix, corresponding to conventional railway vehicles or tracks. Moreover, major national operators generally have experimental data or advanced models at their disposal to evaluate these new input parameters.

Figure 1: CNOSSOS rolling noise model for rail-bound vehicles (inputs in green, outputs in blue)

This is not the case for tram networks, for which very few measurements are available, notably concerning the wheel and rail roughness or the transfer functions. With regard to rail roughness, some recent measurements show significant differences with conventional rails [START_REF] Grassie | Rail irregularities, corrugation and acoustic roughness: characteristics, significance and effects of reprofiling[END_REF][START_REF] Chiacchiari | Measurement methods and analysis tools for rail irregularities: a case study for urban tram track[END_REF][START_REF] Chiacchiari | Rail roughness and rolling noise in tramways[END_REF]. Concerning the separation of noise sources and the contributions of track and vehicle to rolling noise, existing models also show that tramways have their own properties [START_REF] Wijnia | Noise emission from trams[END_REF][START_REF] Mandula | Prediction of noise from trams[END_REF][START_REF] Pallas | Characterisation of tram noise emission and contribution of the noise sources[END_REF][START_REF] Panulinová | Input Data for Tram Noise Analysis[END_REF]. There are several reasons for these differences. The most important are that the sound radiation from embedded tram tracks is significantly different from conventional tracks [START_REF] Van Lier | The vibro-acoustic modelling of slab track with embedded rails[END_REF][START_REF] Nilsson | A waveguide finite element and boundary element approach to calculating the sound radiated by railway and tram rails[END_REF][START_REF] Zhao | Measuring, modelling and optimising an embedded rail track[END_REF], the vehicle wheels are smaller and the wheel loads are lower [START_REF] Chiacchiari | Rail roughness and rolling noise in tramways[END_REF]. Consequently, for tram rolling noise modelling, it is clear that the transfer functions defined for conventional railways cannot be used.

In order to propose tram input data, Acoucité and IFSTTAR performed a test campaign on a French tram network. In addition to classic pass-by measurements carried out on various sites and vehicles at different heights, specific measurements of wheel and rail roughness as well as track decay rates were performed. The track decay rate is indeed a key parameter for the assessment of the track transfer function. In this paper, the results concerning these additional measurements are presented and discussed. The main differences with data corresponding to conventional railways are highlighted.

DESCRIPTION OF TEST TRACKS AND VEHICLES

Measurements were performed on four sites with different track types and surfacing. Two tracks are equipped with Vignole rail laying on monobloc concrete sleepers and ballast (C and D). One of these two tracks is characterised by the addition of a grassy coating above the ballast layer, outcropping the rail head (C). The other two tracks have grooved rails laying on bi-block sleepers, embedded in a concrete slab (A and B). On one of these two tracks, a grassy coating is also added (A). This last track section is characterised by a slight curve, unlike the three others which are located on straight lines. Table 1 summarises the characteristics of these track sections. Photographs in Figure 2 show the different rail types and surfacing. Three types of vehicles regularly run on the network. Two of them are very similar and differ only in the number of units (5 or 7) and bogies (3 or 4 respectively). Both are equipped with disc-braked resilient wheels of diameter 59 cm (new). The third type of vehicle is composed of three units, resting on three bogies in all. It is also equipped with disc-braked resilient wheels but with a diameter of 72 cm (new). Wheel roughness was measured only on three vehicles of the first category but with various mileage since the last reprofiling.

RAIL AND WHEEL ROUGHNESS MEASUREMENTS

Rail roughness

The procedure used for measuring the rail acoustic roughness was in accordance with the standard EN 15610-2009 [START_REF]EN 15610:2009 -Railway applications -Noise emission -Rail roughness measurement related to rolling noise generation[END_REF]. The thoroughly validated CAT equipment (for "Corrugation Analysis Trolley") developed by RailMeasurement was used [15]. An accelerometer fixed on the trolley is in contact with the rail. An operator pushes the trolley along the test section. Only one rail is measured at a time, at a speed of approximately 1 m/s and with a sampling distance of 1 mm. The trolley can be configured on a Vignole or grooved rail. The roughness estimation is carried out by post-processing the measured raw vertical profile (after integration of the acceleration signal) according to the standard: removal of localised defects or narrow peaks/spikes, curvature procedure and spectral analysis. Roughness was measured on both rails of each track.

On each rail, the effective width of the running band on the railhead was identified by a visual inspection. It turned out to be rather wide (> 2 cm) and several measurements were made for different lateral positions of the sensor on the rail: 25 and 35 mm for tracks A and D, 25 mm, 30 and 35 mm for tracks B and C (distances from the interior edge of the railhead, see Figure 3). Results corresponding to each track section are given in Figure 4: roughness spectra measured on the same rail for various lateral positions, mean roughness for each rail and global mean roughness for both rails (Throughout the paper, roughness means are quadratic averages of individual roughnesses). Default data given in the appendix of the CNOSSOS method for conventional rails are also plotted for comparison: the limit roughness curve prescribed in the standard ISO 3095:2013 [16] for the definition of reference tracks and an average spectrum corresponding to the national Dutch network. The roughness spectra measured on the same rail are very similar with differences generally less than 1 dB per third octave. The differences between the two rails of the same track are greater but often remain below 3 dB except for track B which has significantly higher levels on the left track. On this rail, we note in particular a zone of severe corrugation in the spectrum at wavelengths between 4 and 8 cm. This is probably due to the fact that the track section corresponds to the entrance of a curve. The resulting lateral friction phenomena can indeed lead to wheel/rail wear. The most important point is that the measured roughness levels are much higher than the levels proposed in the CNOSSOS method for conventional rails (sometimes by more than 10 to 15 dB), except for track D whose average levels are closer to those of the Dutch network (2 to 3 dB difference on average).

Wheel roughness

Wheel roughness measurements were carried out in the workshop on a free wheel, with an axle raised a few millimetres above the rail. A magnetic-based measuring system (TriTops device developed by RailMeasurement) was installed on the rail near the wheel to be measured (see Figure 5). Three displacement sensors and an incremental encoder wheel were in contact with the wheel. The three sensors were positioned on the contact area of the wheel tread. The measurement was achieved by turning the axle by hand over a few turns (5 or 6 in this case). Results corresponding to a wheel of each vehicle are given in Figure 6 : roughness spectra measured on the same wheel for various lateral positions (the three displacements sensors of the measuring device) and mean roughness for each vehicle. Default data given in the appendix of the CNOSSOS method for a conventional disc-braked wheel are also plotted for comparison. A significant dispersion is observed with regard to the lateral position on the wheel (i.e. between the three sensors of the system) with differences of up to 3-4 dB per third. The differences between the roughness measured on the different vehicles are also significant, but no correlation could be established between the roughness spectra and the mileage since the last reprofiling. Finally, the comparison with the roughness spectrum proposed in the CNOSSOS method for a disc-braked wheel shows that tram wheels generally have higher roughness levels, particularly at the shortest wavelengths (< 31.5 mm) for which differences of up to 10 dB are observed in some third octaves.

Influence of the track and the vehicle on the combined roughness

In order to evaluate the contributions of the wheels and the rail to the total combined roughness, mean rail roughness spectra corresponding to each track are plotted in Figure 7 and compared with the wheel roughness spectrum averaged over the three vehicles. In addition to the graduation of the abscissa in terms of wavelength, a frequency scale has been added at the top of the figure. The frequency (𝑓) -wavelength (𝜆) correspondence is performed by the relationship 𝑓 = 𝑉/𝜆, for a speed of 45 km/h which is representative of the vehicle speed on the test track sections. It can be seen that all over the first part of the spectrum (above 25 mm wavelength or below about 500 Hz at 45 km/h) the contribution of the track to the combined roughness is predominant. In this range, the track will thus have a significant influence (up to 7-8 dB) on pass-by noise levels via the rail roughness. In the second part of the spectrum (below 25 mm wavelength or above about 500 Hz at 45 km/h), wheel and rail roughness have the same order of magnitude. Thus, both the track and the vehicle contribute to the combined roughness. However, the differences between the roughness levels of the different tracks are less important in this range and all rail roughnesses will therefore play a similar role in the pass-by noise.

TRACK DECAY RATE MEASUREMENTS

The last part of the campaign concerns the characterisation of the dynamic behaviour of the track. Indeed, as indicated above, in order to validate and adjust the calculation of the track vibro-acoustic transfer functions, it is necessary to characterise the specificities of tram tracks with embedded rails which may have a very different behaviour from conventional railways. The track decay rate (TDR), which reflects the attenuation of waves along the rails from the excitation, is the key indicator to characterise this behaviour. The method for direct measurement of the TDR is defined in the standard EN 15461+A1:2011. The procedure was applied on track B (specific tramway track: grooved rail on sleepers embedded in a concrete slab) and track D (rather conventional track: Vignole rail on concrete sleepers and ballast). On track D, the vertical and lateral decay rates were measured, whereas on track B, only the vertical decay rate was measured. The measured decay rates are given in Figure 9 and compared with the limit vertical and lateral curves prescribed in the standard ISO 3095:2013 [16] for the definition of reference tracks. The TDR curves measured of track D display classic shapes. Vertically, three peaks are identified around 500, 1250 and 5000 Hz due respectively to the resonance of the rail on the pad, the periodicity of the sleepers (pinned-pinned frequency) and the deformation modes of the rail section (in particular the rail foot). Lateral peaks are also visible with significantly lower frequencies (125, 630 and 3150 Hz). Finally, we note that the two TDRs of track D remain higher than the standard gauge for most frequency bands. The vertical TDR measured on track B is completely different from that measured on track D. Three peaks can also be identified but with frequencies much lower than those of track D. In particular, a minimum of less than 2 dB/m is observed in the curve at a frequency of 630 Hz, which is quite unusual on conventional tracks. It should also be noted that at this frequency, the measured TDR is lower than the standard limit curve, which implies a possible high contribution of the rail to the pass -by noise emitted (to be qualified according to the rail radiation factor at this frequency).

CONCLUSIONS

In order to identify input parameters for CNOSSOS noise emission models specific to trams, measurements of acoustic roughness and vibration decay rates were performed on various tracks and vehicles of a tramway network. It appears that the characteristics measured are very different from those corresponding to conventional railways. In particular, wheel and rail roughness levels are higher in all wavelength bands, with differences that may exceed 10 dB. In the high-wavelength (or low-frequency) range, rail roughness levels are much higher than wheel roughness levels and the track has a significant influence (up to 7-8 dB) on the combined roughness. The comparison of measured decay rates also shows that tram-specific transfer functions must be proposed, particularly for the tracks with embedded rail. The identification of appropriate vibroacoustic transfer functions for trams based on these measurements and pass-by acoustic measurements is the next step of this project.

Figure 2 :

 2 Figure 2: Photos of the tracks

Figure 3 :

 3 Figure 3: Identification of the width of the running band on the railhead and measurement with the CAT

Figure 4 :

 4 Figure 4: Rail roughness spectra measured on test tracks

Figure 5 :

 5 Figure 5: Wheel roughness measurement system

Figure 6 :

 6 Figure 6 : Wheel roughness spectra measured on test vehicles

Figure 7 :

 7 Figure 7: Comparison of wheel and rail roughness spectra as a function of wavelength and frequency

Figure 8 :

 8 Figure 8: Accelerometer fixed on the embedded rail with first impact location marks for the measurement of the vertical decay rate according to EN 15461 (track B)

Figure 9 :

 9 Figure 9: Track Decay Rates (TDR) measured on test tracks D and B

Table 1 :

 1 Characteristics of test track sections

		Rail type Track support		Surfacing	Geometry
	A	Grooved	Bi-block concrete sleepers	Concrete	Slight curve
			+ concrete slab
	B	Grooved	Bi-block concrete sleepers	Grass	Straight line
			+ concrete slab
	C	Vignole	Monobloc	concrete	Grass	Straight line
			sleepers + ballast
	D	Vignole	Monobloc	concrete	(Ballast)	Straight line
			sleepers + ballast

olivier.chiello@ifsttar.fr

ACKNOWLEDGEMENTS

This work was supported by the LabEx CeLyA of Université of Lyon, operated by the French National Research Agency (ANR-10-LABX-0060/ANR-11-IDEX-0007). This support is greatly appreciated.

The authors are grateful to SYTRAL and Keolys for their support in the measurement campaign.


Anne-Marie Barthe-Delanoë

Sabine Carbonnel

Frederick Benaben

Hervé Pingaud

Frédérick Bénaben

Hervé

An Event-Driven Platform for Agility Management of Crisis Response

Keywords: Adaptation, Agility, Complex-Event Processing, Detection, Event-Driven Architecture, Event Cloud, Model-Driven Architecture, Service Oriented Architecture

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

An Event-Driven Platform for Agility Management of Crisis Response 1. INTRODUCTION

As stated by [START_REF] Devlin | Crisis management planning and execution[END_REF], a crisis situation can be political, military, economical, humanitarian, social, technological, environmental or sanitary. Regardless its nature, a crisis is an abnormal situation, which is the result of an instability impacting a subpart of the world (called ecosystem or system) with unaccept-able consequences [START_REF] Devlin | Crisis management planning and execution[END_REF][START_REF] Lagadec | La gestion des crises[END_REF]. Such a situation implies to deal with the crisis management through a dedicated set of stakeholders in charge of the crisis response.

According to [START_REF] Atlay | OR/MS research in disaster operations management[END_REF][START_REF] Beamon | Inventory modeling for complex emergencies in humanitarian relief operations[END_REF]) the crisis management lifecycle is classically composed of four main steps starting with (i) mitigation, followed by (ii) preparedness, succeeded by (iii) a response phase and finally (iv) recovery.

The efficiency of the response step is determined by the speed and the accuracy with which information can be managed and exchanged among the partners (i.e. organizations, people and devices involved into the collaboration). Considering the fact that an Information System (IS) is the visible part of an organization, our point is to tackle organizations' collaboration issue through ISs interoperability. Interoperability is defined by the European Network of excellence InterOp as "the ability of a system or a product to work with other systems or products without special effort from the customer or user" (Konstantas, Bourrières, Léonard & Boudjilida, 2005) (pp. v-vi). It is also defined by Pingaud (2009a) as "the ability of systems, natively independent, to interact in order to build harmonious and intentional collaborative behaviours without deeply modifying their individual structure or behaviour".

As a crisis situation is an unstable phenomenon (by nature or by effect of the crisis response), it may challenge the relevancy of the collaborative processes run among the ISs of the crisis cell partners.

Mainly, the problem statement is the following: how to ensure the agility of the crisis response and the use of various and heterogeneous data sources to feed the ISs of the collaboration? How to analyse all the gathered data and extract the relevant information for a given crisis situation at time t?

MISE APPROACH OVERVIEW

Considering these points, we aim at designing and producing a Mediation Information System (MIS) to support interoperability among partners and to keep the response workflows relevant to the crisis situation, through the Mediation Information System Engineering 2.0 (MISE 2.0) project. This part of this research work is presented in "MISE Design Time" and "MISE Run Time" sections. The first version of the MIS prototype (result of the MISE 1.0 project) was successfully used in the French funded project ISyCri (ISyCri stands for In-teroperability of Systems in Crisis situation), whose one objective was to design an IS for several partners who have to solve, or at least to reduce, a crisis into which they are involved.

Another point to deal with during the response phase is the evolutionary character of a crisis situation. Due to this fact, the system shall remain compliant with the possibly changing requirements of the situation. This implies to measure the efficiency of the response, to be able to take into account the changes of the crisis itself or in the crisis cell (i.e. the events happening in the studied ecosystem). In a few words, a continuous response to the crisis is needed.

Several research projects focused on the event-management as a mean to be more accurate about the situation at time t on the field of the crisis, but also to be more efficient to manage the events sent by the crisis'ecosystem. Some of these projects are the French funded project SocEDA, the European funded projects PLAY [START_REF] Truptil | Nuclear Crisis Use-Case Management in an Event-Driven Architecture[END_REF] and PRONTO [START_REF] Marterer | An architecture for distributed, event)driven systems to collect and analyze data in emergency operations and training exercises[END_REF]. Such platforms integrate an Event-Driven Architecture layer, that provide them the ability to retrieve, manage and even generate complex events in order to help the users to filter the events and detect any anomaly. But such event-management is quite limited by the fact that only known types of events can be managed by static business rules.We believe that the EDA layer is a real benefit that completes the architecture of existing SOA platform (like MISE 1.0 and MISE 2.0) but its implementation is not limited to the use of a single Complex Event Processing engine (which plays the role of event filter, event manager and event generator). While [START_REF] Yu | Coordination of Emergency Response Operations via the Event-Based Awareness Mechanism[END_REF] focus on the modeling of the collaborative activities and their dependencies and on the event impact on the states of the activities to solve this limitation, MISE 2.0 focuses on the detection of divergences between the whole crisis model and the effects of the events on both the crisis situation and the crisis cell (the partners and their activities). Then we propose a tool to adapt the crisis response if needed (via a partial or complete redesign/a partial or complete re-execution of the response). This part of this research work is presented in the remainder of this article, in the "MISE Agility" section.

The MISE 2.0 prototype, presented in this paper, is under construction and aims at solving some limitations and assumptions of the MISE 1.0 prototype. It will be tested on a realistic use-case (a nuclear plant accident).

MISE DESIGN TIME

Like MISE 1.0 design approach [START_REF] Rajsiri | Knowledge-based system for collaborative process specification. Integration and Information in Networked Enterprises[END_REF], MISE 2.0 design approach is based on a Model-DrivenApproach (MDA) [START_REF] Miller | MDA Guide Version 1.0[END_REF] through an automated model transformation including (i) the collaborative characterization, (ii) the design of the collaborative process cartography, and (iii) the execution step.

The Collaborative Situation Characterization

The goal of this first step is to gather knowledge about the collaboration. For this purpose, [START_REF] Mu | A Model-Driven BPM Approach for SOA Mediation Information System Design in a Collaborative Context[END_REF] have defined a metamodel that integrates the concepts of a collaborative situation and that allows to characterize a specific collaborative situation (like a crisis situation). The concepts covered by the metamodel are subdivided into three categories:

• The context of the collaborative situation:

this is the environment of the subpart of the world concerned by the collaborative situation. In the case of a crisis situation, it allows to define the threats, the risks, the goods, the people, etc. • The partners of collaborative situation: this part of the knowledge focuses on the public side of the partners, i.e. the information and the skills they want to share into the context of the considered collaborative situation. • The goals of collaborative situation: a collaborative situation exists only to meet a need. Thereby, the goals of the collaborative situation form a critical and essential knowledge to build the systems that allow the effective deployment of the collaborative situation.

In MISE 2.0, the metamodel is structured in layers, around a central core that represents the general concepts of the collaborative situation (Mace Ramete, Lamothe, Lauras, & Bénaben, 2012). The central core groups all the concepts related to the collaborative situation (environment, partners, goals). This core is shared by any kind of collaborative situation between organizations. However, the layers covering the core are domain specific, and even subdomain specific. They are used to define the specific concepts, which inherit from the general concepts of the core. In MISE 2.0, several layers were defined, including one dedicated to the crisis situation (see Figure 1).

The obtained collaboration metamodel is the container of the knowledge relating to the collaborative. The user will be in charge of designing instances that represent the components of the considered situation, with respect to the metamodel. A software editor will help the user to characterize the considered collaborative situation (such as the response to a nuclear plant crisis situation) and obtain a model of the collaborative situation [START_REF] Rajsiri | Knowledge-based system for collaborative process specification. Integration and Information in Networked Enterprises[END_REF].

The Design of the Collaborative Process Cartography

This second step aims at using the gathered knowledge about the targeted collaborative situation, in order to build a dynamic collective behaviour that meets the modelled context. The semantic gap between the characterization of the needs and requirements (in other words, the targeted crisis response) and the solutions (the business dynamic that meets the defined goals) has to be filled.

The addition of the behaviour concepts to the metamodel (as presented in [START_REF] Mu | A Model-Driven BPM Approach for SOA Mediation Information System Design in a Collaborative Context[END_REF]) provides a direct link between the model of crisis situation characterization and the collaborative process metamodel. Through a model transformation, a process cartography can be deduced (organized according to the three abstraction levels: business, logic, technological).

In addition to this deduction, a n-to-m semantic reconciliation (as shown in Figure 2), explained in (Bénaben, Boissel-Dallier, Pingaud & Lorré, 2012) is made between the deduced business activities -at the abstract level-and the technical services offered by the partners -at the concrete level-. There is also a data transformation activity: the data's format from the response of the service A is not necessary compliant with the expected format of incoming data for service B. This transformation is performed by services based on semantic matchmaking engine, as detailed in [START_REF] Bénaben | Semantic reconciliation in interoperability management through Model-Driven Approach[END_REF].

At the end of this step, a set of collaborative technical processes is obtained (Bénaben, Boissel-Dallier, Pingaud & Lorré, 2012).

MISE RUNTIME

Finally, the deduced collaborative technical processes are automatically implemented as executable workflows (this is the implementation layer).

In the remainder of this article, we will present the Figure 3, Figure 4 and Figure 5, which summarize the overall MIS's architecture of the MISE 2.0 prototype, containing three main parts (the crisis situation, the crisis cell and the event processing).

The main hypothesis of this article concerns the partners' IS that are supposed to follow the

Figure 2. Principles of N-to-M semantic reconciliation

same conceptual logical architectural philosophy: the Service Oriented Architecture (SOA) [START_REF] Vernadat | Interoperable enterprise systems: Principles, concepts, and methods[END_REF]. If it is not the case, we consider partners'IS may be SOAcompliant with the help of interfaces between non-SOA applications and the MIS (whose deployment is based on SOA principles). The MIS will run on a server, more precisely on an Enterprise Service Bus (ESB), which is Petals ESB (developed by the French software editor Petals Link/Linagora) and all the tools used to design and then run the workflows are services hosted on this ESB (it is used for both design time and runtime).

On Figure 3 We can note that the Design Time workflows (used to deduce the response workflows and the MIS implementation) and the Runtime workflows (i.e. the response workflows) are recorded in a database (5) that allows feedback about the crisis characterization and the deduced and run workflows.

MISE AGILITY

By nature and by the effects of the collaborative processes to solve or reduce the crisis, a crisis situation is an unstable and evolutionary phenomenon. So, we can consider that as the crisis situation evolves, the crisis response (i.e. the run collaborative workflows) may be not relevant after a while.

In the literature, the notion of agility was widely discussed. [START_REF] Badot | Théorie de l'entreprise agile[END_REF] defined it as the reconfiguration of the system to satisfy a need for adaptation. For other authors like [START_REF] Kidd | Agile Manufacturing: Forging New Frontiers[END_REF], [START_REF] Lindberg | Strategic Manufacturing Management: A Proactive Approach[END_REF] and [START_REF] Sharifi | A methodology for achieving agility in manufacturing organisations:An introduction[END_REF], agility is a need for flexibility, responsiveness or adaptability. In the context of logistics, flexibility is seen as "the ability to meet shor-term changes" [START_REF] Sheffi | Demand Variability and Supply Chain Flexibility[END_REF] and it is differentiated from adaptation over time in response to a change [START_REF] Mccullen | The F1 Supply Chain: Adapting The Car To The Circuit-The Supply Chain To The Market[END_REF]. Considering these notions of responsiveness (speed of adaptation), adaptation (wideness of this adaptation and detection (moment of the adaptation), we propose the following definition of agility: agility is the ability of a subject to lead as quickly as possible, on the one hand, to the detection of its mismatch to a given context, on the other hand, to the setting up of the required adaptation.

In our context, solving the collaborative workflows'agility issue means we need to detect the moment when a workflow is not relevant anymore regarding to the collaborative goals and the current context of the collaborative situation (detection), and what needs to be done to deal with this issue (adaptation), as fast as possible (responsiveness).

Based on Pingaud (2009b)'s research work, three kinds of evolutions of collaborative situations can be extracted:

• The evolution of the crisis situation itself:

the perceived characteristics of the crisis, in particular the issues to solve, are not the same at the beginning of the crisis and need a new response to the crisis. • The evolution of the crisis cell: the management of the response to the crisis situation may evolve due to an evolution of the structure of the crisis cell (e.g. arrival or leaving of stakeholders, lack of resources). • The evolution of the response to the crisis: the management of the response to the crisis situation may evolve due to (i) a dysfunction of the execution of a service (leading to the interruption of the workflow of the response), or (ii) due to a partial initial definition of the process of the response.

As an example of a dysfunction, we can cite the case of the nuclear plant of Fukushima Daiichi, where the poured water had not reached the expected goal (i.e. to cool the reactors).

Thus any changes, any evolution, any information that could challenged collaborative processes' accuracy and relevancy have to be managed. According to [START_REF] Chandy | Event Processing, Designing IT Systems for Agile Companies[END_REF][START_REF] Etzion | Event Processing in Action[END_REF][START_REF] Luckham | Event Processing Glossary -Version 1.1[END_REF] these elements that happened and that embedded data can be considered (and managed) as events. These events are produced by (i) the people on the crisis field (e.g. policemen, firemen, EMS team) and by devices (e.g. radiation sensor, weather measurement station) (point 6 on Figure 4), (ii) the services used by the response workflows (7). These events are collected in an event cloud and/or sent to the CEP through an event stream.

The use of Event-Driven Architecture (EDA) principles [START_REF] Luckham | Event Processing Glossary -Version 1.1[END_REF][START_REF] Michelson | Event-Driven Architecture Overview: Event-Driven SOA Is Just Part of the EDA Story[END_REF][START_REF] Maréchaux | Combining Service-Oriented Architecture and Event-Driven Architecture using an Enterprise Service Bus[END_REF][START_REF] Josuttis | SOA in Practice: the Art of Distributed System Design[END_REF] to complete the SOA principles -on which the MIS is based-allow us to take the previously described events into account. A Complex Event Processing (CEP) engine is used to consume and manage these events (point 8 on Figure 4).

The CEP engine not only allows the choreography of the collaborative processes by event management (to manage exchange between the processes and to monitor the workflows'execution) [START_REF] Peltz | Web Services Orchestration and Choreography[END_REF][START_REF] Barros | A critical overview of theWeb Services Choreography Description Language (WS-CDL)[END_REF] but also filters and applies business rules to detect relevant events or combination of events. For example, two events (a wind direction measure and the caesium 137 rate in ambiant air), which are not considered as risks when seen separately, may have a different meaning if they are considered together. In this example, the CEP can send an event to inform the MIS of a change in the crisis characterization (9).

The CEP generates events, which are received on the ESB through the event proxy. Depending on their content, they will be consumed by the partner's services or by theAgility service. In order to be agile, as agility is considered as the combination of event detection and adaptation, the MIS have to detect the events that have an impact on the crisis response and to define an adaptation regarding these events.

The Agility service's role is (i) to update both expected model (the planned and expected situation model at time t) (point 10 on Figure 5) and field model (the « what happened actually on the field» situation model at time t) (11) through the received events (respectively through the events received from the monitoring of the crisis response, and the events coming from the field).

Then the Agility service has (ii) to measure and identify the differences between these two situation models ( 12) and (iii) to suggest a relevant adaptation of the MIS through a complete or partial execution of the Design Time workflows.

Depending on the identified differences, a part of the response workflows may be run once again (e.g. to solve an issue concerning a technical execution that has failed) (13), or modified (e.g. another partner's service may be called to replace a service that is down) ( 14) or even completely redesigned (because the initial characterization of the crisis situation is incomplete or the crisis situation has considerably evolved) (15).

The adapted workflows are not only executed ( 16), they are also stored in order to capitalize knowledge (17). In a few words, we can say that the use of CEP allows refining the vision of the crisis situation (i.e. the impacted ecosystem and the crisis cell) while the Agility service allows refining the crisis response.

MISE 2.0 IMPLEMENTATION: CRISIS USE-CASE

The Crisis Situation

As the MIS' main objective is to be the support of collaborative situation, the focus is set on the response step: the MIS helps the stakeholders in charge of the crisis situation to deduce, via the preparedness step results, and to give the crisis a response.

The use-case is a Chemical Biological Radiological and Nuclear (CBRN) use-case: a large quantity of radioactive substance is accidentally released in the atmosphere, due to a critical accident in a French nuclear plant. To resolve this crisis, a lot of heterogeneous actors may be involved. As many stakeholders are involved in the crisis management process, contact was made with IRSN (IRSN, 2007;IRSN, 2011) and ASN (ASN, 2009), France's public service expert in nuclear and radiation risks: they have provided information about the real emergency plans and processes and the best practices.

The services provided by these actors are also diverse and varied, ranging from psychological assistance to traffic duty. This heterogeneity is probably the main cause of the difficulty to manage such a crisis situation. But there are many other difficulties to cope with.

For instance, there are a lot of critical dependencies between the actions of these heterogeneous actors. A decision to evacuate will depend on the actual level of radioactivity measured, but also on weather forecasts and assessments of the situation in the nuclear plant.

MISE Platform Integration in the Existing System

The MISE platform is integrated with the existing system as follows (Figure 6). Numerous and various sensors are used to monitor the radiation levels, the temperature, the wind direction, etc. in a nuclear plant.

These sensors are able to emit their measures as events, i.e. they send their data through a network and the people and devices interested in these data'topics gather them. In a few words, this is the publish/subscribe mechanism.

The PLAY platform (presented previously in section "MISE Overview") is able to gather events emitted by various and heterogeneous data sources, like sensors. The PLAY platform has the role of an event marketplace: it collects events and proposes them to third part systems, like the MISE platform. The MISE platform gathers events found into the PLAY event marketplace. Based on these gathered events, the MISE platform is able to analyse the data coming from the field of the crisis situation (the nuclear plant in our case study).

An interoperability issue can be underlined: how these connections between heterogeneous systems (sensors, PLAY platform, MISE platform) are possible?

This point is solved through use of two majors standards (in an SOA context): Sensor Observation Service (SOS) (OGC, 2012) and WS-Notification (OASIS, 2007a;OASIS, 2007b;OASIS, 2007c). The SOS standard defines a web service interface to query sensor data and embedded a SOAP binding. The WS-Notification standard allows to define the mechanisms to exchange events through a mechanism of subscription to topics of inter-Figure 6. Integration of MISE within the existing system est. WS-Notification will be detailed in the remainder of this article.

Event Types (In a Crisis Situation Context)

The event type is the structure of the instantiations, represented as a collection of event attributes.As recommended by [START_REF] Etzion | Event Processing in Action[END_REF][START_REF] Luckham | Event Processing Glossary -Version 1.1[END_REF], an event type should specify certain predefined data as:

• A unique event identifier used to reference the event • The type of the event • The timestamp of the event's creation • The source of creation for the event Eight event types covering the whole kinds of events that can happen in the context of crisis situation management were listed: Measure, Alert, Demand, Offer, Resources_Status, Ac-tivity_Status, Instruction and Report. They are detailed in the UML class diagram in Figure 7.

These types are classified into four macro types of events (Situation, Resources, Activity and Consequence), all depending of one common ancestor called Event and containing two attributes (TimeStamp and UniqueID). Each event type owns its own attributes and inherits a part of them from its ancestors.

At the implementation level, [START_REF] Luckham | Event Processing Glossary -Version 1.1[END_REF] recommend defining the event types through one of the new computer languages like XML Schema or Java. As the MIS is based on the SOA principles, it is natural to develop the defined crisis response processes in Business Process Execution Language (BPEL) [START_REF] Oasis | Web Services Business Process Execution Language OASIS Standard Version 2[END_REF] workflows, run by an orchestration engine. It leads to use the Web Services-Notification (WS-N) standard (OASIS, 2007a;OASIS, 2007b;OASIS, 2007c), which is based on XML formalism, to describe the event occurrences sent by/to the MIS' workflows. So the use of XML Schema to describe the eight event types is completely convenient with the previous architecture choices.

Event Managing and Business Rules

A Complex Event Processing (CEP) engine is used to consume and manage the events. Esper, an open-source CEPdeveloped by theAmerican software editor EsperTech has been chosen as it allows to manage events in an XML format such as WS-N format.

Events come from both the crisis response process itself and the whole devices, sensors, softwares, partners' information systems implied into the crisis situation. Through a software connector we have developed (in Java language), Esper engine can subscribe to the services that send WS-N formatted events, and so receives this event stream. Esper filters it and applies the business rules that are defined (i.e. event processing rules, containing event patterns) on the input event stream (these rules are manually implemented before running the engine). When an event process rule is triggered by input events, an output event is generated. It can be noted that the event types of studied event occurrences are parameterized into Esper according to the structure that is defined in the previous subsection "Event types (in a crisis situation context)".And the events generated by Esper (as a consequence of event process rules triggering) follow exactly the same structure.

This section aims at presenting a short example of such a rule extracted from the nuclear crisis use case. The aim of this rule is to gather the events from the Measure event type, and, according their values, generates an event from the Alert event type, which will be sent by Esper (and gathered by the concerned subscribers). This rule is human produced (after preparedness meetings or extracted from established emergency plans for instance), and it is written in natural language: Then this rule is parameterized into Esper, using the Esper Query Language (EQL), as shown below: insert into alerts select 'Radiation increasing over security level in combination with a N-N-W wind' as alertDescription, 'high' as alertGravity, radiation.measureLocation as alertLocalisation, radiation. measureSEID as alertSEID, radiation.measureName as com-ponentName from measureEvent(measureUnit='wind direction' and measureValue=8 and measureSEID='METEOF-TLS-NORD').win:time(20 seconds) as wind, measureEvent(measureUnit='Nano sievert per hour' and measureValue > 110000 and measureSEID='MFRT-TLS-BLA').win:time(20 seconds) as radiation Each pattern triggering inserts an event (with the properties specified into the select clause) into the "alerts" event stream. Through a software connector, Esper is able to send this output event stream as WS-N formatted event. This output event instantiates one of the eight event types previously defined (in the presented example, it instantiates the Alert event type). This approach allows consumer services (like the Agility service or any partner service or any mediation service) to subscribe to the events generated by the CEP.

Among all events received by the MIS (including those generated by the CEP), some events are used to orchestrate activities inside a specific process, some of them are used to choreography the processes, some of them are used to update both field model and expected model. And some of them may assume two or three of these roles. Ideally, any received event will be used to update the models and eventually has a role into the orchestration/choreography function of the MIS. In the previous example, the generated Alert event will be used by the Agility service to update the field model, with the creation of a new risk in the crisis situation model.

To illustrate deeper the concept of such event roles, and their impact on the update of the field model and the expected model in the use case, the following example is presented: the temperature of the reactor of the nuclear plant is significantly increasing. The defined response in this case is to cool the reactor by spreading water on it. In the crisis response workflow in charge of this part, the concerned activity is "cool the reactor with two tanks of water". Once this activity is done,Agility service receives two events (at minima):

• One concerning the status of the activity (the expected model is updated according this event),

• One concerning the real result on the field, provided by a sensor (the field model is updated according this event).

To illustrate the proposal, only the most interesting cases of event combinatory are detailed in the following.

• First Case: the status of the activity informs the MIS that the activity is done with success (no technical failure, the two tanks of water were correctly spread, so the reactor is considered as cooled and the temperature as decreasing), and the result on the field of the activity informs the MIS that the temperature is decreasing. These two events lead to the same conclusion: the temperature of the reactor is decreasing.

The executed response meets the current crisis situation. • Second Case: the status of the activity informs the MIS that the activity is done with success, and the result on the field of the activity (coming from a sensor) informs that the temperature is absolutely not decreasing, and worse, is still increasing. • Third Case: the status of the activity informs the MIS that the activity execution fails, and the result on the field of the activity informs the MIS that the temperature is absolutely not decreasing, and worse, is still increasing. • Fourth Case: the status of the activity informs the MIS that the activity execution is 50% completed (only one water tank was available), and the result on the field of the activity informs the MIS that the temperature is decreasing.

We can see with these cases that after updating the two models with the received events, the role of the Agility service is to detect the divergence (here, the fact that actually, despite the execution of cooling activity, nothing changes), and also the origin of the divergence (by comparing the models as two sets of points and not in a point-to-point way). The origin may be:

• At the level of the activity itself: was there actually a failure during the execution of the activity? Were the resources enough to reach the objective? (In our example: third case) • At the level of the activity: is this activity available? Is the activity able to meet our needs? (In our example: second case) • At the level of the crisis characterization:

has the crisis situation evolved so much that the response is not relevant to the current situation? (In our example: second and third case)

The fourth case also shows us that a divergence between the models may not lead to a negative fact. We keep in mind that this example is really simple and only helps to understand the necessity to detect the divergence but also its (multiple) causes in order to decide the strategy concerning the adaptation: (i) re-execute the activity, (ii) modify the response implementation (change a service), (iii) redesign the whole response (from the moment where the response became not relevant). This choice is not trivial, as each option has a cost considering the elapsed time (and so the evolution of the crisis that can lead to an over crisis situation) but also a cost considering the resources (and so the economics). Typically, the fourth case shows that too many resources where asked, and even a lack of 50% of water, the reactor was cooled as expected. We think that the Agility service will not only help to decide what and when we have to modify the crisis response, but also helps to study the crisis response in terms of cost, which is very interesting for the feedback, after the crisis resolution (and so helps to define best possible responses to a crisis situation).

PERSPECTIVES

In such a collaborative environment and in such a crisis situation, the quality of the data and its protection is a critical issue. It is obvious that we must not allow a right of access to any data in any conditions to anybody. During the semantic reconciliation (when the partners' services are chosen to create the executable workflows) and during the event subscriptions, the MISE 2.0 platform will provide governance tools for both services and event sources. Events can only be used if they are trustable: for the moment, several approaches can be considered, like a social filter (using trust criteria on event sources and the relations between the event sources) or a repository of event sources, that gives to the users several criteria to choose the most relevant event sources.

CONCLUSION

People, devices, softwares, sensors, internal and external services of the MIS: if all these information channels can be turn into services, or plugged to human-to-machine service interfaces, they can be connected to the MIS's ESB. Then this ESB executes the collaborative processes between services and service interfaces. The CEP subscribes to the events produced by the collaborative processes (as event streams or event cloud), through the event proxy (hosted on the ESB).

We can work on these event streams/event cloud to follow the execution of the services called by the workflows (orchestration), to follow the event exchanges between the processes (choreography) and to allow the MIS monitoring. The low coupling provided by the combination of SOA and EDA in the MIS architecture highly reduces the integration costs and facilitates the connection between heterogeneous services provided by heterogeneous partners. Briefly, the aim of this article was to show that the MIS allows the coupling between systems that cannot ignore each other and that cannot be connected due to the inability to cover all possible connections (explosive combinatory) and their relevance at a given time.

Another perspective concerns the crisis situation modeling. For the moment, theAgility service is only seen as a mean to detect divergences about an established crisis situation and to help to adapt the crisis response to the new situation. But, it can be also used as a detector of anomalies in a nominal system: incoming events would be used to update the model of the current situation and this updated model may be compared with a reference model of the situation (i.e. the model of the situation in a nominal state). According to the detected divergences (origin, nature, size) a crisis situation may be identified automatically.

Anne-Marie Barthe-Delanoë is a postdoctoral research fellow in the Interoperability of Organizations (IO) team in the laboratory of Industrial Engineering of the Mines Albi-Carmaux, since the end of 2013 when she received her PhD in Industrial Engineering and IT. She also graduated in 2007 as an engineer and got a M.S. in Automated, IT and Decision-making Systems from the Mines Albi-Carmaux. Her research works deal with the interoperability of organizations and the agility of collaborative processes, especially in a crisis situation. Prior to joining the IO team, she served first as a research engineer at EBM WebSourcing (a French SOA software editor), then as a consultant at Cameleon Software (a French product configurator software editor).

Sabine Carbonnel was a research engineer in the laboratory of Industrial Engineering of the Mines Albi-Carmaux. She graduated as a doctor in IT from INSA Rennes in 2005: she worked on « integration and modellng of linguistic knowledge for online handwriting recognition ». Her research interests focused on artificial intelligence. After six years serving as a research engineer in the domain of industrial engineering, she is now an engineer in the Information System Department of the French Ministry of Education.

Frédérick Bénaben is an Assistant-Professor in the IO team at the laboratory of Industrial Engineering of the Mines Albi-Carmaux, since the end of 2003. After a master's degree in computer science (1998), he worked on a PhD on "model checking for properties verification and validation on heterogeneous optronic systems" with THALES Optronics and University of Montpellier (2001). After a post-doc period at the Ecole des Mines Alès, he joined the laboratory of Industrial Engineering of the Mines Albi-Carmaux in order to work on Information Systems and interoperability of enterprises. Member of several research associations (Pole GSO of InterOp V-Lab, CNRS GDR-MACS) he works particularly on mediation information system engineering to support inter-organizational interoperability. Involved in several national and European projects, he is aiming at joining Business Process Management approaches and model-driven design to achieve interoperability of organizations. Hervé Pingaud is graduated as engineer in 1983 and as doctor in 1988 from the Institut National Polytechnique de Toulouse (INPT) with a PhD on process dynamic simulation. Then he worked as a full time researcher on process simulation and control engineering in INPT. From 1992until 1999, he had an increasing interest for industrial engineering. He acted as a project leader in developing new diploma in industrial engineering both in INPT, and in Mines Albi-Carmaux that he joined for a new position of full time Professor in 1999. From 1999 until 2010, in the laboratory of Industrial Engineering of Mines Albi-Carmaux, he supervised PhD students in three main scientific areas: enterprise process modelling, process and risk management, and interoperability in information system design. Since 2010, he is the Director of Champollion University (Albi, France). He is a French representative of IFAC TC 5.3 "Enterprise Networking and Integration", and used to act as one of the CNRS group coordinator on this subject at a national level.

Figure 1 .

 1 Figure 1. The core and the crisis management layer of the metamodel. (adapted from (Mace Ramete, Lamothe, Lauras, & Bénaben, 2012))

Figure 3 .

 3 Figure 3. Global view of the MISE 2.0 platform

Figure 5 .

 5 Figure 5. The agility service of the MISE 2.0 platform

Figure 7 .

 7 Figure 7. The eight event types concerning crisis situations

ACKNOWLEDGMENT

This work has been partially funded by the French Research Agency (ANR) regarding the research project SocEDA(SOCial Event Driven Architecture) (GrantANR-10-SEGI-013). This project aims to provide dynamic and adaptive workflows to collaborative situations (like crisis situations) through EDA and CEP. The authors would like to thank the project partners for their advices and comments regarding this work.