Julien Delange

Jérôme Hugues

Laurent Pautet

Bechir Zalila

Code Generation Strategies from AADL Architectural Descriptions Targeting the High Integrity Domain

Keywords: AADL, code generation, high integrity

Distributed Real-time Embedded (DRE) systems are increasingly used in critical domains such as avionics, vehicle and industrial control as well as in medical systems. They must be designed carefully and have to provide safety properties because a failure could mean loss of life. For these reasons, it is recommended to automatically generate a significant part of the code from the models describing the critical aspects. In our approach, we automatically generate two kinds of code from architectural models. The first one plugs the user functional code in the middleware, the second one provides a significant part of the middleware functions. Both rely on a hand coded written middleware that provides the minimal facilities to plug the generated code and to resolve portability issues. In this paper, we present our code generator and the middleware designed to generate High Integrity (HI) systems. We demonstrate via several use-cases how we succeeded in meeting the requirements of DRE systems (small memory footprint, no dead-code, etc...).

Introduction

Developing High Integrity (HI) systems is very difficult compared to classical ones as they are used in safety-critical domains such as space or avionics. These systems have to conform to strong requirements (small memory footprint, limited computation capacity) and standards.

Manually writing HI applications appears to be very tedious for the developer. It is also very difficult to comply with standards and requirements. It is preferable to automatically generate a large part of the code from analyzable models. Thus, the code generation process avoids all programming errors introduced by manual coding and ensures that it follows the properties included in the model. In addition, using model transformation, this process produces a verifiable model (e.g.: Petri Net) from the application model. It is simpler and safer than producing this model from source code. AADL, which stands for "Architecture Analysis and Design Language" [START_REF]SAE Aerospace. Architecture Analysis & Design Language[END_REF] is an architecture description language that allows the modelling of distributed, real-time embedded applications. AADL was first introduced to model the hardware and software architectures in the avionics domain, but was later extended to the general DRE (distributed real-time embedded) domain. This pedigree results in a language that is more amenable to static analysis and verification than other more general purpose modelling languages.

Our past work led us to the design of a Ada Ravenscar code generator [START_REF] Zalila | Generating Distributed High Integrity Applications from their Architectural Description[END_REF] from AADL models. The Ravenscar Profile [START_REF] Dobbing | Guide for the use of the Ada Ravenscar Profile in high integrity systems[END_REF] is a subset of rules and coding guidelines for Ada that ensure certain properties including static schedulability analyzability and the absence of deadlock. Generation of Ravenscar compliant Ada code ensures that the generated code provides these properties. However, Ada needs a specific runtime and this may reduce the range of potential executive platforms. On the contrary, the C language can be used on more platforms than Ada. However, the C language does not provide any static analysis method at compile time such as Ravenscar, so we have to create it by hand.

The process of producing a working application from an AADL model is divided into two main parts: a code generator and a minimal middleware. The code generator automatically produces C code from AADL models. The generated code relies on a minimal middleware that provides all the services it needs by the generated code. The middleware is considered as minimal because it only contains the functions requested by the application. Moreover, a large part of the middleware is automatically generated from the model, whereas another part is statically written. In our work, we focus on embedded systems, so we designed the middleware to be compliant with the requirements of such high integrity and embedded systems (small memory footprint, etc...).

In the remainder of this paper, we present the AADL language, the Ravenscar profile and give an overview of the code generation process. We explain the internals of the code generation process. Then, we present the minimal middleware we created to use the generated code: PolyORB-HI-C [START_REF] Delange | PolyORB-HI-C User Guide[END_REF]. We present its design and architecture. We give three use cases and the platforms used to perform our tests. Finally, we conclude and give some ideas for future work.

Context

In this section, we give an overview of AADL [START_REF]SAE Aerospace. Architecture Analysis & Design Language[END_REF][START_REF] Peter | The Architecture Analysis & Design Language (AADL) : An Introduction[END_REF], the language used to model critical systems. Then, we present the Ravenscar profile for Ada and what it implies for the code we generate. Finally, we describe the code generation process.

2.1 Overview of AADL AADL has been designed by the SAE (Society of Automotive Engineers). This language has been created to model the architecture of systems. It allows the description of both software and hardware parts of a system and focuses on the definition of clear block interfaces and separate implementations from these interfaces. Models can be expressed using a graphical or textual interface.

The standard property set of the language and the possibility to add new ones offers a way to model low-level aspects of the system and defines the specific behavior of each component. The finetuning of the model and the code-reuse ability constitute great advantages for choosing this modelling language.

AADL defines several components, each of them models a hardware or software entity.

Hardware components are

• Processor: models the processor of the system and the underlying executive. In other words, this component represents the operating system and the architecture of the system. For a standard computer, we declare a processor component and add properties to tell that it represents an x86 platform with a Native operating system such as Linux or Windows. • Memory: models any memory in the system, from RAM to ROM, or hard drives. This component typically represents a function or a procedure in a language. An execution unit (such as thread) can declare call section to invoke subprograms. • Data: models a type manipulated by an entity of the system. For example, it can be used to describe the type of the arguments of a subprogram or any variable declared in an execution unit (such as thread).

A special component (system) aggregates all the components of the system.

Components can contain subcomponents, in order to describe the hierarchy of the system. For example, a process component can contain several thread components. AADL contains a set of properties, which can be extended by the user. Properties are applied to components to model their characteristics and behaviors (such as the period of a thread, the size of the stack for a thread, etc...). AADL components can declare features, which are their interface to communicate with other components (for example, the parameters of a function are considered as features for an AADL subprogram). In addition, the connections clause of each component declares its relation with other entities (for example, a connection between the features of a thread and the ones of a subprogram means that the variables of the thread are used as arguments in a function-call). The features and connections section are used to model the communications between all nodes of a distributed system.

The Ravenscar Profile

The runtime of the Ada programming language provides extensive tasking capabilities. However, some of them are not suitable for safety-critical real time systems. Rendez-vous, multiple entries in protected objects and select statements render execution time analysis very complex. The Ravenscar Profile [START_REF] Dobbing | Guide for the use of the Ada Ravenscar Profile in high integrity systems[END_REF] is an effort to define a subset of Ada for use in High Integrity systems; the major restrictions therein are detailed below.

• Static tasking stipulates that the task-set is statically defined, there is no task terminations or abort statements and no dynamic priorities • Static synchronization model enforces nonhierarchical protected objects, a static set of protected objects, no select statements and no entries on tasks • Deterministic memory usage states that there be no implicit heap allocation • Deterministic execution stipulates that there is a maximum of one entry per protected object, the queue length of said entry be one, there be no requeue statements, no asynchronous control of tasks and delays be absolute • Runtime configuration states that task dispatching be FIFO_Within_Priorities, the priority ceiling protocol [START_REF] Lui Sha | IEEE Transactions on Computers[END_REF] be used for protected object access and that there be no suspendible code in a protected object procedure, function or entry Only periodic and sporadic tasks are allowed. Periodic tasks are dispatched at regular time intervals (their period). Sporadic tasks are dispatched as a result of events, but with a specified minimal inter-arrival time between events. The behavior in case of violation of this rule is implementation-dependant.

When using the Ravenscar profile in Ada source code, the compiler checks each statement. With the C language, we cannot check the behavior of the code at compile time. On the contrary, the code generation patterns create code that provides all the requirements of the Ravencar profile. Therefore, the C code generation process checks the behavior only one time (code generation), whereas the Ada code generation checks it twice (code generation and compilation). The steps for building a distributed application from AADL models are illustrated in figure 1. The developer provides his architectural model and his own behavior code. Then, the code generator uses the model to automatically generate code (step 1 on the figure). The code generator knows the API of the minimal middleware so it uses it in the generated code. Consequently, it uses services provided by the middleware and statically allocates all the resources needed by the system. Then, the generated code is compiled with the minimal middleware and the code provided by the user (step 2). In this step, the middleware uses the resources allocated in the generated code to provide its services.

Advantages of code generation process

Writing a distributed application, even using a middleware, remains a tedious task for the developer, who always encounters some problems to design, deploy or configure it. Models provide the deployment and configuration information, so the generated application doesn't need to be configured by the developer. The deployment of the generated applications is also automatically performed. While automatic code generation avoids all programming errors in the generated code, our approach automatically generate Ravenscar-like C code.

A traditional application often embeds some dead-code and has a memory overhead, due to many reasons (use of externals libraries, etc...). If these properties are not significant for most applications, they are important for embedded platforms that have memory constraints. In the code generation process, the architectural model is used to allocate statically all the resources at the initialization (threads, buffers, etc...). We allocate only the resources needed by the system. Such a method ensures a minimal memory footprint. We use the information from the model to create all data structures used by our algorithms. In the middleware it is easy to bound the execution time of our algorithms. This helps us to compute the worst execution time.

Related work

Research on AADL is very intense, and many applications have been created to manipulate AADL models. The Topcased [START_REF]Toolkit in Open Source for Critical Applications & Systems (TOPCASED)[END_REF] project offers a way to model systems with AADL using a textual as well as graphical representation.

In addition, AADL models can be used to check properties of the system. The Cheddar tool [START_REF] Singhoff | Cheddar : a flexible real time scheduling framework[END_REF] can prove the system's schedulability. To make this possible, one adds some properties on the components to describe their timing constraints (deadline, scheduling algorithm, mutexes ceilings, etc...). Then, Cheddar analyzes the schedulability and tells its feasibility.

Code generation process from models is a topic already developed. Many code generation techniques have been developed. Most of them use UML models [START_REF] Muenchaisri | Design of Rules for Transforming UML Sequence Diagrams into Java code[END_REF]. However, these methods are used to help the user to write his code and do not fit with the requirements of HI systems. Other methods focus on the HI domain [START_REF] Bordin | Automated Model-Based Generation of Ravenscar-Compliant Source Code[END_REF], but always use UML models and may introduce a memory overhead.

On the contrary, the originality of the present approach resides in the possibility of automatically generating a Ravenscar-compliant application written in C with a reduced memory overhead.

Automatic code generation

This section details the code generation process. It presents the code generation patterns used to transform AADL models into C code. We explain what part of code of the middleware we generate and how we can generate Ravenscar-compliant code. The internal structure of the code generator is also described.

Internals of our code generator

For each component of the model, we apply patterns that translate the AADL declaration into C code. For example, a thread component is mapped into a thread in the system. Consequently, when we find this kind of component, we generate a function call to create the thread and define a function for its execution. If the mapping of the thread component is easy to understand, the mapping of other components is more complex. Moreover, we have to be compliant with the Ravenscar profile, so our patterns must create code that follows the Ravenscar restrictions. All the code generation patterns defined in our code generator are explained in this section.

We designed a tool for manipulating AADL models: Ocarina [START_REF] Vergnaud | Ocarina documentation[END_REF]. It is used to manipulate models and have many features: semantic analysis of AADL models, code generation for the PolyORB middleware [START_REF] Hugues | A Factory To Design and Build Tailorable and Verifiable Middleware[END_REF], graphic model representation from a textual one, etc... It contains the entire infrastructure to manipulate AADL models and describe other languages (as target languages for C code generation). It was natural for us to extend this tool and implement our code generator as a new feature. We use the existing code to read and manipulate AADL models and implement our codegeneration patterns and code writing method. In the following paragraphs, we explain the internal work of Ocarina and the steps of the code generation.

Our code generation process uses at least two syntaxic trees: one for the modelling language (in our case, AADL), and another for the target language (Ada, C, etc...). The structure of each tree is described and we automatically generate functions to create and manipulate the tree. This architecture eases the creation of new syntaxic trees and the extension of our tool to new languages.

The code generation process is divided into four steps:

1. The parser analyzes the model. This first pass on the model creates a syntaxic tree, which contains all the declarations of the model. When parsing the model, we check that it is well formed. 2. We create an instance-tree, based on the syntaxic tree. This tree has one root system component with all its subcomponents. It precisely describes the model with its component hierarchy. Creating this tree is very important, because the model is well organised and unused components are not included in the instance-tree. 3. We traverse the instance tree and apply patterns on components to create the syntaxic-tree of the target language. For the C code generation, the result of this step is a tree with all generated C declarations. 4. The generated files are printed and we generate Makefiles to compile the code with the minimal middleware. At this step, the code shall be fully functional and the user can directly compile it.

Code generation patterns

The code generation patterns are very important, they automatically generate the code in the target language from the components of the model. For each component in the model, a pattern is applied and creates code in the syntaxic tree of the target language. The code-generation patterns are summarized in table 1.

For a thread component we generate statements that create the thread at initialization time and define a macro that describes the number of threads in the local node. These declarations ensure that the threads are created at initialization time, and that we allocate a fixed amount of threads. No other resources are allocated.

For each subprogram component, we generate a function that calls user-defined routines or generated ones.

For data component, we map it to a predefined type (such as integer, float, etc) according to its properties. However, data components could have subprograms as features (as the data component in listing 1). These subprograms get access to the data to read or write it. For these reasons, such data must be protected from concurrent access. We map such component to a structure with all its subcomponents and we add a unique identifier to this structure (the pos_impl structure in listing 2). Then, this identifier is used to lock or unlock the data before we read or write it (see the implementation of the functions in listing 2). The name of the structure is derived from the name of the component. To generate a fully working distributed system, we had to consider the features of each thread and analyse communications between the entities. For each thread that may communicate, we create a unique identifier in order to identify threads on each node. Information about the location of each node (IP address, port) is added in the code so the system automatically initializes connections between nodes.

The processor component models the architecture and the operating system. So, we use it to solve the portability problem. In our case, we defined a property set for all supported platforms and operating systems. We add the property value of the processor component in the Makefile used to compile each node. This value is used to choose the cross-compilation tools.

Middleware designed for the generated code

The previous section presents the code generation internals and its patterns to translate AADL models into C code. The generated code contains the resources used by the application and defines the functions used by each thread. However, the code needs to rely on services to use the operating system primitives. A service provides functionalities to execute the program: communications with other nodes, facilities to create and schedule tasks, etc... This is the purpose of the middleware: it manages the resources allocated in the generated code and calls the operating system's services. In this section, we describe the services provided by a traditional middleware and explain why we need to define a new middleware that is more compliant with high integrity system. Then, we present the minimal middleware we design, detail its services, its architecture and its compliance with commonly used operating systems.

Canonical middleware architecture

Our past research led us to design PolyORB [START_REF] Hugues | A framework for DRE middleware, an application to DDS[END_REF], a schizophrenic middleware. It separates concerns between distribution model, API, communication protocols, and their implementation by refining the definition and role of personalities. The schizophrenic architecture consists of three layers: application-level personalities (adaptation layer between application components and middleware through a dedicated API) and protocollevel personalities (handles the mapping of personality-neutral requests onto messages exchanged using a chosen communication network and protocol) built around a neutral core. The neutral core layer enables the selection of any combination of application and/or protocol personalities. Several personalities can be collocated and cooperate in a given middleware instance, leading to its schizophrenic nature. The neutral core defines generic services used by application and protocollevel personalities. We also focus on it because it contains fundamental services for a middleware. The µBroker is the core component that provides support for interaction between the other canonical services :

1. Addressing service looks up objects on servers.

This service is used when a client ask the server for an access to an object 2. Binding factory service establishes communications with the server using one communication channel 3. Representation service gives a common representation for the data (e.g: CDR). This solves the problem of endianness. 4. Protocol service provides several protocols to communicate with other nodes. 5. Transport service provides several transport layer to send and receive the data 6. Activation service ensures an entity can execute the request. 7. Execution service gives the resources to execute the request. 8. Typing service manages the typing system in the application (sophisticated when it comes to the CORBA any mechanism for instance) 9. Interaction service manages the liaisons between connected entities in the application, However, such middleware deals with objectoriented methods and is not compliant with HI systems. Their configuration is performed at run-time (creating and managing POA), their resources are dynamically allocated (buffers, threads, etc...) and it is difficult to evaluate the worst case execution time of some functionalities. Such a design introduces temporal indeterminism and it remains hard to analyze the behavior of such system.

The middleware we wrote (PolyORB-HI-C [START_REF] Delange | PolyORB-HI-C User Guide[END_REF]) matches a small memory footprint and ensures predictable properties. The use of AADL models eases the configuration as it provides the user requirements and the deployment information. Consequently, the configuration of the middleware is made at compile time and resources are statically allocated. It ensures that no dynamic configuration or allocation is performed at runtime such as in traditional object-oriented middleware. Moreover, AADL models precisely describe the communications between the node of the distributed system. Using this information, we can automatically establish communications between the nodes that may communicate at initialization time. It prevents dynamic creation of connections to other nodes. According to this static configuration, some services included in PolyORB become useless. For example, the addressing service and the binding factory are no longer used because we automatically add code to locate nodes and establish communications.

A large part of the middleware is automatically generated whereas another is statically written. The generated part of the middleware contains functionalities that are specific to the model. The statically written part defines generic functionalities used by all applications Moreover, the model provides the architecture of the system so we can select the services needed by the generated code (e.g.: if the model defines a single process, we don't include services that enable communication). Such method reduces the introduction of memory overhead and dead-code.

Many research projects designed middleware [START_REF] Schmidt | Architectures and patterns for developing highperformance, real-time orb endsystems[END_REF] for real-time and high-integrity embedded software and use other approaches than the one described in this paper. While projects tend to provides more and more features in their middleware, it is important to keep in mind that we just try to provide few services, and include only those needed by the generated code.

In the next subsection, we present our middleware PolyORB-HI-C. We describe its architecture and services according to their equivalence with the PolyORB ones. In addition, we explain what part of the middleware is automatically generated and what part we wrote by hand. We also explain how it fits with the requirements of the Ravenscar profile. Finally, we describe how we design it to be compliant with many systems.

Architecture of PolyORB-HI-C

The services provided by the middleware are listed below:

1. Execution service creates threads and provides scheduling functionalities. 2. Representation service configures the types available on the target platform and provides a common representation of the types in the distributed system 3. Transport service provides functionalities to send and receive data from other nodes 4. Protocol service provides protocols to exchange data between the nodes of the distributed system

The execution service is used to create and manage threads on a local node. This service is quite different from the one in PolyORB : threads do not execute requests on an object, they execute an infinite loop with the code provided by the user. The execution service handles periodic and sporadic tasks as defined in the Ravenscar profile. It provides all the functions to be compliant with the strong timing requirements of HI systems. The task dispatching policy by the middleware is FIFO_Within_Priorities. This policy helps us analyze schedulability.

The representation service configures the middleware to choose the types on the target platform (set data representation according to the types available on the target such as 8, 16 or 32 bits integer, float, etc…) and provides functionalities to marshal/unmarshal data into a message. This service is the same as the one defined in PolyORB, we just add some functionalities such as type configuration and data protection. This service is partly generated (the code to marshal requests is automatically generated), whereas another part is statically written.

Transport service enables communication channels between the nodes of the distributed system. This service is equivalent to the one in PolyORB. Several transport layers can be implemented in the middleware so the user can choose it. At this time, only BSD sockets are implemented. Most of the code of the transport service is statically written.

Protocol service provides functionalities to structure the messages exchanged in the distributed system. The service is equivalent to the one of PolyORB. As for transport service, several protocols can be implemented. At this time, we implement two protocols: IIOP (Internet Inter-ORB Protocol, the protocol of CORBA [START_REF]Common object request broker architecture : Core specification[END_REF]) and another protocol that directly serialize the data. The resources used by this service are automatically generated whereas the code remains statically written.

Figure 2 shows the architecture of the middleware and the organisation of the source files of each service. The execution service uses the representation service to express a representation of the time. The representation service is used by the transport and protocol services to get the types available on the platform. Finally, the transport service uses the execution service to create a thread that listen for incoming messages from other nodes.

All the resources of the system are statically allocated at compile time, as is the deployment information. If the resources cannot be allocated at compile time (creation of threads, mutexes, etc...), we do it at initialization time. In each program, a function initializes all resources before the system starts. This ensures that we don't make any dynamic allocation or configuration at runtime. All portability aspects are included in the middleware as well. This problem is solved in two steps. At configuration time, the middleware detects the endianness of the architecture and available types. It chooses its functions and the type management method according to the information it has on the platform. The second aspect is about compilation: choosing the right cross-compilation tools, using specific command-line options when compiling, etc... To solve this problem, we use the information about the execution platform provided in the generated Makefile for each node. The middleware then has a configuration of each compilation step for all execution platforms and adapts its behavior according to all these parameters. Moreover, we pay attention to the functions used in the middleware to get portable code. Most of the code uses POSIX standard, in order to be easily ported to other systems that support it. Also, we add an abstraction layer to the POSIX one in order to remain Ravenscar-compliant.

The code of the middleware must respect all constraints of the HI domain. The execution time of the algorithms used can be easily bounded and all resources are statically allocated at compile time or at initialization time. The size of each resource is defined with the information provided by the generated code. This ensures that we have a minimal footprint (no more memory is allocated), and no non-deterministic service is used at runtime (dynamic memory allocation, etc...).

Tests and benchmarks

This section gives an overview of the platforms we used and their specifications. Moreover, we present some benchmarks we carried out. They detail the memory footprint on each platform.

Platforms

We tested our examples on the following platforms:

1. Nokia N770: ARM architecture, 64 MB of RAM with a Linux-based operating system.

2. Nintendo DS: ARM architecture, 4 MB of RAM (2Mb for the operating system, 2MB for userland applications) with a port of Linux: DSLinux [START_REF] Dslinux | [END_REF].

3. Native system: x86 architecture with Linux operating system.

The Nokia N770 platform proves that our approach could be used for personal systems such as smartphone, PDA and other personal embedded systems. Such devices have a limited capacity of computation, but do not have hard memory constraints. On the contrary, the Nintendo DS has strong memory constraints. Only 2 MB of RAM are available for the execution of third-party programs, so it shows that our generated applications have a small memory footprint. The last architecture, called native may not seem to be as interesting as the others. On the contrary, this platform shows that the generated code works on a standard personal computer and helps us for debugging purposes.

Tests

During the design of the middleware, we designed some tests that use the code generator and the minimal middleware. We focus on three of them: RMA, Sunseeker and Flight Management [START_REF] Hamid | A Generative Approach to Building a Framework for Hard Real-Time Applications[END_REF]. All these use-cases are available on our website dedicated to AADL [START_REF] Vergnaud | Ocarina documentation[END_REF].

The RMA test creates two periodic tasks (T1 and T2) in one process with the following properties: 2 x Period(T1) = Period(T2). Each task prints a message to show when it is being run. This test shows the correctness of the scheduling.

The Sunseeker test was written by the Software Engineering Institute (SEI) of the Carnegie Mellon University (CMU) in order to test some AADL features and code generation patterns. It models a missile guidance example. It defines two periodic tasks. Each task receives data from the other, computes a value and sends it to the other task. This test introduces data exchange between distributed nodes so that the code related to distributed application is added in each program of the system.

The last test (Flight Management [START_REF] Hamid | A Generative Approach to Building a Framework for Hard Real-Time Applications[END_REF]) creates five tasks: three periodic tasks and two sporadic tasks. The communication graph between tasks is quite complex. All kinds of ports are used (event port, data port and event data port). This test shows the correct mapping of each port type to C and that communications with several ports works well.

Metrics

From these tests, we carried out some metrics on memory footprints. Table 2 shows the memory footprint of each test on each platform. All the binaries are compiled with GCC and are statically linked. In all cases, the size of the binary is less than one megabyte. The Nintendo DS uses a port of Linux (DSLinux [START_REF] Dslinux | [END_REF]), but uses a C-library designed for embedded system: µClibC. The binary created with this embedded-profiled C-library is smaller than the ones that use traditional C-library (such as the binaries compiled for the native platform).

Conclusions and Future Work

Using architectural models to automatically generate code is a good way to create code for high-integrity systems. Such a method avoids all errors traditionally introduced by manually produced code, it can also create code that provides safety properties. In our approach, the code generator implements the Ravenscar profile for C. The minimal middleware limits the memory overhead and is compiled only with the needed functions. A large part of the middleware (functions and resources) is automatically generated whereas a static part uses the resources and calls the services specific to the underling operating systems. The architecture of the middleware eases its port to other platforms.

If our code generator produces code that provides all the requirements of the Ravenscar profile, we can't ensure that the user-code does not break our safety rules. Besides, if the Ada compiler checks the compliance of the Ravenscar profile on the whole system, the C compiler doesn't perform any check. Consequently, even if the generated code is well formed, the user can break all the safety rules introduced in the system with his functions.

We can extend the current work in many ways. First, we can create other language generators in order to automatically produce a distributed system with several nodes that use different languages. At this time, our code generator, Ocarina, only supports Ada and C languages. Another way consists of adding some security and safety information to the model. Such information is used to automatically generate a safe and secure distributed system (data-flow analysis between nodes, encryption in data transfer, etc...). Research on architecture models will probably remain very intense in the next years, due to the needs to check and validate the system before its implementation.

Figure 1 :

 1 Figure 1 : Steps to create a distributed application from AADL model

Listing 2 :

 2 void pos_impl_update (pos_impl* v) { lock(v->protected_id); update(&(v->field)); unlock(v->protected_id); } void pos_impl_read (pos_impl* v) { lock(v->protected_id); read(&(v->field)); unlock(v->protected_id); } Generated code from a data component with subprograms as features

Figure 2 :

 2 Figure 2: Architecture of the minimal middleware

•

  Bus: models different kinds of networks, wires, etc... • Device: models any other device in the system (sensor, motion detector, etc...).

	Software components are :
	• Process: models a single address space.
	The notion expressed in this component is
	similar the UNIX process. As in operating
	systems, a process component can contain
	thread components.

• Thread: models lightweight process. This component can be understood as a POSIX thread. It can contain subprogram calls.

• Subprogram: models a flow of instructions.

Table 1 :

 1 Code generation patterns

	data POS_Internal_Type
	properties
	ARAO::Data_Type => Integer;
	end POS_Internal_Type;
	data POS
	features
	Update : subprogram Update;
	Read	: subprogram Read;
	end POS;
	data implementation POS.Impl
	subcomponents
	Field : data POS_Internal_Type;
	end POS.Impl;
	Listing 1: AADL model of a type that uses
		subprograms as features
	AADL Component	Code-generation pattern
	System	Create a directory which contains each process
	Process	Create a directory which contains the source code.
			• Instantiate the thread at
			initialization time
			• Create function executed by
			the thread after the initialization
			• Define a macro to tell how
	Thread	many threads are created on the
			local node
			• Create identifiers for its ports
			• Create an entity identifier to
			communicate with other threads
			in the whole distributed system
			Create a function that call other
	Subprogram	mapped subprograms or user-
			defined functions.
			• Map the data to existing
			predefined types
	Data		• Declare a protected identifier if
			the data must be protected from
			concurent access
			Put the right execution platform
			(architecture and operating
	Processor	system) in the Makefile in order
			to choose the right cross-
			compilation tools.

Table 2 :

 2 Memory footprint for each test

		RMA	Sunseeker Flight management
	Nokia N770 589 KB 645 KB	638 KB
	Nintendo DS 144 KB 204 KB	209 KB
	Native	471 KB 527 KB	532 KB

Acknowledgment: This work is partly funded by the RNTL Flex-eWare project.


Teddy Parra

Olivier Beyssac

Christian Chopin

Florent Moreau

Dr Franck Bourdelle
email: franck.bourdelle@u-cergy.fr

Ultrathin section preparation of phyllosilicates by Focused Ion Beam milling for quantitative analysis by TEM-EDX

Keywords: Focused Ion Beam (FIB), sample preparation, phyllosilicate, analytical TEM, analytical protocol

come

Introduction

Chlorite and mica are two clay minerals, the composition of which is commonly used in chemical thermobarometry (e.g. [START_REF] Battaglia | Variations in the chemical composition of illite from five geothermal fields: a possible geothermometer[END_REF][START_REF] Cathelineau | Cation site occupency in chlorites and illites as a function of temperature[END_REF][START_REF] Cathelineau | A chlorite solid solution geothermometer. The Los Azufres (Mexico) geothermal system[END_REF][START_REF] Dubacq | Dehydration of dioctahedral aluminous phyllosilicates: thermodynamic modelling and implications for thermobarometric estimates[END_REF][START_REF] Hillier | Octahedral Occupancy and the Chemical-Composition of Diagenetic (Low-Temperature) Chlorites[END_REF][START_REF] Jahren | Diagenetic Illite-Chlorite Assemblages in Arenites .1. Chemical Evolution[END_REF][START_REF] Vidal | Exhumation paths of high-pressure metapelites obtained from local equilibria for chlorite-phengite assemblages[END_REF]. These geothermobarometers classically rely on chemical data obtained by Electron Microprobe (EMP) Analysis, based on Wavelength Dispersive X-ray Spectroscopy (WDX) or on Energy Dispersive X-ray Spectroscopy (EDX). In both cases, quantitative measurements need to be calibrated with standards of known chemistry to be accurate and reliable; on the other hand, this technique allows for in situ analysis, thus preserving the microtexture and the contacts between mineral phases when using petrographic thin sections. Both the spatial and analytical precision have made EMP the most popular technique for the quantitative analysis of minerals, in particular clay minerals.

However, in low-temperature (T < 300°C), lowpressure metamorphic rocks (P < 3 kbar), the submicrometer size of mineral grains leads in most cases to 'contaminated', i.e. mixed analyses. In such rocks, the use of thermobarometers, all based on local chemical equilibrium (e.g. [START_REF] Vidal | Exhumation paths of high-pressure metapelites obtained from local equilibria for chlorite-phengite assemblages[END_REF] between mineral phases, therefore requires higher spatial resolution. Transmission Electron Microscopy (TEM) complemented with an EDX detector offers such a resolution, but requires ultrathin sections transparent to electrons if one wants to preserve the textural relationships between minerals down to the nanoscale. Conventionally, thin sections of mineralogical samples for TEM studies have long been prepared using ion-milling. However, a major disadvantage of this method is the poor precision when positioning the slice plane and therefore the loose control on the location of the section with respect to the mineral microtexture. The focused ion beam milling (FIB) appears as an alternative technique [START_REF] Wirth | Focused Ion Beam (FIB): A novel technology for advanced application of micro-and nanoanalysis in geosciences and applied mineralogy[END_REF], because it allows for targeting the area that needs to be extracted with a very high-precision (like a SEM) and for cutting heterogeneous samples (e.g. [START_REF] Benzerara | TEM study of a silicate-carbonate-microbe interface prepared by focused ion beam milling[END_REF][START_REF] Heaney | Focused ion beam milling: A method of site-specific sample extraction for microanalysis of Earth and planetary materials[END_REF][START_REF] Obst | TEM-specimen preparation of cell/mineral interfaces by Focused Ion Beam milling[END_REF]. Unfortunately, the FIB technique may involve many artefacts such as structural or chemical damages due to the heavy Ga ions used for the milling. Additionally, a FIB-section is often thicker than the ones prepared by the conventional ionmilling method and this may induce thickness effects during the quantitative chemical analysis.

In the present study, the suitability of FIB-milling to prepare ultrathin sections of phyllosilicates for analytical TEM investigations is evaluated. In that respect, a particular attention has been paid to identify and quantify the artefacts due to the FIB-milling process. Then, the protocol for TEM-EDX quantitative analysis of such sections is described with a particular emphasis on the corrections required by the FIB sample thickness. As EMP analysis is the reference tool for thermobarometry, we finally validate the use of FIB-milling and the TEM-EDX analytical protocol by comparison against EMP analyses on the same crystals of phyllosilicates.

Materials and methods

Samples and chemistry calculation

Two sets of samples were selected to cover a large range of P-T conditions and of types/grain sizes of phyllosilicates. The first set is coming from the Glarus Alps in the central Alps (Switzerland) which is a reference zone for low-grade metamorphism. These samples (noted GL07) are described in [START_REF] Lahfid | Evolution of the Raman spectrum of carbonaceous material in low-grade metasediments of the Glarus Alps (Switzerland)[END_REF] and contain small-size particles of illites and chlorites. The second set of sample is from the Tinos Island (Greece, noted TI08), which is a classical example for high-grade metamorphism in the blueschist to eclogite facies (Parra et al., 2002) with coarse-grained chlorite and mica crystals, allowing for a comparison of analyses obtained with both the TEM-EDX and EMP. In each sample two FIBsections were prepared which yields a total of 32 sections (14 samples from Glarus and 2 from Tinos).

In this study, the structural formulae were calculated on the basis of 11 and 14 oxygens for mica and chlorite, respectively, assuming all Fe as FeO. All K, Na and Ca were assigned to interlayers, and are called "volatile elements" (see below). Element contents are expressed in atoms per formula unit (apfu). The structural formulae were filtered using the criteria detailed by Parra et al. (2002), [START_REF] Vidal | Exhumation paths of high-pressure metapelites obtained from local equilibria for chlorite-phengite assemblages[END_REF] and [START_REF] Vidal | A thermodynamic model for Fe-Mg aluminous chlorite using data from phase equilibrium experiments and natural pelitic assemblages in the 100 degrees to 600 degrees C, 1 to 25 kb range[END_REF], in order to exclude possible mixed analyses, i.e. those affected by the contribution of an adjacent mineral.

Preparation of TEM samples by FIB

The FIB-milling was performed on conventional polished thin sections after a careful microtextural study with optical microscopy and SEM in order to locate the appropriate mica-chlorite contact zones. The procedure chosen for FIB-milling is similar to the milling procedure described and illustrated in detail in [START_REF] Heaney | Focused ion beam milling: A method of site-specific sample extraction for microanalysis of Earth and planetary materials[END_REF].

In the current study a FEI 200 instrument, belonging to CP2M (University of Aix-Marseille, France) working with a liquid Ga source at an acceleration voltage of 30 kV was used. The specimens were first sputter-coated with a platinum layer, approximately 15-20 nm thick. To protect the upper side of the TEM lamella from the milling Ga-ions an additional, thick layer (1 μm) of organometallic Pt, called "Pt-strap" in [START_REF] Heaney | Focused ion beam milling: A method of site-specific sample extraction for microanalysis of Earth and planetary materials[END_REF], was deposited ontop of the targeted area prior to the milling. In our study, trenches were first milled on each side of the strap with high current. For the following reduction of thickness of the remaining lamella, the current was reduced stepwise (5000 -1000 -300 -100 -30 pA). When milling of the overall shape of the section was finished, the side walls of the lamella were cleaned at a milling current of only 30 pA to preserve the clay matter. Using this milling technique a lamella thickness of approximately 150-200 nm could be expected at the upper end of the section. The base of the lamella was undercut after tilting the sample. The lamella was then removed from the polished-section and placed on a TEM grid using a micromanipulator under an optical microscope.

Modelling of Ga ion beam damages to the thin section

Beam damages were evaluated using the Monte-Carlo simulation approach (cf. [START_REF] Obst | TEM-specimen preparation of cell/mineral interfaces by Focused Ion Beam milling[END_REF]. In such an approach, the trajectories and the collision cascades of Gaions were simulated for a beam incident angle of 1° from the vertical axis, as occurring during the last step of the milling procedure. The simulation was performed with the "Stopping and Range of Ions in Matter" (SRIM) code version 2008.04 by [START_REF] Ziegler | The stopping and range of ions in matter (SRIM -2008.04[END_REF].

TEM analyses

The FIB ultrathin sections were analyzed with a TEM-EDX JEOL 2100-F instrument at the materials characterization department of IFP Energies Nouvelles (Solaize, France), using a 200 kV voltage, a counting time of 60 s and a dead time lower than 15%. The current density was maintained at 1.3 pA/cm -2 . The sample tilt angle was 7°, and the total take-off angle is 32°. In these conditions, the spot size is defocused to 50 nm. The experimental EDX standardization consists in the determination of k-factors by the analysis of minerals of known chemistry (noted "standards"). The standards chosen are phyllosilicates (Table 1) in order to account for matrix effects, in particular the cation-loss effects that are included in the k-factor determination. They are all powders, prepared for the TEM by dropping a clay suspension solution onto a carbon-coated copper grid. Particle thickness is statistically less than 50 nm, allowing one to neglect the fluorescence and absorption effects. Standardization analyses were performed on areas where the layers were visible (i.e. with the beam within or close to the 00l crystalline plane), in order to account for the crystal orientation effects within the k-factor determination. For the natural standards, the chemistry was determined by EMP analysis. The synthetic minerals were obtained by the sol-gel method [START_REF] Hamilton | The preparation of silicate compositions by gelling method[END_REF]) and crystallized by hydrothermal method.

The TEM-EDX beam trajectory through the lamella was evaluated using a Monte-Carlo simulation approach. This simulation was performed with PENELOPE-2006 software [START_REF] Salvat | PENELOPE-2006: A code system for Monte-Carlo simulation of electron and photon transport[END_REF] et al., 1986). For paragonite, 3000 bars, 580°C and 78 days are the synthesis conditions. For chlorites TT15 and TT21, see details for synthesis in [START_REF] Parra | Experimental data on the Tschermak substitution in Fe-chlorite[END_REF].

EMP analyses

The EMP analyses were carried out on a CAMECA SX-100 instrument at the CAMPARIS service in Paris. The analytical conditions were 15 kV, 10 nA, a counting time of 10 s for the major elements (Si, Al, Mg, Fe, Ca) and 15 s for K and Na. Mineral standards used for calibration were albite (Na), diopside (Mg, Si, Ca), orthoclase (Al, K), garnet (Fe) and MnTiO3 (Mn, Ti).

Artefacts and damages by FIB-milling process

During the first part of the milling procedure, when the energy of the beam current is high, the ion beam severely impacts the fine structure of the matter but the platinum layer set on top of the FIB-section protects it, so that the damages are localized at the periphery of the area of interest [START_REF] Heaney | Focused ion beam milling: A method of site-specific sample extraction for microanalysis of Earth and planetary materials[END_REF]. However, several contaminations of the FIB-section are possible throughout the following steps of the process, like Ga 2+ deposition, amorphization and/or element redeposition [START_REF] Wirth | Focused Ion Beam (FIB): A novel technology for advanced application of micro-and nanoanalysis in geosciences and applied mineralogy[END_REF]. A careful attention was therefore systematically paid to the beam damages caused for low current, low incident angle conditions.

Amorphization and Ga 2+ beam damages

During the milling, Ga atoms are implanted on the surface of the FIB-section, constituting a nonhomogeneous Ga-layer [START_REF] Giannuzzi | Ion -Solid interactions[END_REF]. The Ga deposit depends on ion energy, angle of incidence, sample's ion species and targeted material. As a consequence, the incident high-energy Ga-ion beam may alter the structure of minerals by locally inducing an amorphization of the sample surface. The assessment of the damage impact was obtained by Monte-Carlo simulation [START_REF] Ziegler | The stopping and range of ions in matter (SRIM-2000)[END_REF][START_REF] Ziegler | The stopping and range of ions in matter (SRIM-2000)[END_REF]. This mathematical approach permits to simulate in three dimensions the penetration of the ions into the matter and the full cascades of energy loss. Figure 1 presents these simulations for 1000 Ga-ions accelerated at a voltage of respectively 30, 20 and 10 keV in clinochlore, Mg-sudoite and Mg-celadonite. The impact angle of the ion beam is fixed to 1°, as it is during the thinning of the thin section. The matter density is fixed to 2.7 g/cm 3 , which is an average density for the phyllosilicates. The simulation is two-dimensional, the ion beam entering in contact with the matter at the centre of the left side of the figure.

At 30 keV, which represents the worst case, the thickness of FIB-section damaged by the ion beam is almost 20 nm for all the tested minerals. In fact, clinochlore, Mg-sudoite and Mg-celadonite have similar chemistries, and the scale of ion beam damages is approximately the same: the Ga 2+ implantation is restricted to the first 10 nm, in both sides of the thin section, and the full cascades of energy loss affects 20-25 nm. Thus, even if a fraction of the ultrathin section may loose its original structure, it can be assumed that the bulk majority of the matter is not influenced by the milling, if the ultrathin section is not too thin. In other words, a thin section with a thickness of 200 nm is preserved to 80%. Similar results have been obtained by other authors for other materials, as [START_REF] Kim | Focused ion beam sample preparation of continuous fibre-reinforced ceramic composite specimens for transmission electron microscopy[END_REF] for Al2O3 and CaWO4. With the FIB used in this study, it is possible to decrease the beam intensity (5000 to 30 pA) but not the beam current voltage under 30 kV without deteriorating the quality of the working image, which is now possible with the dual-beam FIB systems. Thus, the impact of the beam on the studied clays thin section can be minimized using a lower beam acceleration voltage, with 20 and 15 nm affected on both side by the full cascade of energy loss for 20 and 10 keV respectively (Figure 1). There is a compromise to be found as the milling time is then longer, but the preserved section thickness is higher compared to the 30 keV case. Even if the numerical simulation represents only an approximation in the case of a crystalline structure, the TEM-observations of a crystalline structure (clay layers) in the ultrathin sections confirm that the majority of the section thickness is not amorphous. An optimization of the milling process (milling time, beam energy and final section thickness) enables to obtain thin section of the area of interest without significant beam damages (amorphization and Ga-ions implantation). In fact, the Ga-ions which are implanted on the surface of the FIB-sections constitute a non-homogeneous layer which can be minimized by using a lower-energy beam for the final thinning [START_REF] Giannuzzi | Ion -Solid interactions[END_REF]. Moreover, to make sure of the preservation of the crystalline structure in the different minerals, an observation of the layers was systematically carried out with the TEM. In any case, the presence of the Ga-atoms at the ultrathin section surface is not an issue for the TEManalysis as the spectral line of Ga does not disturb the quantification, since the Ga X-ray energy is significantly lower than Si, Mg, Fe, Al and K energies.

Redeposition effects

The redeposition of the pulverized matter (including Pt from the Pt strap) during the FIB milling is also a problem, because it may form a contamination layer over the surface of the FIB section [START_REF] Giannuzzi | Ion -Solid interactions[END_REF].

The Pt contamination can easily be excluded from the quantification, but the contamination from the sample itself must be considered and, in case of a significant redeposition, the corresponding analyses should be discarded. This artefact is difficult to quantify and there is no straightforward procedure, even if this phenomenon may be minimized by selecting appropriate milling parameters (low-current beam for the milling). In this study, the redeposition is estimated in a qualitative manner by analyzing a crystal near the platinum strap located on top of the ultrathin section where the crystal is supposed to be the less exposed to redeposition. If these analyses contain a high Pt content (i.e. when the Pt X-ray line is large enough to form a shoulder of the Si K line on the EDX spectrum, or when the PtO2 content exceeds 1 wt%), this indicates that redeposition (for all elements) was significant, and the corresponding analyses must be rejected.

Figure 1. Monte-Carlo simulation of 1000 Ga-ion trajectories (black) and the full cascades of energy loss (grey) in clinochlore, Mgsudoite and Mg-celadonite from left to right and for 10, 20 and 30 keV Ga-beam from bottom to top. Simulations were performed with the SRIM 2008.04 code [START_REF] Ziegler | The stopping and range of ions in matter (SRIM -2008.04[END_REF]. The Ga-beam hits the sample in the centre of the left side of the FIB section with an incident angle of 1° on the surface from upside down.

Identification and correction of the analytical artefacts specific to sample preparation

k-factors and quantitative corrections

The EDX analysis uses intensities of X-rays emitted by the matter submitted to an electron beam, which depends on the concentration of each element [START_REF] Goldstein | Quantitative Y-ray analysis[END_REF]. The intensity detected (element line intensity, dependent on number and energy of X-rays emitted) by the EDX detector and the chemical quantification are linked by many parameters which are in most cases not known, or not easily estimated. To avoid these difficulties, Cliff and Lorimer (1972) suggested a quantification of each element by comparing its concentration to an element considered as a reference: e) for j, the line's relative weight (p j,l e), the Coster-Kronig transition factor (TKC j,l e, absent for the K lines), the ionization cross section ( j e) at the electron's initial energy (E0), and as the detector efficiency ((E j,l e)).

2 1 2 , 2 2 1 , 1 1 2 , 2 2
The k-factors have to be estimated for each element relative to a reference element which has a k-factor set to 1.00. For that purpose, they suggested to use silicon or any other strong X-ray line. The k-factors are valid only if the sample thickness is less than 50 nm (Cliff andLorimer, 1972, 1975;Jacobs and Baborovska, 1972) so that fluorescence and absorption may be neglible. If the specimen is thick, absorption and fluorescence factors must be estimated in addition to the k-factors ratio to obtain a truly quantitative analysis. These absorption and fluorescence factors are included in the equation of the emitted intensity and thus allow correction of the detected intensity [START_REF] Goldstein | Quantitative Y-ray analysis[END_REF]. The absorption factor is:

                 

 

The fluorescence factor is: where re1 is the ratio of absorption coefficient after and before the absorption jump of the e element's j1 line,  j e(ρz) the ionization's density in-depth (Castaing's standardization) and  the X-ray take-off angle. It should be noted that the fluorescence depends on the mass absorption coefficient  j,l e and that both fluorescence and absorption factors depend on the thickness (z) and the density () of the sample. Figure 2 shows the relative importance of these corrections on quantitative analysis for a non-infinitely thin FIB section of chlorite. We observe that without corrections, the iron content is 2.07 apfu. After fluorescence and absorption corrections, this content is decreased by 0.1 apfu for a minimum thickness of 80 nm. We also note that sample density does not have a strong influence on the correction calculations, and has a negligible effect on the quantification results. As predicted, the correction for thickness modifies notably the chemical results between a FIB section of a negligible thickness (0 -50 nm) and a FIB section with a thickness of 300 nm. In that case, the iron content is decreasing from 2.07 to 1.77 apfu. This example illustrates the necessity, when the FIB section thickness exceeds 50 nm, to evaluate this thickness on the very same area where the analysis is done. This allows one to estimate accurately the effect of fluorescence and absorption.

      2 2 2 1 1 2 , 2 2 2 , 2 2 2 1 1 1 2 2 2 2 , 2 , 1 , 1 2 , 1 1 1 2 z E E sample e A A r
Figure 2. Influence of fluorescence and absorption corrections according to thickness and density on a chlorite analysis in a FIB section (GL07 26 B1). Density varies from 2.5 to 3. Thickness varies from 80 to 300 nm as usually observed in our FIB sections.

Ultrathin section thickness estimation

To estimate the thickness of the FIB sections, the simplest method consists in a physical measure between two dots made with the focused beam separated by a known angle. But this method needs a long time analysis, and therefore induces significant radiation damages to the ultrathin section. Moreover, to be precise, this method requires that both sides of the section are parallel which is not the case for FIB sections. Confronted to the same problem, [START_REF] Watanabe | The quantitative analysis of thin specimens: a review of progress from the Cliff-Lorimer to the new zeta-factor methods[END_REF] proposed an alternative method to quantify the chemistry with a modified k-factor (noted ) that does not depend on the analysis parameters. Altogether, the -factors method [START_REF] Watanabe | Absorption correction and thickness determination using the zeta factor in quantitative X-ray microanalysis[END_REF][START_REF] Watanabe | The new form of the ζfactor method for quantitative microanalysis in AEM-XEDS and its evaluation[END_REF]2006) allows one to determine the sample thickness simultaneously with the composition, by an iterative process, together with the absorption and fluorescence corrections. However, the -factors standardization needs accurate estimates of the thickness of the standards used for EDX probe calibration, it requires precise measurement of the beam current density during analysis and does not take into account the specific amorphization of phyllosilicates during analysis. In addition, the application of this protocol to phyllosilicates is very limited because the standards used by [START_REF] Watanabe | The quantitative analysis of thin specimens: a review of progress from the Cliff-Lorimer to the new zeta-factor methods[END_REF] are pure-element thin films, whereas phyllosilicates are multi-element oxide compounds with a highly anisotropic structure. Previously, [START_REF] Van Cappellen | Quantitative Transmission-X-Ray Microanalysis of Ionic Compounds[END_REF] proposed an analytic method of plane-parallel specimen which does not require thickness or X-ray take-off angle parameters, and which is based on the principle of electroneutrality of the specimen structure. In the following, we demonstrate the applicability to phyllosilicates of this simple iterative method to estimate the thickness of a FIB-section at each analysis point. The calculation of the thickness is easy and fast with a recent EDX software (JEOL Analysis software in this case) and does not require any additional destructive TEM-beam exposure of the ultrathin sections, as follows.

-First, it is necessary to determine experimentally the real oxygen k-factor during the calibration of the EDX probe. Indeed, the pre-unrecorded value, in Figure 3, is clearly overestimated when applied to phyllosilicates because of the contrasting crystallographic structure between the clays and the TEM manufacturers' standards. The oxygen k-factor determination can be made during the EDX standardization step, by the analysis of the standards and estimation of the k-factor according to the silicon (Si) reference.

-Second, as the density effects are negligible (in this study), we initially assume a density of 2.7 in accordance with the average density of phyllosilicates.

-The thickness is then calculated from the theoretical oxygen content of phyllosilicates per half unit-cell, based on the fact that (i) the oxygen k-factor is rather homogeneous (Figure 3), (ii) oxygen is theoretically the only element whose contents do not vary in phyllosilicate structures, and (iii) it does not intervene directly in the quantification of the other elements.

Since the oxygen content is also a function of thickness, we need an iterative procedure to reach the appropriate thickness that fits the ideal oxygen content. This iterative procedure consists in adjusting each standardized k-factor with the valid correction factors by incremental variations of the input thickness. Starting with the normalized composition roughly corrected (based on the ideal structure with O = 14 apfu for chlorite and O = 11 apfu for mica) with a fixed density and an initial thickness of 100 nm, it is possible to deduce a number of cations, which makes possible the quantification of an ideal oxygen atomic % (i.e. the ratio [14 or 11 Oxygens]/[number of cations + 14 or 11 Oxygens]). If the result is not equal to the real oxygen atomic% (calculated from the O k-factor), the thickness is modified, and a new correction is applied on k-factors. This calculation is repeated for each analysis until a convergence is reached between ideal and real oxygen atomic%. In this study, this protocol is noted t-O-protocol, for estimated thickness from oxygen atomic% protocol.

Precaution for TEM analysis to minimize polarization effect and contaminations

In addition to the thickness effects, other artefacts may affect the quantitative results. [START_REF] Bullock | Crystalline effects in the analysis of semiconductor materials using Auger electrons and X-rays[END_REF] demonstrated that TEM-EDX quantification may be influenced by the crystalline orientation with respect to the incident electron beam. This effect may however be minimized upstream by analyzing the standards used for the EDX calibration and the FIB-sections of clays according to the same crystalline planes. Thus, the gauged k-factors take into account the orientation effect. For that purpose, (i) the petrographic thin sections are cut perpendicular to the main cleavage of the rock, i.e. perpendicular to the sheet-silicates (00l) plane, and (ii) FIB sections are always cut perpendicular to the longest axis of the crystal after careful observation with a SEM. This guarantees that the crystal is cut perpendicular to the (00l) plane and so minimizes the contribution of the orientation effect to the k-factors standardization.

One should also consider that the incident beam may affect an adjacent mineral, inducing contaminations and errors in quantification. Figure 4 presents a Monte-Carlo simulation of the trajectories of beam electrons in the FIB section, with the maximum sample tilt configuration (7°). It shows an increase in the beam spot size of ~50% at the opposite face of a FIB-section with a thickness of 200 nm. This simulation suggests that analyses of clays must be made at a minimum distance of 30 nm from the contact with other minerals in order to limit contaminations. Additionally, as the take-off angle is 32°, it is possible that the high-energy X-rays of one mineral could excite the fluorescence of lower-energy lines from adjacent minerals. In fact, to completely avoid contamination, fluorescence and absorption effects due to the adjacent minerals must be taking into account in the quantification corrections.

Figure 4. Monte-Carlo simulation of 2000 electron trajectories in a mica with a thickness of 200 nm and a density of 2.7. Simulation was made with PENELOPE-2006 [START_REF] Salvat | PENELOPE-2006: A code system for Monte-Carlo simulation of electron and photon transport[END_REF].

Evaluation of the FIB-milling procedure for TEM-EDX quantitative analysis

Evaluation of the t-O-protocol validity

To check the accuracy of the t-O-protocol, we tried to correlate the estimated thickness to an independent analytical criterion such as the number of counts. On Figure 5, we have represented a TEM cartography that shows the number of counts (noted "input rate"), which is actually known to be strongly correlated to the thickness. In theory, we expect the thickness to influence the number of counts detected by the probe, and practically we expect some correlation between the estimated thickness and the input rate. It is necessary to establish that the input rate parameter is independent of the normalized chemistry. This is tested on Figure 6 which shows that the Si and Al contents of micas show no clear correlation with the input rate. Figure 7-a shows the estimated thickness versus the input rate (in counts/s) for the mica analyses of all Glarus samples, and that (i) the two parameters are highly correlated and (ii) the great majority of estimated thicknesses fall in the range of expected FIB-section thickness, which is 50-300 nm. The few estimated thicknesses equal to 0 to parts of the FIBsection that are sufficiently thin to belong to the "infinitely thin" case where the corrections do not apply.

However, the calculation procedure to estimate the thickness of FIB sections is very sensitive to the variations of the number of cations. Assumption of all Fe as FeO implies a maximum number of cations, and a possible variation of the Fe 3+ /Fe 2+ ratio will induce significant variations in both the structural formulae and calculated thickness. For the structural formulae calculation, the absence of quantitative information on the Fe 3+ content is an inherent problem to all microanalytical techniques including EMP. For the estimation of thickness, the Fe 3+ content is a severe limitation that may completely alter the benefit of the thickness-correction of the analysis. Table 2 shows an example, where, for a mica with an iron content of 0.51 apfu, the estimated thickness may vary by up to 24 nm (109 nm to 133 nm) when assuming either 0% or 100% of trivalent iron. In the case of Fe-rich chlorites, the observed correlation is obviously more significant since the number of iron apfu is much higher. As a consequence, the estimation of thickness is only applicable to phyllosilicates with a low atomic% of iron (e.g. Fe-poor micas), or which have a known Fe 3+ /Fe 2+ ratio. In this study, we selected the GL07 or TI08 samples because of their low content of iron, in particular for micas, and we based our validation protocol on their analytical results. Since the iron content of chlorites is always too high to obtain an accurate number of cations, we have indirectly calculated their thicknesses from analyses of adjacent Fepoor micas occurring at less than 100 nm (noted Mchlorite thicknesses). Figure 7-b represents the M-chlorite thickness against the input rate for each chlorite analysis. As for the micas, a good correlation is observed between input rate and attributed thickness. Importantly, if the Fe 3+ /Fe 2+ ratio is known, the thickness of chlorites can directly be estimated from their proper composition. In cases where this ratio is unknown and there are no Fepoor micas close to the chlorite analysis point, the regression line of Figure 7-b can be used only tentatively to estimate an approximate thickness as a function of the input rate, bearing in mind that such a regression needs to be calibrated for each TEM apparatus.

Discussion of corrected TEM results: comparison between EMP and TEM-EDX analysis

To validate the complete preparation/analysis protocol described in the previous sections, it is necessary to compare the analytical errors attached to the present protocol to those obtained with EMP. To do so, we have performed a circular check on the phyllosilicates from Tinos samples which are large enough to be analyzed by EMPA. Figure 8 presents the comparison of t-O-corrected and uncorrected TEM-EDX analyses with the EMP analyses of M-chlorite for Si and Fe, the most sensitive element to fluorescence and absorption corrections. Figure 9 compares corrected TEM-EDX and EMP analyses of micas for Mg and Al, which may also be affected by fluorescence and absorption corrections. Two aspects deserve attention: the relative scatters of the datasets, and the agreement of average values. The scattering of the TEM-EDX data is higher than the corresponding ones for EMP analyses. This difference in the results distributions can be explained by the difference in the spatial resolution of the two techniques. The interaction volume from which chemical information is obtained with EMPA has a micrometric size, every analysis giving the average composition of over thousand layers. TEM-EDX provides a distinctly higher spatial resolution in analysis (with a spot size of 50 nm in our study), imparting to the results a high dependence on compositional heterogeneities and chemical clustering in the sample. Considering these, the low scattering of the Tinos analyses may be due to a relative homogeneity at the micrometric scale (EMP) that is not anymore observed at the nanometric scale (TEM-EDX). The use of an average composition calculated on all analyses becomes necessary if one wants to compare the results of the two methods.

For the M-chlorite, in the absence of corrections, iron is over-estimated by the TEM-EDX method which yields Fe content higher than 1.95 apfu, whereas EMP results indicate an average of 1.86 apfu. The estimated thickness for this sample varies between 50 and 90 nm, which yields an average correction of -0.1 apfu for that element and makes the result of chemical quantification nearly identical with both methods. For micas, we also obtained a very good agreement between EMP and corrected TEM-EDX average results as shown on Figure 9, with a difference lower than 0.05 apfu when corrections are applied.

Extension of the t-O-protocol to Fe-rich clay minerals

As detailed in the former section, the closest Fe-poor micas can be used to estimate the thickness of adjacent chlorites. This approach may be generalized to entire FIB thin sections, as illustrated on Figure 10, where the bright-field TEM image of a FIB thin-section is used as a background. On Figure 10-c, the "topographic" map obtained from the estimated thicknesses of mica is superimposed. Owing to the density of analysis points, it is possible to delimit curves of iso-thickness in chlorite from analysis points of mica, with an assumed precision of ± 20 nm (equal to the difference between two curves of equivalent thicknesses). If it is assumed that the contrast variation is similar for mica and chlorite, Figure 10 shows a very good correlation between the calculated thickness and the image contrast, lightest contrasts underlining thinner parts of the FIB-section (the correlation between contrast and FIB section thickness was checked with SEM). This application may allow for correcting the chemical maps for example (e.g. [START_REF] Vidal | P-T-deformation-Fe3+/Fe2+ mapping at the thin section scale and comparison with XANES mapping: application to a garnet-bearing metapelite from the Sambagawa metamorphic belt (Japan)[END_REF].

Conclusion

The FIB milling method is becoming a more and more effective tool in its applications to Earth sciences (e.g. [START_REF] Wirth | Focused Ion Beam (FIB): A novel technology for advanced application of micro-and nanoanalysis in geosciences and applied mineralogy[END_REF]. We show here that, with due attention paid, some of its inherent artefacts can be circumvented for its application to clay minerals samples. The main precautions concern both (i) the FIB sectioning and (ii) the analytical procedures and are:

(i-1) decreasing the accelerating voltage and beam intensity during milling in order to avoid amorphization, gallium implantation and material redeposition; (i-2) avoiding too thin FIB sections (in order to keep a high crystalline/amorphized material ratio); (ii-1) analyse the crystal close to the Pt strap for metal redeposition; (ii-2) calibration of the EDX-probe with powders of reference phyllosilicates, in the (00l) plane; (ii-3) care for identical analytical conditions during sample and reference-material analysis, including crystalline orientation; (ii-4) sample thickness evaluation in each analysis point, in order to implement fluorescence and absorption corrections. The protocol developed here for TEM analysis of a non-infinitely thin section with EDX standardization on particles yields results that are in excellent agreement with those of EMP. The t-O-protocol is extendable to the whole family of phyllosilicates, in particular to smectites, which have the same structure as micas. In the case of Fe-rich phyllosilicates a limitation is the Fe 3+ content, which should be known to evaluate properly the sample thickness. However, the protocol remains applicable for all the phyllosilicates which are Fe 3+ -poor and therefore offers a viable substitute to EMP for the analysis of submicrometric minerals.

The immense benefit of coupling TEM-EDX with FIB milling is that analyses are performed on areas that could be preselected on the basis of textural or petrological criteria and be extracted with sub-micrometric precision. This opens therefore the field of nanoscale analysis to clay minerals in selected and preserved textures, allowing a true petrological approach down to nanometer scale. Intracrystalline compositional variations or zonations become accessible at this scale and so do local equilibrium that may have controlled mineral chemistry. Potential applications of this technique range from recalibration of phyllosilicate-based thermometers under diagenetic conditions to the fine-scale monitoring of dissolutionrecrystallisation processes in reservoir rocks.

  Ie2 are the measured X-ray intensities on e1 and e2 elements, ce1 and ce2 are the concentrations of the two elements, and ke1 and ke2 are k-factors values, determined from thin standards. The k-factors equation includes several terms, as the atomic weight (Ae), the fluorescence yield ( j

Figure 3 .

 3 Figure 3. Oxygen k-factors deduced from each analysis of the standards (n = 162). The plain line represents the O k-factor given by TEM manufacturers. The dashed line represents the user-determined k-factor, which is the average of all deduced kfactors. The dashed rectangle represents the standard deviation (2σ) of 0.208 of deduced k-factors.

Figure 5 .

 5 Figure 5. Relation between sample thickness and EDX input rate. The TEM image on the left shows a FIB thin section with three levels of thickness (~100, ~200 and ~300 nm). The topright image is a close-up view showing the topography of mica in the FIB section, with strong change of thickness along A-B. The bottom-right image is a TEM-EDX cartography representing the number of detected counts in the corresponding area (example of Al).

Figure 6 .

 6 Figure 6. Si (top) and Al (bottom) contents according to the input rate (in counts/s) for all mica analyses of Glarus samples. Si and Al contents are calculated with the fluorescence and absorption corrections, determined from the estimated thicknesses.

Figure 7 .

 7 Figure 7. Correlation between the estimated thicknesses and the input rate (in counts/s). a) Case of micas, on 325 analyses on different FIB blades (GL07); b) Case of 197 chlorites analyses (GL07), for which the thickness was estimated from adjacent Fe-poor micas analyses, localized at less than 100 nm (noted M-chlorite). Absolute input rate values are only valid for the TEM JEOL-2100 F.

Figure 8 .

 8 Figure 8. Comparison between EMP and t-O-protocol EDX-TEM results in case of chlorite, for which the thickness was estimated from adjacent Fe-poor micas analyses (noted Mchlorite). Sample TI08 PIII. Estimated thicknesses between 50 and 90 nm. a) Fe vs Si (apfu) contents without corrections. Average of TEM analysis: Si 2.817, Fe 1.98; average of EMP analysis (apfu): Si 2.83, Fe 1.86. b) Fe vs Si (apfu) contents with t-O-protocol corrections. Average of TEM analysis: Si 2.818, Fe 1.89 vs average of EMP analysis (apfu): Si 2.83, Fe 1.86.

Figure 9 .

 9 Figure 9. Comparison between EMP and t-O-protocol EDX-TEM results in case of mica. Sample TI08 PIII. a) K vs Si (apfu), and b) Al vs Si (apfu). Estimated thicknesses between 30 and 100 nm.

Figure 10 .

 10 Figure 10. Example of use of the estimated thicknesses on micas to delimit variation of thickness over the entire FIB foil. a) FIB thin section with a mica and a chlorite. Black contrasts underline thicker areas of the FIB blade. b) Mica analyses, and estimation of thicknesses with the t-O-protocol. c) Interpolation of level of equivalent thicknesses (in nm). d) Extrapolation to the entire FIB blade in the chlorite area.

  .

	Standards	Compositions	Calibrated elements	Type
	Paragonite 1	Na Al2 Al Si3 O10 (OH)2	Na, Al	Syn.
	Paragonite 2	Na Al2 Al Si3 O10 (OH)2	Na, Al	Syn.
	Pyrophyllite	Al2 Si4 O10 (OH)2	Al	Nat.
	Talc	Mg3.05 Si3.95 Al0.02 O10 (OH)2	Mg	Nat.
	Muscovite	K0.88 Na0.05 Al2.67 Fe0.2 Mg0.03 Si3.15 O10 (OH)2	Fe, K, Al	Nat.
	Chlorite TT15	Fe4.6 Al1.3 Al1.3 Si2.7 O10 (OH)8	Fe, Al	Syn.
	Chlorite TT21	Fe4.38 Al1.62 Al1.62 Si2.38 O10 (OH)8	Fe, Al	Syn.
	Clintonite*	Ca Na0.007 Mg2.29 Fe II 0.05 Fe III 0.11 Al3.39 Si1.20 O10 (OH)2	Mg, Ca, Al	Nat.
	Phengite	K0.89 Na0.01 Fe0.13 Mg0.42 Al1.90 Si3.55 Ti0.01 O10 (OH)2	Mg, Fe, K, Al	Nat.
	Table 1. Minerals used as standards. Syn., synthetic product; Nat., natural product. * Fe 2+ /Fe 3+ ratio determined by Mössbauer
	spectroscopy (Joswig

Table 2 .

 2 Influence of the Fe 3+ /Fe 2+ ratio on the number of cations and indirectly on the thickness estimation. Example of two micas (GL07 and TI08). Results are expressed in apfu for 11 oxygens.

	Iron valency	all Fe is Fe 2+	all Fe is Fe 3+	difference	all Fe is Fe 2+	all Fe is Fe 3+	difference
	Mg	0.37	0.37	0.00	0.32	0.31	-0.01
	Al	2.12	2.10	-0.02	2.38	2.33	-0.05
	Si	3.33	3.30	-0.03	3.21	3.14	-0.07
	K	1.07	1.05	-0.02	0.24	0.23	-0.01
	Fe	0.22	0.22	0.00	0.51	0.49	0.02
	Total	7.11	7.04	-0.07	6.73	6.57	-0.16
	Estimated thickness (nm)	88	95	+ 7	109	133	+ 24

Acknowledgements

We are most grateful to the materials characterization department of IFP Energies Nouvelles-Lyon, in particular to L. Sorbier, and to the laboratory of CP2M-Université Aix-Marseille, for technical advice. This study was financially supported by IFP Energies Nouvelles, CNRS and ENS Paris. The Glarus samples were collected in the frame of a Partenariat Hubert Curien Germaine De Staël between ENS Paris and Université de Neuchâtel (Suisse).