Emilie Balland

Pierre-Etienne Moreau

Antoine Reilles

Rewriting Strategies in Java

In any language designed to express transformations, the notion of rewrite rule is a key feature. Its conciseness as well as its strong theoretical foundations are essential. The notion of strategy is complementary: this describes how rules are applied. In this paper, we show how a high-level strategy language can be implemented in a Java setting. We present the integration of the visitor combinator design pattern into Tom. This corresponds to an interpreter for strategy expressions. To be more efficient, we present a compilation method based on bytecode specialization. This low-level transformation is expressed in Tom itself, using rules and strategies.

Introduction

Rule based transformations are used in a wide range of applications including compiler construction, optimization, refactoring, software renovation as it is shown in [START_REF] Visser | A survey of rewriting strategies in program transformation systems[END_REF][START_REF] Lacey | Imperative program transformation by rewriting[END_REF]. Complex program transformations are achieved through a number of elementary modifications, defined by rewrite rules, whereas the way they are applied corresponds to the notion of strategy.

The main interest of using strategic rewriting systems is the conciseness, as well as the strong theoretical foundations of this paradigm. In practice, elementary program transformations appear explicitly in the program as rules. The strategies defined separately allow the user to precisely control the applications of the transformations. The separation between rules and strategies helps to ensure properties such as correction or termination. In the context of optimizer construction, [START_REF] Visser | Building program optimizers with rewriting strategies[END_REF] demonstrates that standard strategies (i.e. innermost or top-down traversals) are not sufficient. Even if separating transformations and control provides safety, languages based on rewriting must offer modular and extensible strategy expressions to be really usable.

There already exist several environments, or meta-environments, well tailored to ease the development of such transformation systems. Among them, let us mention Obj, Maude, Asf+Sdf, Stratego, Elan, Hats or Txl for example. Since 2001, we have been developing the Tom system [START_REF] Moreau | A Pattern Matching Compiler for Multiple Target Languages[END_REF][START_REF] Balland | Tom: Piggybacking rewriting on java[END_REF], whose main originality is to be built on top of an existing language: Java. The main advantage of this approach is that any Java program is a Tom program. Therefore, the system automatically provides a large library and support for builtins such as int, float, and String, I/O, system calls, etc. As a counter part, the design of the language is more constrained since the introduced constructs should be compatible with the Java model and syntax. In this paper, we give in Section 2 an outline of the Tom language. In Section 3, we show how strategic programming, pioneered by Obj, Elan, Maude, and Stratego can be lifted into the Java programming environment. In Section 4, we show how it can be applied to implement a compiler for the strategy language of Tom using a rule based library designed to perform Java bytecode transformations.

2 Rule based programming in Java

First order term

The notion of term is essential when considering rewrite rules: this is the main datastructure. Gom [START_REF] Reilles | Canonical abstract syntax trees[END_REF] is a language and a tool for describing typed tree structures. Given an algebraic signature, it generates an implementation efficient both in time and space. The implementation offers maximal sharing which is similar to the ATerm library [START_REF] Van Den Brand | Efficient annotated terms[END_REF]. As in ApiGen [START_REF] Van Den Brand | A generator of efficient strongly typed abstract syntax trees in Java[END_REF], the generated code ensures that only well typed terms can be built. As illustrated below, Gom offers modular importations and supports primitive types of Java: A main contribution of Gom is to provide a hook mechanism to define canonical forms that have to be preserved. In other words, to each algebraic operator, a construction function can be associated. This function ensures by construction that terms are in normal form, and thus that invariants are preserved. In the following example, we define a hook attached to Plus, which ensures that the addition with a neutral element is automatically simplified:

Plus:make(e1,e2) { %match(e1,e2) { Cst(0),x -> { return 'x; } x,Cst(0) -> { return 'x; } } }

Rule based programming

Tom is a language extension which adds pattern matching primitives to existing imperative languages. Pattern matching is directly related to the structure of objects and therefore is a very natural programming language feature, commonly found in functional languages. This is particularly well-suited when describing various transformations of structured entities like for example trees/terms, hierarchical objects and XML documents. The main originality of the Tom system is its language and data-structure independence [START_REF] Moreau | A Pattern Matching Compiler for Multiple Target Languages[END_REF]. From an implementation point of view, it is a compiler which accepts different host languages and whose compilation process consists in translating the matching constructs into the underlying native language. Since Gom generates Java implementations of terms, in the following, we consider Java as the host language.

On the practical side, Tom provides three main features: a "%match" construct to match objects, a "'" construct to build objects, and a mapping definition formalism used to connect the algebraic level to the implementation level, called formal anchor. In this paper we only consider implementations of data-structures generated by Gom, but note that the notion of formal anchor allows to match against any kind of data-structure.

The %match construct adds pattern matching facilities similar to functional languages. The action part is written in Java, providing flexibility. The "'" construct builds a term and can be used anywhere a Java expression is allowed. For example, the expression 'Cst(5) builds the corresponding term.

Note that Java expressions can be mixed with Tom expressions and that invariants are systematically ensured. Therefore, 'Plus(Cst(2+3),Cst(2-2)) will be evaluated into Cst [START_REF] Gamma | Design patterns: Abstraction and reuse of objectoriented design[END_REF], after reducing 2+3 and 2-2, using Java semantics, and removing the neutral element Cst(0), thanks to the hook mechanism.

In addition, Tom provides associative matching with neutral element (also known as list-matching) that is particularly useful to model the exploration of a search space and to perform list or XML based transformations.

To illustrate the expressiveness of list-matching we consider a variadic operator ExprList whose signature is defined as follows:

Expr = ... | ExprList( Expr* )
This allows to build list of expressions. Therefore, the term ExprList(Cst(3), Var("x"),Cst [START_REF] Lacey | Imperative program transformation by rewriting[END_REF]) denotes a list composed of three elements. To define the search for a variable Var(name) the following construct can be used: In this example, list variables annotated by a * are instantiated by a (possibly empty) list. Therefore, for the considered sequence, the Var(name) will be found in second position, and the Java variable name will be instantiated by the string "x". The variables a* and b* are respectively instantiated by ExprList(Cst(3)) and ExprList(Cst [START_REF] Lacey | Imperative program transformation by rewriting[END_REF]). This corresponds to the list which contains Cst(3) and the

Strategic programming in Java

It is now well established that first order functions or rules are not sufficient to describe transformations in an elegant way: higher-order features are needed to describe how transformation rules should be applied. This is the purpose of strategies.

Tom strategy language

An elementary strategy is a minimal construct that corresponds to a transformation. We distinguish three basic ingredients: Identity (does nothing), Fail (always fails), and the notion of transformation rule (performs an elementary transformation). In our system, they must be type-preserving and are defined by extending a default strategy:

%strategy EvalConst() extends Fail() { visit Expr { Plus(Cst(c1),Cst(c2)) -> { return 'Cst(c1 + c2); } Mult(Cst(c1),Cst(c2)) -> { return 'Cst(c1 * c2); } } }
When applied to a node of sort Expr, a transformation is performed if a pattern matches the current node. Otherwise, the default strategy is applied (Fail in this case). The EvalConst strategy describes how to simplify the addition or the product of two constants. Note the use of c1 + c2, which is a Java expression. For example, it returns Cst(12) when applied to Mult(Cst(3),Cst(4)).

On top of elementary strategies, more complex strategies can be built, involving basic combinators as presented in [START_REF] Visser | Building program optimizers with rewriting strategies[END_REF][START_REF] Visser | Visitor combination and traversal control[END_REF]. By denoting s[t] the application of the strategy s to the term t, the basic combinators are defined as follows:

Sequence(s1,s2)[t] → s2[t'] if s1[t] → t' failure if s1[t] fails Choice(s1,s2)[t] → t' if s1[t] → t' s2[t'] if s1[t] fails All(s)[f(t1,...,tn)] → f(t1',...,tn') if for all i, s[ti] → ti' failure if there exists i such that s[ti] fails One(s)[f(t1,...,tn)] → f(t1,...,ti',...,tn) if s[ti] → ti' failure if for all i, s[ti] fails Omega(s,j)[f(t1,...,tn)] → f(t1,...,tj',...,tn) if s[tj] → tj' failure if j > n or if s[tj] fails
Using this formalism, a strategy trying to apply the user strategy EvalConst() and performing identity if it fails can be built with 'Choice(EvalConst(),Identity()). In the presented implementation, it can be applied to a term t using the .visit(t) method.

By combining elementary strategies and basic combinators, it becomes possible to define higher-level constructs. The fix-point operator can be defined as Repeat(s) = Choice(Sequence(s,Repeat(s)),Identity()).

This strategy will apply the strategy s repeatedly until it fails, and then return the last result obtained before failure, thus Repeat will never fail.

To write recursive strategy definitions such as Repeat(s), we use a recursion operator µ, which is similar to the rec of functional languages. Then, Repeat(s) is defined by Repeat(s) △ = µx.Choice(Sequence(s,x),Identity()), where x denotes a variable, and s a parameter of the strategy. Defining such strategies in Java is not easy because a graph has to be built to encode the recursion. The x should be seen as a pointer to the strategy itself. In JJTraveler for example, these recursive strategies can be defined, but the graph corresponding to the recursion should be built by hand. In Tom, we raised the recursion operator to the object level, using mu and variables, allowing the definition of recursive strategies in a term based framework:

Strategy Repeat(Strategy s) { return 'mu(MuVar("x"),Choice(Sequence(s,MuVar("x")),Identity())); } As a consequence, the expansion phase which transforms a term into a graph (called µ-expansion) is performed at runtime. Strategy expressions can have any kind of parameters. It is common to have a Java Collection as parameter, for instance to collect all variable definitions in an AST. Using a Stack is also common to find free variables, or to bind variables to their declaration (as in the µ-expansion, defined by a strategy of course!). As illustrated above, parameters can also be strategies (s for instance). This allows user defined strategies to behave differently depending on how they are applied, or to build continuations in strategies.

Finally, when a signature is defined in the Gom language, congruence and construction strategy operators are generated.

Those are used to discriminate constructors and thus allow to describe higherorder strategies such as map for instance.

Given a signature List = Cons(head:Element,tail:List) | Empty(), the map strategy can be defined by 'mu(MuVar("x"),Choice( Cons(s,MuVar("x")), Empty())), where Cons and Empty denote congruence operators associated to Cons and Empty. Cons(s1,s2) applies s1 and s2 to the arguments of a term rooted by Cons, otherwise it fails. Using construction strategies, this naturally allows the definition of dynamic rules. Also, the use of those congruence strategies permits the definition of local strategies, where the order of evaluation of the subterms is defined by the user. By defining two parameterized strategies Get and Set (which manage a Java HashMap), we can easily implement the rewrite rule f (x) → g(x) by 'Sequence( f(Set("x")),Make g(Get("x"))).

The combination of basic strategy combinator and Java has been pioneered by JJTraveler. In the presented work, the main contributions are the possibility to define elementary transformation rules using %strategy, the introduction and the implementation of the explicit recursion operator mu, as well as the automatic generation of congruence operators. This is important since it makes the framework easier to use and contributes to the promotion of formal methods in the Java community.

Some elements of reflexion

A shortcoming of rewrite rules is their context free nature: rules have only access to the subterm they are applied to. Using parameterized transformation rules it is of course possible to propagate context information, but this may not be convenient, for example to know to which redex a rule is applied, when traversal operators are involved. We have added the ability for each strategy, including transformation rules, to know where they are applied wrt. the original term. These positions are represented by first order objects corresponding to a sequence of integers and can be used to build strategies such as "replace at position ω" or "get subterm at position ω" by nesting Omega strategies, where Omega(s,i) applies s to the i th subterm. When dealing with transformation systems which can produce several results, the combination of traversal operators and positions allows to compute all possible reachable terms in an elegant way. This extension is very useful to describe tools and analyzers that deal with reachability or control flow analysis problems.

A main originality of Tom is the ability to perform matching against any kind of term implementation, and in particular against the objects that implement a strategy. Therefore, a strategy expression, including the recursion operator, are first class objects. Tom can be used to match, transform, or dynamically create any strategy expression. A strategy is also "traversable", in such a way that rules and strategies can be applied on a strategy itself. While quite new for us, this offers reflective capabilities that can be used to perform optimization or on the fly compilation of dynamically created strategies, as illustrated in Section 4. Along with congruence strategies and construction strategies, this allows to encode pattern matching and rewrite rules as dynamic strategies, thus providing dynamic scoped rules. Note that the presented language does not allow to construct higher-order strategies as in the Hats strategy language [START_REF] Winter | Strategy Construction in the Higher-Order Framework of TL[END_REF]. In particular, it is not possible to construct dynamic instantiations of rules.

Implementation in Java

The implementation of such strategies relies on the use of several design patterns, the most important being the visitor combinators [START_REF] Visser | Visitor combination and traversal control[END_REF] one (do not confuse with the "visitor design pattern"). The intention of this pattern is similar to the visitor one, but allows combination of visitors, and the definition of various tree traversal strategies by combination of basic visitors. To use those strategies, the term structure has first to be Visitable, that is to exhibit the term structure via the Visitable interface: public interface Visitable { public abstract int getChildCount(); public abstract Visitable getChildAt(int i); public abstract Visitable setChildAt(int i, Visitable child); } This interface allows to decompose a term and to explore its subterms, and is used by the elementary strategies All and One to describe the tree traversal. Strategies themselves have to implement this interface, to be manipulated as terms and transformed by strategies as described in the previous subsection.

Strategies are part of the visitor combinators design patterns, and so are the combined visitors. Thus strategies implement the Visitor interface, providing a Visitable visit(Visitable v) method, used to describe the behavior of a strategy when applied to a given term v. Those strategies may have strategies as children, for instance Sequence(s1,s2) will be represented by a Visitor object of class Sequence with two fields first and then which are strategies. In that case, the visit method is implemented as follows:

Visitable visit(Visitable v) throws VisitFailure { return then.visit(first.visit(v)); } It applies the first strategy to the subject term v, then apply the strategy then to the result. If one of those application fails, the whole sequence fails. In our framework, the notion of failure is encoded by a Java exception. This is why the visit method may throw a VisitFailure exception. The All and One combinators use the Visitable interface to apply their child strategy to the subterms of the subject, and build the result using the setChildAt method. To ease the strategy compilation, in our implementation the visitor children are not stored as object fields like in the previous example, but rather in a visitor array named visitors, to ease accessing them with generic algorithms.

In order to create type safe user strategies, we introduce a combinator Fwd which depends on the typed interface of the tree structure. The goal of this combinator is to dispatch the call to the generic visit to type specific transformation methods. In order to define new transformation strategies, the user has to extend this Fwd class and redefine the typed variants of the visit method, thus ensuring type preserving transformations.

The Fwd combinator possesses one child, which is the default strategy, and is designed to be extended by inheritance. Its visit method follows the visitor design pattern [START_REF] Gamma | Design patterns: Abstraction and reuse of objectoriented design[END_REF], by calling an accept method on the visited tree node, which is used to select a type specific visit method, by the classical double dispatch method. For instance, each node of type Expr in the tree representation generated for the Pico module presented in Section 2 possesses an accept method: public PicoAbstract accept(PicoVisitor v) throws VisitFailure { return v.visit_Expr(this); } where PicoVisitor is the interface that provides typed visit methods. counter-part of this modularity is the cost of complex traversals due to the visitor design pattern. The time spent in evaluating each elementary strategy is not negligible in comparison with the time spent in effectively performing the transformations. This has led us to study whether a strategy expression could be efficiently compiled or not, in order to improve the overall efficiency of a strategy based system.

To achieve this goal, two different approaches can be considered:

(i) a high-level transformation which consists in simplifying a strategy expression into a more efficient, but semantically equivalent one, (ii) a low-level transformation directly applied on the bytecode, consisting in optimizing the implementation via program transformation.

The first approach consists in transforming a strategy into a more efficient one. For that, we can consider equivalence classes of strategies and choose as normalized form the most efficient representation. As Tom strategies are first-class citizens, they can be transformed using rewrite rules. Therefore, this first approach can be described in Tom. Below, we give two examples of simplification rules:

Sequence(Identity(), x) -> { return 'x; } Choice(Fail(), x) -> { return 'x; } Not(One(Not(x))) -> { return 'All(x); } Not(All(Not(x)))
-> { return 'One(x); } One advantage of this method is the simplicity of its implementation, but to obtain a real gain, the detection of more complicated patterns is needed.

On another side, by instrumenting the strategy library we realized that most of the time is spent in executing function calls. This shortcoming is due to the visitor combinator design pattern and only appears in the implementation code (i.e. Java). As a result, this deficiency can only be reduced at a low-level. As Tom is a language built on top of Java, this optimization can be achieved by statically analyzing Java sources. However, this solution is not acceptable because it would impose a second transformation step, just after the compilation from Tom to Java.

For these reasons, our approach consists in performing the optimization at runtime, directly on bytecode programs. Furthermore, the Tom formalism is particularly well suited to describe such kind of transformation. In the following, we show how a compiled Java class can be analyzed and transformed using Tom, and we give some experimental results to express optimizations on strategy code.

Bytecode transformation by rewriting

A particularity of Java is to target a standard, machine independent, low level bytecode as compiled form of programs, which is interpreted by the Java virtual machine. Then, it becomes natural to perform program transformations at the bytecode level. This technique is used in particular to provide language extensions such as aspect oriented programming, to perform sophisticated static analysis, generate middleware code or improve runtime performances.

To manipulate Java classes, Tom provides a library [START_REF] Balland | Bytecode rewriting in tom[END_REF] which supplies a term usable by Tom out of a Java class. The library enables to define transformations of this term by strategic rewriting as well as functionalities to generate a new Java class from the modified term.

The library generates a Gom term using the ASM library [START_REF] Bruneton | ASM: a code manipulation tool to implement adaptable systems[END_REF]. This term is a memory-efficient representation of the Java class, which can then be traversed and transformed using Tom. As we have seen in the previous section, one interesting feature of Tom is its ability to perform list matching. Every Java method is represented in Gom by a list of instructions. So finding if a Iload(i) is followed by a IStore(i) can be expressed by the pattern: InstructionList(_*,ILoad(i),IStore(i),_*).

With one pattern, we can find all the occurrences of the sequence ILoad(i);IStore(i) in the body of a method. Moreover, the strategy language can be used to express complex transformations in a very concise way. Due to this library, we are able to express optimizations on strategy code directly using Tom.

Optimizing strategies

We have seen previously that the main problem of strategy efficiency was due to the implementation by the visitor combinator design pattern. Every strategy combinator is parameterized by strategies and the visit method of a combinator calls the visit methods of the parameters. When considering a large strategy term, most of the time is dedicated to visit calls.

Given a strategy expression, the objective of the strategy compiler is to generate a specialized version of the visit method, by successively inlining strategy combinators contained in it. At the end, the resulting code no longer depends on calls to other visit methods of strategy combinators. Bytecode manipulation, along with a Just-in-time tool, is well suited to achieve this objective as strategies can be visited during the execution of a Tom program. Indeed, it is possible to determine at runtime the type of each node of the tree, allowing us to proceed to the compilation. Figure 2 shows the strategy tree of a Top-Down. Every combinator has its own visit method. Each of them, except for the user defined strategy, contains at least one call to another visit method. newCode = (TMethodCode)inliner.visit('code);

Here, code is the variable used in the pattern defined above to find the definition of the visit method. This strategy of optimization can be called on the initial strategy term before visiting.

To obtain this new code, there is a compile method that generates, from an original strategy term, a class that corresponds to the compiled strategy term and returns an instance of it. Instead of generating a file for this new class, it is directly loaded into the JVM.

Benchmarks

We present in Figure 3 a few benchmarks obtained for different applications, when using the just-in-time strategy compiler. Concerning space usage, code inlining leads to duplication, but in a linear way. In practice, strategies are not so huge and contains less than 100 elementary combinators. Therefore the space increase is not an issue. The first example corresponds to the innermost normalization of a binary tree whose size ranges from 2 2 to 2 32 nodes. The strategies involved are extending failure. Therefore, each time a rule cannot be applied to a subterm, a new exception is thrown and caught by a catch statement. We obtain a gain by a factor 2 when using the compiled strategy. This can be explained by the fact that the strategy code is inlined, and thus the exception mechanism is kept local to a method instead of being distributed across methods and objects. This makes the implementation much more efficient.

The two following examples are real life applications which use strategies. The structure example is a theorem prover in the calculus of structures, as presented in [START_REF] Kahramanogulları | Implementing deep inference in TOM[END_REF]. This system features deep inference, which means it is necessary to traverse a proof term in depth to find new redexes where the deduction rules can be applied. The last application is a tool used to find quasi-interpretations of functional programs [START_REF] Bonfante | A characterization of alternating log time by first order functional programs[END_REF]. This involves manipulating of polynomial expressions, traversing them to apply transformations and substitutions, replacing variables by values for evaluation, usually in a bottom-up way.

Tom brings pattern matching and rewriting to Java, allowing to express transformations in a clean and efficient way. In order to describe complex transformations as found in compilers, optimizers or program analysis, we introduced a strategy language integrated into Java allowing to control precisely the rules applications and to describe in a formal way tree traversals and transformations.

Those strategies are built by composing objects representing elementary strategies, which can then be viewed as an interpreter of strategies, using the visitor combinator design pattern.

Among the transformations we can describe with Tom, we focussed here on low-level program transformations, for example Java bytecode. In particular, we illustrate those bytecode transformations by the just-in-time compilation of strategy expressions, using partial evaluation techniques. To express this transformation, we presented a Tom library built on top of ASM and allowing to transform bytecode expressions in an algebraic manner. Due to the reflexive properties of our strategy library, we use strategic programming to traverse the bytecode representation of the strategy expressions, perform analysis and inlining.

In this paper,we have presented rules for method inlining on strategy codes. A next step should be to add new rules for implementing classical loop-invariant code motion. Due to the recursive operator, the strategy code can contain imbricated loops and it would be interesting to remove the computations that can be performed outside.

  module Pico imports String int abstract syntax Expr = Var(name:String) | Cst(val:int) | Plus(e1:Expr, e2:Expr) | Mult(e1:Expr, e2:Expr)

  boolean hasVar(Expr l) { %match(l) { ExprList(a*,Var(name),b*) -> { return true; } ExprList(a*,Plus(x,y),b*) -> { return hasVar('x) || hasVar('y); } } return false; }

Figure 1 Fig. 1 .

 11 Fig. 1. Bytecode transformations in Tom

Fig. 3 .

 3 Fig. 3. Experimental results: programs are run without and with strategy optimisation. The execution time is expressed in seconds (shorter is better).

Acknowledgments: We sincerely thank Jeremie Delaitre for the initial development of bytecode rewriting in Tom and its work on strategy compilation.

The visit method of the Fwd combinator will call the accept method when applied to a term belonging to the Pico module (i.e. instance of the PicoAbstract), and falls back to the default strategy otherwise. Each specific type-preserving visit method is implemented as a call to this default strategy. Then, each user defined strategy will only have to extend this Fwd class and override one or many type specific visit method to implement a type safe transformation, that can be combined with the elementary strategies to form a complex transformation. The EvalConst strategy defined in section 3.1 can then be defined as the following class: This framework may seem difficult to use from a user point of view, but as the typed tree structure is generated by the Gom compiler, the framework is also instantiated for this typed structure, and the only requirement for the user is to extend the Fwd class to create its transformation strategies. In the context of Tom, the implementation of user defined strategies is straightforward when using the %strategy construct since the Java code is automatically generated.

Optimizing strategies by Bytecode transformation

As mentioned in section 3, Tom strategies are represented by a tree composed of user defined strategies basic combinators. As a consequence, high level strategies, such as leftmost-innermost, are expressed by a combination of low level primitives. This approach has many advantages and makes the strategy language extensible. A corresponds to the first strategy to apply, and visitors [START_REF] Balland | Tom: Piggybacking rewriting on java[END_REF] to the second one. When considering the statement return visitors [START_REF] Balland | Tom: Piggybacking rewriting on java[END_REF].visit(firstResult), the strategy compiler has to detect the call to visit in order to inline its body. This is performed at runtime using reflective capabilities of Java: the dynamic type of visitors [START_REF] Balland | Tom: Piggybacking rewriting on java[END_REF] is determined and the implementation of the corresponding visit is inlined. In our example, the considered dynamic type is All and the call to visit can be replaced by the loop over children. This process is repeated until getting a fix-point which corresponds to the compiled strategy.

In our framework, there is a mapping from the real bytecode (extracted using ASM) to an algebraic view (implemented by Gom). Therefore, a Java class is represented by a term. For each event generated by ASM corresponds an algebraic constructor. Due to lack of space, we cannot explain in detail how a Java class is described (ASM generates more than 250 different kinds of events). In the following we consider that a Java class is characterized by a list of methods. Each of them has a name, a profile, as well as an associated list of instructions. This abstract view can be described using an algebraic signature: TMethodDef = Method(info:TMethodInfo, code:TMethodCode) TMethodInfo = Info(name:String, desc:TMethodProfile) TMethodCode = Code( TInstruction* )

In order to inline a call to visit, the first step consists of finding the calls to this method. Given a strategy (i.e. a graph of objects), we consider the algebraic term that represents the list of classes that occur in the graph of objects. Starting from the root, we have to find the implementation of the visit method. This is done by inspecting the list of methods associated to a given class.

%match(mList) {

MethodList(_*,Method(MethodInfo[name="visit"],code),_*) -> { /* processing where we can use the code variable */ } } In this example, the associativity of MethodList is used to search for a method whose name is visit. When found, the body of this method is retrieved and stored in the code variable. Note also that syntactic matching is a concise way to retrieve information in deep subtrees (the slot name for example). Now that the term corresponding to the method's body has been retrieved, the inlining operation can really start. This second step consists in determining, for each call to visit, the type of the callee and to collect its implementation code. The type of each sub-strategy is determined at runtime using Java reflexivity. The corresponding code is mapped to a Gom term and inlined: this consists in replacing the call to visit by the considered term. .visit(_) pattern is detected by searching for five consecutive bytecode instructions: Aload(0) puts 0 on the stack in order to retrieve the class variable visitors (using Getfield). The variable indexInst can be instantiated by any bytecode instruction. This is useful since there exists different ways to put the index on the stack. Aaload corresponds to the access to visitors[index]. Finally, Invokeinterface invokes the method visit. The statement newCode = ... performs the runtime type detection, loads the class, and store the term representation into newCode. The inlining is performed by returning 'Code(...). This replaces the five matched instructions by newCode.

To be correct, note that we have to rename each label and index before inlining visit calls. Otherwise, name capture problems may occur. Similar to the inlining process, the renaming process is implemented by a user defined strategy named Rename.

The combination of renaming and inlining is defined by a strategy, using a TopDown operator to perform a traversal of the tree: MuStrategy inliner = 'Sequence( TopDown(Rename()), TopDown(InlineVisitCode()) );


Kamal Medjaher
email: kamal.medjaher@ens2m.fr

Amine Mechraoui
email: amine.mechraoui@gipsa-lab.inpg.fr

Noureddine Zerhouni

Diagnostic et pronostic de défaillances par réseaux bayésiens

Keywords: Défaillance, Dégradation, Diagnostic, Localisation, Pronostic, Réseaux Bayésiens, Système dynamique Fault, Degradation, Diagnosis, Isolation, Prognosis, Bayesian networks, Dynamic systems

Cet article a pour but de montrer l'utilisation des réseaux bayésiens statiques et dynamiques dans le domaine de la localisation des défaillances (diagnostic) et de l'anticipation ou de la prédiction des éventuelles dégradations pouvant affecter un système dynamique. Dans le premier cas, les réseaux bayésiens statiques sont utilisés pour calculer les probabilités a posteriori de ou des causes les plus probables d'une anomalie observée (observation ou évidence). Dans le second cas, les réseaux bayésiens dynamiques sont utilisés pour tenir compte de la dynamique du système et permettre de prédire son comportement futur en fonction de son état actuel et d'autres variables ou contraintes exogènes.

ABSTRACT. This paper deals with fault diagnosis and prognosis in dynamic systems by using static and dynamic bayesian networks. In the first case, static bayesian networks are used to compute the a posteriori probabilities of the most probable causes of an observed abnormal situation on the system (called evidence or observation). In the second case, dynamic bayesian networks are used in order to take into account the system's dynamic and to predict its future behaviour according to its actual state and other exogeneous variables or constraints.

Introduction

La complexité de plus en plus croissante des systèmes industriels, ajoutée aux contraintes liées à la compétitivité et à la législation en vigueur en terme de respect de l'environnement, ont poussé les industriels et la communauté scientifique à chercher des solutions pouvant rendre ces systèmes plus performants, plus compétitifs et plus sûrs. L'un des points sur lesquels les travaux de recherche sont orientés est la maintenance conditionnelle dans laquelle sont menés des travaux sur le diagnostic et le pronostic de défaillances. Le diagnostic de défaillances des systèmes industriels a pour rôle de détecter et de localiser les défaillances qui surviennent sur le système et aussi d'identifier les causes de ces défaillances. Effectuer un diagnostic de défaillances sur un système donné c'est identifier le mode de fonctionnement dans lequel il se trouve. Les premières méthodes de diagnostic furent basées sur la redondance de matériels jugés critiques pour le fonctionnement du système. La redondance matérielle est très répandue dans les domaines où la sûreté de fonctionnement est cruciale pour la sécurité des personnes et de l'environnement, comme dans l'aéronautique ou le nucléaire. Les principaux inconvénients de la redondance matérielle sont liés aux coûts dus à la multiplication des éléments ainsi que l'encombrement et aux poids supplémentaires qu'elle génère. Le développement des calculateurs numériques permet aujourd'hui la mise en oeuvre, dans le milieu industriel, des méthodes modernes de l'automatique et de l'intelligence artificielle. Cette nouvelle approche permet d'éliminer en partie, voire même en totalité, la redondance matérielle pour le diagnostic des systèmes industriels. Globalement, on distingue deux approches de diagnostic [START_REF] Isermann | Model-based fault-detection and diagnosis -status and applications ))[END_REF], [START_REF] Isermann | Supervision : fault-detection and fault-diagnosis methods. An introduction ))[END_REF], [START_REF] Toscano | Commande et diagnostic des systèmes dynamiques[END_REF] : l'approche quantitative utilisant principalement des modèles analytiques (espace de parité, observateurs, estimation des paramètres, etc.), et l'approche qualitative faisant appel à des méthodes sans modèles analytiques (basées essentiellement sur les techniques de l'intelligence artificielle) [START_REF] Piechowiak | Intelligence artificielle et diagnostic ))[END_REF]. Dans la première approche, quantitative, il est indispensable d'avoir un modèle mathématique des phénomènes physiques qui s'y déroulent pour réaliser un diagnostic. La qualité des résultats obtenus dépend alors fortement de la qualité du modèle obtenu. Cependant, il es très difficile, voire même impossible dans certains cas, d'obtenir un modèle qui traduise fidèlement le comportement du système. La seconde approche, qualitative, est quant à elle exploite les données disponibles pour faire de l'apprentissage ou encore, l'expertise qu'on a du système pour construire des règles. Mais, dans le cas où la base de données est incomplète ou insignifiante, ou encore si plusieurs cas sont possibles (explosion combinatoire), ces méthodes deviennent difficilement applicables et peuvent conduire à des conclusions erronées. Dans le cas des systèmes complexes où des connaissances expertes sont disponibles, il est possible d'utiliser un outil graphique bien adapté : les réseaux bayésiens [START_REF] Pearl | Probabilistic reasoning in intelligent systems : Networks of plausible inference[END_REF], [START_REF] Naïm | Réseaux bayésiens[END_REF]. Ces derniers permettent de représenter graphiquement cette connaissance en tenant compte des incertitudes. Dans la première partie de cet article nous verrons comment les réseaux bayésiens statiques sont utilisés pour faire du diagnostic (de la localisation principalement) sur un moteur électrique à aimant permanent. Il s'agit principalement d'exploiter la structure graphique du modèle obtenu et d'utiliser les algorithmes d'in-férence existants pour calculer des probabilité a posteriori de l'état des composants du système suite à une ou plusieurs observations (appelées évidences). Contrairement au diagnostic, le pronostic de défaillances est un domaine de recherche relativement récent auquel la communauté scientifique commence à accorder une importance croissante. Plusieurs définitions du pronostic sont proposées dans la littérature. Ainsi, la norme ISO 13381-1 : 2004(ISO, 13381-1, 2004) définit le pronostic comme étant l'estimation de la durée de fonctionnement avant défaillance et du risque d'existence ou d'apparition ultérieure d'un ou de plusieurs modes de défaillance. Le rôle du processus de pronostic est alors d'estimer la probabilité qu'une défaillance survienne à un instant donné, ou encore de prédire le temps résiduel avant défaillance (communément appelé RUL pour Remaining Useful Life). Cela permet donc l'aide à la prise de décision et à la planification d'actions de maintenance pour éviter l'immobilisation du système et augmenter sa disponibilité et sa fiabilité. Les méthodes de pronostic peuvent être classées selon trois approches [START_REF] Byington | Prognostic Enhancements to diagnostic Systems for Improved Condition-based maintenance ))[END_REF] : le pronostic basé sur un modèle physique, le pronostic guidé par les données et le pronostic basé sur les données de retour d'expérience. Les méthodes à base de modèle physique de dégradation donnent des résultats précis (à condition de disposer d'un modèle précis) mais, en terme d'applicabilité, ces méthodes sont les moins répandues. En effet, obtenir le modèle de dégradation demande des moyens et coûte donc cher. De plus, le modèle obtenu est propre à un type de composant, matériau ou machine donné ; et ne peut donc pas être généralisé. Les méthodes utilisant des données capteurs ou opérateurs se situent au milieu de la pyramide (voir [START_REF] Byington | Prognostic Enhancements to diagnostic Systems for Improved Condition-based maintenance ))[END_REF]) en termes de précision, de coût et d'applicabilité. Dans la deuxième partie de cet article, nous proposons une procédure pour construire un modèle de pronostic pour des systèmes dynamiques en utilisant deux outils : les bond graphs (BG) [START_REF] Karnopp | Systems Dynamics : A Unified Approach[END_REF] et les Réseaux Bayésiens Dynamiques (RBD) [START_REF] Murphy | Dynamic Bayesian Networks : Representation, Inference and Learning[END_REF]. Les premiers sont utilisés pour représenter la dynamique du système et pour extraire le modèle analytique correspondant (fonction de transfert, représentation d'état), et les seconds permettent une représentation plus générale des connaissances qu'on a du système en intégrant des variables exogènes (actions de maintenance, avis d'experts, etc.). Le présent article est organisé comme suit : la section 2 est dédiée à l'utilisation des réseaux bayésiens statiques en diagnostic de défaillances, plus particulièrement une application sur la localisation de défaillances sur un moteur électrique à aimants permanents. Ensuite, à la section 3, nous présenterons une procédure pour construire un modèle de pronostic à partir d'une description physique d'un système donné. Cette procédure sera illustrée sur un exemple de système consistant en la suspension d'un quart de véhicule. Enfin, nous terminerons par une conclusion.

Diagnostic de défaillances par réseaux bayésiens statiques

Le but de cette section n'est pas de présenter toute la théorie de diagnostic par réseaux bayésiens statiques, mais plutôt de donner une application de ces derniers dans la localisation de défaillances pouvant survenir sur un moteur électrique synchrone à aimants permanents. Les lecteurs intéressés par l'aspect théorique peuvent consulter [START_REF] Sheppard | A Bayesian Approach to Diagnosis and Prognosis Using Built-In Test ))[END_REF] ou encore [START_REF] Mecharaoui | Bayesian based fault diagnosis : application to an electrical motor ))[END_REF].

Description du système

Un moteur synchrone à aimants permanents (voir figure 1) est composé principalement d'un rotor et d'un stator qui génère le mouvement de rotation transmis par l'arbre à la charge. Le stator est alimenté par un signal triphasé qui crée un champs rotatif. Grâce aux aimants permanents, le rotor tourne à la même vitesse que celle du champs rotatif crée par le stator.

Figure 1. Moteur synchrone à aimants permanents

L'objectif principal de cette application est de réaliser un diagnostic de défaillances sur le mouvement de rotation de l'arbre du moteur (on s'intéressera à la disponibilité ou non du mouvement de rotation).

Modélisation

Pour construire le réseau bayésien statique, qui sera utilisé dans l'étape de diagnostic, nous avons exploité une base de données fournie par un expert du système, qui inclue une décomposition fonctionnelle du moteur électrique dans son ensemble. A partir de cette base de données, nous avons extrait les relations causales qui existent entre les différents noeuds (représentant les composants) du graphe (étape qualitative de construction du modèle final) et ensuite, nous avons estimé les probabilités conditionnelles relatives à chacun des noeuds du graphe (étape quantitative). La décomposition fonctionnelle existante du moteur a été utilisée dans ce qui suit pour identifier les différents noeuds du modèle graphique correspondant ainsi que les relations causales qui existent entre eux. Après cette étape qualitative, nous avons procédé à la construction du réseau bayésien utilisé en diagnostic des éventuelles défaillances pouvant affecter les composants impliqués dans le mouvement de rotation de l'arbre (voir figure 2).

Une fois la structure graphique du réseau bayésien obtenue, nous l'avons quantifié en estimant les probabilités marginales a priori et les probabilités conditionnelles de [START_REF] Naïm | Réseaux bayésiens[END_REF]. Ces valeurs peuvent ensuite être modifiées en fonction de nouvelles observations ou des résultats de simulation. Les calculs sur le réseau bayésien de la figure 2 sont manuellement fastidieux à faire. Pour contourner cette difficulté, nous avons fait appel à l'utilisation du logiciel BayesiaLab pour calculer les probabilités jointes, marginales et conditionnelles. BayesiaLab est un logiciel adapté pour la modélisation, l'apprentissage et l'analyse des réseaux bayésiens. Cependant, il existe d'autres logiciels ou boîtes à outils qui traitent des réseaux bayésiens (BNT : Bayesian Networks Toolbox, Hugin, NETICA, etc.) et qui peuvent être utilisés avec succès.

Localisation de défaillances

Des simulations effectuées sur le modèle graphique final obtenu ont permis de localiser les défaillances pouvant survenir sur le système. Il s'agit de calculer les probabilité conditionnelles a posteriori pour chaque mode de chaque noeud du réseau. Dans ce qui suit, deux scénarios sont considérés : le mode de fonctionnement nominal et la présence d'une défaillance.

Mode de fonctionnement nominal :

Ce scénario correspond au mode de fonctionnement nominal du moteur (le mouvement de rotation est supposé disponible). Le réseau bayésien relatif à ce mode est donné à la figure 3.

Dans ce mode, étant donné qu'aucune anomalie n'est observée, la probabilité jointe du système complet est égale à 1. Des probabilités marginales sont calculées 3) montrent que la probabilité concernant la disponibilité du mouvement de rotation est de 92.71% et que celles du stator, du rotor et de l'arbre de transmission (mode OK) sont égales à 99.49%, 95.92% and 98.88% ; respectivement.

Localisation d'une défaillance :

Nous considérons dans ce scénario que le mouvement de rotation de l'arbre de rotation n'est pas disponible (P (M vtRot = N on) = 1). De plus, nous supposons qu'il existe un capteur qui permet de mesurer le spectre vibratoire (noeud SV sur le réseau de la figure 2). Dans le cas où de fortes vibrations sont détectées (observation ou évidence), la probabilité du noeud SV change et devient donc une certitude P (SV = Elevé) = 1. L'actualisation du réseau bayésien conduit à de nouveaux résultats de simulation donnés à la figure 4. Ces résultats montrent dans ce cas que le rotor serait la cause la plus probable du dysfonctionnement. En effet, de fortes vibrations peuvent causer d'une part, des dégradations au niveau des roulements et d'autre part, un mal positionnement des masses d'équilibre qui, à leur tour, causent la dégradation du rotor. Cela justifie donc la probabilité que le rotor soit la cause la plus probable de l'indisponibilité du mouvement de rotation (P (rotor =dégradé|M vtRot = N on, SV =Elevé) ≈ 0.87).

Pronostic de défaillances par RBDs

Introduction

Contrairement au diagnostic dont le rôle est de détecter et localiser des défaillances (après apparition), le pronostic a pour but de fournir une estimation sur la durée de vie résiduelle d'un système, composant ou machine. Il permet donc d'anticiper la défaillance pour mieux planifier les actions de maintenance. Dans cette section nous aborderons la notion de pronostic, les différentes approches existantes ainsi que l'utilisation des réseaux bayésiens dynamiques comme outil graphique permettant de construire un modèle de pronostic. Dans la littérature, plusieurs définitions ont été données à propos du pronostic [START_REF] Muller | Contribution à la maintenance prévisionnelle des systèmes de production par la formalisation d'un processus de pronostic[END_REF], [START_REF] Byington | Prognostic Enhancements to diagnostic Systems for Improved Condition-based maintenance ))[END_REF]. Cependant, une définition du pronostic industriel qui peut faire l'unanimité est celle donnée par la norme ISO 13381-1 : 2004 pour laquelle (( le pronostic correspond à l'estimation de la durée de fonctionnement avant défaillance et du risque d'existence ou d'apparition ultérieure d'un ou de plusieurs modes de défaillance )). En outre, le processus de pronostic est par nature entaché d'incertitude et doit être associé à une mesure de confiance. Ce dernier point a d'ailleurs été souligné par Provan [START_REF] Provan | Prognosis and condition-based monitoring : an open systems architecture ))[END_REF], selon lequel l'incertitude est centrale à toute définition du pronostic. Ceci s'explique par le fait que le pronostic implique une projection dans le future, et que toute future projection doit contenir quelques incertitudes, puisque le future ne peut être prédit avec certitude. En effet, le rôle principal d'un processus de pronostic est de déterminer la durée de vie résiduelle avant défaillance d'un composant ou d'un système, en fonction de son état actuel et du profil futur d'utilisation. Cette estimation dépend donc de plusieurs paramètres (conditions initiales, environnement d'exploitation, intervention de maintenance, etc.) et par conséquent, le résultat obtenu sur le RUL ne doit pas être une valeur absolue mais plutôt une distribution sur un intervalle donné. Les méthodes de pronostic peuvent être classées en trois catégories : les méthodes à base de modèle physique, les méthodes utilisant des données capteurs ou opérateurs, et enfin les méthodes à base de données de retour d'expérience. Pour plus de détails, les lecteurs peuvent se référer au livre écrit par [START_REF] Vachtsevanos | Intelligent Fault Diagnosis and Prognosis for Engineering Systems[END_REF]. Les méthodes basées sur un modèle physique supposent l'existence d'un modèle dynamique du système qui est fonction de la dégradation. Cette dernière peut être une variables continue dont l'évolution est déterminée par une loi déterministe ou stochastique. Ainsi, en simulant le comportement du système, représenté par un ensemble d'équations différentielles, on est capable de donner une estimation du RUL. Cela suppose bien évidement l'existence de méthodes de résolution de ces équations mais aussi la définition de seuils d'alarmes au delà desquels le système est supposé entrer dans un état de défaillance. L'avantage de ces méthodes réside dans la précision des résultats qu'elles fournissent. En effet, si on dispose d'un modèle mathématique de dégradation concernant un composant donné, il est plus facile d'estimer le RUL avec une certaine confiance. Leur inconvénient majeur est qu'il est d'une part, difficile et coûteux d'obtenir le modèle et d'autre part, chaque modèle est propre à une famille de composant ou de matériau (à noter que les modèles de dégradation développés jusqu'à présent s'appuient globalement sur des phénomènes de fatigue, d'usure ou encore de corrosion). Les méthodes à base de données reposent principalement sur l'exploitation des données fournies soit par les capteurs installés sur le système, soit par les différents opérateurs travaillant sur l'installation (observations, tests périodiques, vérifications, etc.). Ces méthodes sont basées sur l'exploitation de symptômes ou d'indicateurs de dégradations (valeur d'une grandeur physique comme la température par exemple, ou encore combinaison de plusieurs grandeurs physiques). L'évolution future de ces symptômes, réalisée par des techniques utilisant les outils de l'intelligence artificielle, des méthodes statistiques ou encore des estimateurs d'état, permet de calculer le temps restant avant l'apparition d'une défaillance (en admettant que les seuils des différents modes de fonctionnement du système sont préalablement définis). Les méthodes de cette approche de pronostic ont l'avantage de ne plus souffrir du manque de modèle analytique de la dégradation et sont donc plus simple à mettre en oeuvre que les méthodes à base de modèle physique de dégradation. Cependant, en terme de précision elles donnent des résultats moins précis que ceux la première approche. La troisième et dernière approche de pronostic est celle utilisant les données de retour d'expérience. Le principe de cette approche repose sur l'exploitation d'une fonction de fiabilité ou d'un processus stochastique de détérioration dont les paramètres sont déterminés à partir d'expertise ou de données de retour d'expérience. Ces méthodes sont faciles à mettre en oeuvre si l'on dispose d'un volume de données de retour d'expérience suffisant et fiable pour chaque type de machine, système ou composant. En effet, une fois les paramètres de la loi de fiabilité obtenus, on peut à tout instant calculer le taux de défaillance par exemple, et donc, en fonction des conditions limites fixées, déterminer le RUL. Cependant, ces méthodes sont les moins précises et souffrent du manque de données de retour d'expérience (données incomplètes ou quasiment inexistantes, durée longue pour les obtenir, etc.). De plus, les lois de fiabilité obtenues sont propres à chaque type ou famille de composant ou machine et ne peuvent pas donc être généralisée. Le choix des réseaux bayésiens dynamiques pour la construction d'un modèle de pronostic est justifié par la possibilité de représenter sur un même graphe la dynamique du système et des informations exogènes (avis d'experts, actions engagées, état actuel du système, etc.).

Procédure de pronostic de défaillances

Dans cette section nous présentons une procédure pour construire un modèle de pronostic de défaillances en partant d'un modèle physique d'un système dynamique. Cette procédure s'appuie sur deux outils de modélisation que sont : les bond graphs et les réseaux bayésiens dynamiques. Le couplage de ces deux outils est justifié par le fait que lorsqu'on est confronté aux systèmes dynamiques, on a besoin dans un premier temps de générer le modèle dynamique sous forme analytique (BGs), et ensuite pour les besoins du pronostic de défaillances utiliser les RBDs pour représenter, en plus de la dynamique du système, d'autres variables ou contraintes telle que la prise en compte de l'état actuel (modes de fonctionnements) ou encore les éventuelles actions de maintenance réalisées sur le système. La procédure de pronostic proposée dans cet article est réalisée en cinq étapes :

-générer le modèle BG en causalité intégrale, -générer les résidus à partir du modèle BG en causalité dérivée, -construire le Graphe Causal Temporelle (GCT) en utilisant le modèle BG en causalité intégrale, -générer le RBD en exploitant la structure graphique du GCT et les informations des résidus, -simuler le RBD obtenu pour estimer le comportement futur du système et pour fournir des métriques de pronostic.

Le modèle BG est obtenu à partir de la représentation physique du système dynamique, en représentant les transferts de puissance entre les différents éléments physiques le constituant [START_REF] Karnopp | Systems Dynamics : A Unified Approach[END_REF]. Le modèle mathématique correspondant au comportement dynamique du système peut alors être déduit du modèle BG en causalité intégrale sous forme de fonction de transfert ou d'une représentation d'état. Les résidus sont générés à partir du modèle BG en causalité dérivée. Cette forme de causalité est préférée dans ce cas pour deux principales raisons. D'abord, à l'instant de détection d'une défaillance, les conditions initiales ne sont pas toujours connues ; ce qui rend les calculs impossibles. Ensuite, dans la phase de localisation, on a une observation des effets (la ou les défaillances) et on essaie d'identifier les causes de ces anomalies. Ainsi, les relations de causalité sont tout simplement inversées. Le GCT est obtenu à partir du modèle BG en causalité intégrale [START_REF] Mosterman | Monitoring, prediction and fault isolation in dynamic physical systems )[END_REF]. Ce graphe est une représentation qui capture les relations dynamiques locales entre les variables, et qui fournit une représentation plus explicite des relations entre les paramètres et les variables de comportement du système [START_REF] Lerner | Bayesian Fault Detection and Diagnosis in Dynamic Systems )[END_REF]. Dans cette contribution, le GCT est utilisé pour construire le RBD. Un RBD est une extension des réseaux bayésiens statiques. Ils permettent de modéliser des distributions de probabilité sur des ensembles semi-infinis de variables aléatoires (U t , X t , Y t ) représentant les variables d'entrée, les états cachés et les sorties d'un modèle d'état [START_REF] Murphy | Dynamic Bayesian Networks : Representation, Inference and Learning[END_REF]. Les RBDs généralisent les filtres de Kalman et les chaînes de Markov (cachées et hiérarchiques). Leur utilisation permet de faire de la surveillance et de la prédiction de l'état futur du système dynamique. Dans notre cas, le RBD du système est généré à partir du GCT en appliquant la méthode proposée initialement par [START_REF] Lerner | Bayesian Fault Detection and Diagnosis in Dynamic Systems )[END_REF]. A l'étape de simulation, le RBD est paramétré en spécifiant les distributions de probabilité des différents noeuds qui le composent. Ensuite, l'utilisation d'algorithmes d'inférence déjà existants [START_REF] Murphy | Dynamic Bayesian Networks : Representation, Inference and Learning[END_REF]) permettra de simuler le comportement et l'état futur du système, et l'analyse des résultats obtenus peut conduire à des métriques pour le pronostic (estimation du RUL, confiance sur la valeur du RUL, etc.).

Application

Pour illustrer les étapes de la procédure proposée, on prend comme application un système physique, qui consiste en la suspension d'un quart de véhicule, et représenté à la figure 5 Le modèle BG précédemment construit est ensuite utilisé pour générer des indicateurs de défaillances (Relations de Redondance Analytique RRA, et résidus). Brièvement, une RRA est une contrainte reliant des variable connues (mesures, entrées, paramètres) ou estimées du système, tandis qu'un résidu est une évaluation numérique d'une RRA (pour plus de détails, voir (B. Ould Bouamama et al., 2006)). Les RRAs sont obtenues à partir du modèle BG en causalité dérivée préférentielle en suivant les étapes suivantes :

-mettre le modèle BG en causalité dérivée préférentielle, -écrire les équations aux jonctions du modèle obtenu, -éliminer les variables inconnues de chaque équation, -générer les RRAs, et en les évaluant, déduire les résidus correspondants.

L'élimination des variables inconnues est réalisée sur le modèle BG en causalité dérivée en parcourant les chemins causaux des mesures aux variables inconnues. Pour l'exemple considéré, deux résidus peuvent être générés (le système étant totalement observable et ne comportant pas de boucles causales ni algébro-différentielles). Ces résidus sont donnés par les équations suivantes :

r 1 = k dz dt -ω 1 + m d 2 ω 1 dt 2 -M d 2 ω 2 dt 2 [1] r 2 = K (ω 1 -ω 2 ) + M d 2 ω 2 dt 2 + b d (ω 1 -ω 2 ) dt [2]
A partir des résidus obtenus, la matrice de signature des défaillances du système quart de véhicule est construite directement en analysant la structure de chacun des résidus. Cette matrice est binaire, dont les lignes correspondent aux éventuelles défaillances des composants et des capteurs du système, et les colonnes les résidus. Une valeur (( 1 )) dans la matrice signifie qu'un résidu r i est sensible à la défaillance du composant correspondant (représenté par un ou plusieurs paramètres dans l'équation du résidu). Deux colonnes D b pour la détectabilité et I b pour la localisabilité (ou isolabilité) sont ajoutées à cette matrice (voir tableau 1). Une valeur (( 1 )) dans D b /I b signifie qu'une défaillance du composant physique correspondant est détectable/isolable. Dans cet exemple, les défaillances sont toutes détectables mais seules celles affectant la roue et l'amortisseur sont localisables.

Le GCT du système de suspension du quart de véhicule est donné à la figure 6. Ce graphe est obtenu à partir du modèle bond graph en causalité intégrale préférentielle de la figure 5(b) et sur lequel on a fait apparaître les variables généralisées effort (e i ) et flux (f i ). Deux types de relations sont représentés sur le GCT, à savoir : les relations algébriques (éléments résistance) et les relations différentielles (éléments C et I). Ces relations sont utilisées lors de la construction du RBD.

Le RBD du système est montré à la figure 7. Il est construit à partir du GCT en appliquant la méthode proposée dans [START_REF] Lerner | Bayesian Fault Detection and Diagnosis in Dynamic Systems )[END_REF] (en traduisant les diffé- Discussion : l'application de la procédure décrite à la section 3.2 a permis d'aboutir au RBD du système de suspension du quart de véhicule. Les paramètres de ce modèle sont ceux du système physique auxquels on peut ajouter des bruits pour tenir compte des erreurs de modélisation et des bruits de mesure. De plus, nous avons ajouté des noeuds dont l'état est fonction des valeurs prises par les résidus et donc pouvant renseigner sur l'état actuel du système (mode de fonctionnement nominal, dégradé, défaillante, etc.). La simulation de ce modèle final permet alors d'obtenir des valeurs sur le RUL et l'état futur du système.

Conclusion

Le diagnostic peut se révéler intéressant pour des systèmes où l'occurrence d'une défaillance est sans conséquences graves sur la sécurité des personnes ou encore sur l'environnement. Il a pour rôle de détecter, de localiser et d'identifier les défaillances afin de prendre des actions adéquates pour la conduite du système (accommodation, reconfiguration, arrêt d'urgence, etc.). Cependant, pour les processus à risque ou tout simplement pour des soucis d'économie et de disponibilité, il serait plus intéressant d'anticiper la défaillance. Ceci est réalisé par le processus de pronostic qui permet, entre autres, d'estimer la durée résiduelle avant défaillance pour mieux planifier les actions de maintenance, augmenter la disponibilité et améliorer la fiabilité du système. Dans la première partie de cet article, les réseaux bayésiens statiques ont été utilisés pour localiser des défaillances sur un moteur à aimants permanents. L'utilisation de cet outil a permis de modéliser la connaissance fournie par un expert pour faire du diagnostic. Dans la seconde partie de l'article, une procédure pour construire un modèle de pronostic pour des systèmes dynamiques relativement simples a été proposée. Cette procédure repose sur le couplage de deux outils : les BGs et les RBDs. Les premiers sont utilisés pour modéliser les phénomènes physiques propres au système, et les seconds pour intégrer au modèle de comportement dynamique généré des connaissances exogènes telle que la prise en compte d'informations issues des résidus ou encore les bruits de modélisation et de mesure. La simulation du modèle graphique final construit peut être exploité pour fournir des indicateurs. Ces derniers peuvent être utilisés pour qualifier les performances futures du système et pour aider à la prise de décision concernant les éventuelles actions à entreprendre afin d'augmenter sa disponibilité et améliorer sa fiabilité.

Figure 2 .

 2 Figure 2. Réseau bayésien statique du système

Figure 3 .

 3 Figure 3. Scénario 1 : mode de fonctionnement nominal

Figure 4 .

 4 Figure 4. Scénario 3 : présence de défaillance

  (a). Ce système est extrait d'un cours de G. Dauphin Tanguy (Dauphin-Tanguy, 2001). Le schéma physique montre les différents phénomènes pris en compte : le profil de la route, la roue représentée par la masse m et le ressort de raideur k, le châssis représenté par la masse M , le ressort de raideur K et les frottements représentés par l'élément R de paramètre b. Le modèle BG en causalité intégrale de ce système est donné à la figure 5(b). Une analyse structurelle (ordre du système, commandabilité, observabilité, etc.) peut être réalisée directement sur le modèle BG obtenu sans utiliser de modèle mathématique. Sur le modèle de la figure 5(b) on peut distinguer des éléments qui stockent de l'énergie (éléments C et I) auxquels sont associés des variables d'état, des éléments qui dissipent de l'énergie (R), et des éléments qui sont des sources d'énergie (Se et Sf ). Le modèle BG en causalité intégrale permet de générer le modèle d'état du système et donc les matrices de transition, de commande et d'observation qui peuvent être utilisées lors de la construction du RBD.

Figure 5 .

 5 Figure 5. Système physique : (a) quart de véhicule, (b) modèle BG

Tableau 1 .Figure 6 .

 16 Figure 6. Graphe causal temporel du système

Figure 7 .

 7 Figure 7. Réseau bayésien dynamique du système

4ème Journées Francophones sur les Réseaux Bayésiens, Lyon, 29 -30 mai 2008

4ème Journées Francophones sur les Réseaux Bayésiens, Lyon, 29 -30 mai 2008

4ème Journées Francophones sur les Réseaux Bayésiens, Lyon, 29 -30 mai 2008


est destinée au dépôt

Tracking of the chemical modifications occuring during the dry heating of alpha-lactalbumin

Muhammad Gulzar, Said Bouhallab, Valérie Briard-Bion, Julien Jardin,

Thomas Croguennec

To cite this version:

Chemical modifications on dry heated α α α α-lactalbumin

Gulzar M., Bouhallab S., Briard-Bion V.*, Jardin J., Croguennec T.

Dry heating is commonly used in food and pharmaceutical industries to decontaminate heatsensitive samples such as egg white or therapeutic protein products. Under these conditions thermal stability of proteins is increased and the changes in protein structure are limited.

However, it was noted that the functionalities of the dry heated proteins are changed: for instance lysozyme, a poor foaming agent, gives stable foams after dry heating even if the secondary and tertiary structure of the protein are not affected. This discovery expends the use of dry heat treatment for functionalizing a wide variety of food proteins, even to those that resist wet-heat treatments of decontamination.

A clear picture of dry-heat induced modifications of proteins is necessary especially for those dedicated to the formulation of infant formula. In this study, LC-MS/MS was used to track the chemical modifications on milk proteins as illustrated here with α-lactalbumin. The samples adjusted to pH 6.5 and water activity a w = 0.23 were dry heated at 100°C for up to 24 hours.

Dry heat treatment traps a fraction of α-lactalbumin molecules into non-native monomers.

These non-native monomers were characterized by the loss of one or two water molecules per α-lactalbumin molecules. Using tandem mass spectrometric peptide mapping, these chemical modification were attributed to i-the formation of pyroglutamic acid from the N-term glutamic acid and ii-the formation of an internal cyclic imide at position Asp 64 . The structural and functional consequences of theses modifications are discussed.

* presenting author

POSTER ONLY

Muhammad Gulzar, Said Bouhallab, Valérie Briard-Bion, Julien Jardin, Thomas Croguennec. Tracking of the chemical modifications occuring during the dry heating of alpha-lactalbumin.EUPA 2013, Oct 2013, Saint-Malo, France. , 2013. hal-01190679


domain: sdv sde

text:
Micol Bellucci

Kim Milferstedt

Renaud R Escudie

Gaelle Gévaudan

Thibaut Saur

Nicolas Bernet

Jean-Jacques Godon

Jérôme Harmand

Complex autochthonous biofilm community limits the invasion of a pure culture of Aquabacterium sp. at various concentrations

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

COMPLEX AUTOCHTHONOUS BIOFILM COMMUNITY LIMITS THE INVASION OF A PURE CULTURE OF AQUABACTERIUM SP. AT VARIOUS

CONCENTRATIONS

 Micol Bellucci, Kim Milferstedt, Renaud Escudié, Gaëlle Gévaudan, Nicolas Bernet, Jean-Jacques Godon, Jérôme HarmandINRA, UR0050, Laboratoire de Biotechnologie de l'Environnement, Narbonne, F-11100,

France

Invasion and colonization of an autochthonous biofilm community by invading microbes might alter the overall ecosystem functioning. Such changes could be positive when a desired process is wanted to be enhanced (e.g. bioaugmentation), or negative if a pathogen implements in beneficial biofilms. The success of invasion appears to depend on several factors such as competition for resources, diversity of the autochthonous community, the number of invaders and predation.

The aim of this study is to test the invasion of mature and early stage complex biofilms by various concentrations of an allochthonous microbial strain, Aquabacterium sp., and the putative effects on the autochthonous biofilm community structure. A mature biofilm was developed on coupons attached to stainless rings inserted into two bubble columns reactors (5 L) which were operated in continuous mode for 35 days with a fixed hydraulic retention time of 65 minutes. After 15 days of operation, additional clean coupons were inserted as virgin surfaces for the development of early stage biofilm. Simultaneously, a suspension of Aquabacterium sp. (500 ml) was injected to one of the two reactors. The second reactor was used as a control without the addition of an invading population. The experiment was done twice using two concentrations of Aquabacterium sp. (OD = 0.04 and OD = 0.5) corresponding to the injection of a total number of cells equal to 1.6 x 10 10 cells and 2 x 10 11 , respectively. The capacity of Aquabacterium sp. to attach and remain in the biofilm was then monitored by quantitative PCR using primers targeting the 16S rRNA gene. In the two experiments, Aquabacterium sp. was detected for 20 days in both mature and early stage biofilms.

However, the number of invaders decreased sharply over time showing that the presence of Aquabacterium sp. in the biofilm was only transient while it was displaced from the biofilm or taken up by predators. The overall microbial community structure of the biofilm was not significantly affected by the addition of Aquabacterium sp., as similar PCR-SSCP profiles were observed before and after the addition of the invaders, and in comparison with the control reactor.

In conclusion, this study suggests that the number of invaders does not influence the colonization success. Also, the competition for space and nutrients of the highly diverse biofilm, even at an early stage, appears to limit the invasion of Aquabacterium sp..


text:
Mark Ronald

Mark R Bakker
email: mark.bakker@bordeaux.inra.fr

Frida F Andreasson

Anne Gallet-Budynek

Laurent Augusto

Maya Gonzalez

Comparison of ingrowth bags and ingrowth meshes in root studies: 3 years of data on Pinus pinaster and its understory

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

In this study, we applied flexible mesh material (6 mm mesh size) in Pinus pinaster production forests in southwestern France, featuring the following 5 dominant understory species: Cytisus scoparius, Calluna vulgaris, Erica cinerea, Pteridium aquilinium and Molinia caerulea. Four stands for each combination of dominant understory and Pinus were investigated throughout the study. The mesh material was either applied as bags (8 cm diameter, 15 cm deep, filled with soil from each site, topped with a litter lid) or as 50 cm long meshes (put with spades down to 15 cm in the soil, topped with litter). Harvests were carried out after 9, 24 and 36 months. For each sample roots were separated according to species, diameter class ((<0.5, 0.5-1, 1-2, 2-5, 5-10, 10-20 and 20-50 mm) and vitality (live or dead). Measured or derived root parameters considered include number of roots (mesh only), fine root biomass, fine root length, fine root density, specific root length, branching (number of apices per m of root length, for Pinus only), live fraction and for fine roots percentage of roots in a given diameter class (relative to all roots <2 mm). In order to compute these parameters for the meshes we considered a hypothetical volume of 2.5 cm on either side of the mesh times 50 cm length and 15 cm height. We expected i) that the ingrowth mesh method would be more suitable in monitoring growth (i.e. production and turnover) of coarser root diameters as a larger mesh surface was available for roots to grow through relative to the bags. Furher, we hoped ii) that meshes would cost less time for root extraction.

Results show for most understory -Pinus combinations a higher fine root biomass for understory species than for Pinus (with the exception of Cytisus), but patterns for fine root biomass over time (9 to 36 months) were similar for understory and pine: increase from 9 to 24 months, then a decrease. Meanwhile, between 24 and 36 months the live fraction decreased (between 90 and 100 % after 24 resp. 9 months, down to 40-60% after 36 months). Total root biomass (live + dead roots) present in both bags and meshes was actually higher after 36 months. Patterns for fine root length and fine root length density were similar to the pattern for fine root biomass. When comparing bags with meshes there seems to be less biomass growing into meshes than into bags for the finest root class (<0.5 mm in diameter). But when considering all fine roots (<2 mm) this is not evident, suggesting that more roots of the coarser fine root classes (0.5-1.0 and 1-2 mm) classes dominate in the meshes. This might point to some delay of soil exploitation of the mesh zone by roots (fewer very fine roots, larger proportion of less fine roots). Specific root lengths, indeed, were rather similar for pine roots in bags and meshes for the <0.5 mm class, but lower in meshes for the <2mm class than in bags. Presumably, the disturbance in mesh zones (upon installation) is higher than for bags: e.g. small roots (2-5, 5-10 or sometimes bigger roots) were found damaged on the outside of the mesh zone, giving rise to many reiterated roots of smaller diameter (1-2, 2-5 mm). This would suggest some bias to the numbers (and properties) of roots of the coarser diameters.

The overall conclusions are: 1. Ingrowth bags and meshes give roughly comparable results 2. Observed differences may be size related (larger volume for colonization, more disturbance potentially). In particular, the method did not, in our case, yield enough exploitable results for small to coarse roots (2 to 50 mm in diameter) and therefore, we cannot conclude that ingrowth meshes are clearly a better method for studying small and coarse roots. 3. Handling ingrowth meshes did not cost less time than handling ingrowth bags in our study. 4. We suggest using smaller mesh surfaces (20 cm?) and of more rigid material to optimize the mesh method as an alternative to ingrowth bags.


text:
est destinée au dépôt

  Performance of a model to predict the flowering date of apricot in three different regions of South France Lucia Andreini, Patrick P. Bertuzzi, Jean Marc Audergon, Sylvain Satger, Marie Elise Liennard, Raffaella Viti To cite this version: Lucia Andreini, Patrick P. Bertuzzi, Jean Marc Audergon, Sylvain Satger, Marie Elise Liennard, et al.. Performance of a model to predict the flowering date of apricot in three different regions of South France. 15. International Symposium, Jun 2011, Yerevan, Armenia. hal-02749445 Comment citer ce document : Andreini, L., Bertuzzi, P., Audergon, J. M., Satger, S., Liennard, M.E., Viti, R. (2011). Performance of a model to predict the flowering date of apricot in three different regions of South France. In: Apricot breeding and culture (p. 1 p.). Presented at 15. International Symposium, Yerevan, ARM (2011-06-20 -2011-06-24).