P Arberet

Jean-Paul Bodeveix

F Boniol

J Buisson

G Cannenterre

D Chemouil

A Cortier

Fabien Dagnat

F Dupont

M Filali

Spacify

J P Bodeviex

E Fleury

J Forget

G Garcia

F Herbreteau

E Morand

J Ouy

G Sutre

A Rugina

M Streker

J P Talpin

SPaCIFY: a Formal Model-Driven Engineering for Spacecraft On-Board Software

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

Introduction

SPaCIFY is a research project aiming at developing a design environment for spacecraft flight software. The project promotes a top-down method based upon multiclock synchronous modeling, formally-verified transformations, exhaustive verification through model-checking and a middleware featuring real-time distribution and dynamic-reconfiguration services. The various tools developed are released under FLOSS (free/libre/open-source software) licenses, favouring cost-sharing and sustainability. The project is led by the French Space Agency and gathers prime contractors Astrium Satellites and Thales Alenia Space, ISV's GeenSys (formerly TNI Software) and Anyware Technologies, and academic teams Cama from TELECOM Bretagne, Espresso from Irisa, MV from LaBRI and Acadie from IRIT. It is a 3-years project (starting in February 2007) partly funded by the French Research Agency (ref. ANR 06 TLOG 27).

Context: space systems

Space systems [START_REF] Chemouil | The design of space systems: an application to flight software[END_REF] generally differs from other ground systems by their environmental constraints:

• Most of the time, the communication with a spacecraft is only intermittent, depending on visibility phases. There are two important consequences: the first one is the small amount of data communicable with the ground segment; while the second one lies in the inability for the ground to react quickly to an on-board anomaly.

• Once a spacecraft has been launched, there is obviously no way to operate and observe it except through TC (telecommands) and TM (telemetries). This implies that flight software should have been designed in a suitable way, such that it remains possible to operate the spacecraft in ways unpreviewed at the time of specification.

• Another aspect is that hardware is often limited compared to standard computers, both for what regards memory size and computational power.

• Validation is also generally a harder task than for other ground systems, mostly because some parts of the system simply cannot be tested "for real" before launching.

• Finally, the whole lifecycle of flight software may last from 10 to 20 years. Platform and software designers usually do not keep following the same project for so many years, which may cause a loss of knowledge about the way the product works. This problem becomes strong when update operation are required on a space system specification and design, even when in flight.

1.2 Spacecraft on-board software Spacecraft on-board software, and more precisely satellite software, can be either central or remote, which means that various pieces of software can run on the central processing unit or on remote terminal units (e.g., a star-tracking software, a processing unit dedicated to the AOCS, etc.). Modeling techniques for spacecraft onboard software should then take into account such a distributed nature.

The main functions implemented by on-board platform are derived from functional chains (power management, thermal management, AOCS (Attitude and Orbit Control System) management, etc.) and are supported by real-time executives (such as RTEMS ) providing basic services (task management, scheduling, synchronization and communication facilities, memory management, etc.). Modern central flight software usually comprises around 10 to 20 tasks, a few of them being periodic, the others being sporadic or completely aperiodic. These tasks are generally managed through fixed-priority static scheduling (rate-monotonic style).

1.3

The adressed problem and the SPaCIFY contribution The hardest part in developing on-board software, both platform and payload parts, lies in the ability, or not, to verify and to validate it. It already happened to find very well-designed software that was almost unverifiable statically (this being due for instance to a large use of function pointers). Obviously, the most difficult tasks concern dynamic and performance matters. Finally, FDIR (Failure Detection, Isolation, and Recovery) is also problematic, as validating it means being able to guess possible failures and to simulate them (which is sometimes impossible for some space equipment). Moreover, some FDIR strategies are so complex that they are almost impossible to validate (for this reason, there has been a movement towards using simple FDIR strategies, possibly needing ground intervention, rather than smart but hard to understand strategies). The use of formal methods (FM), i.e., fundamental notations and techniques for modeling, analysis, validation of systems in a provably sound way, coupled with modeldriven engineering (MDE) approach all along the conception could be an efficient help for designer to ensure some quality in the development. The SPaCIFY project aims at bringing advances in FM and MDE to the spacecraft on-board software industry. It focuses on software development and maintenance phases of spacecraft life-cycles. The project advocates a top-down approach built on a domain-specific modeling language named Synoptic. In line with previous approaches to real-time modeling such as Statecharts and Simulink, Synoptic features hierarchical decomposition in synchronous block diagrams and state machines. Thanks to the formal semantics of Synoptic, formal transformation from Synoptic to two other formal languages have been developed. The first transformation, from Synoptic to AltaRica enables formal verification on Synoptic models. The second one from Synoptic to Signal enable efficient embedded code generation. All these models and transformations form the SPaCIFY development process presented in the following sections.

The SPaCIFY approach 2.1 Overview

The SPaCIFY development process is depicted figure 1. The main ambition of this process is to enable developers to focus on design rather than on implementation, and to work with design models promoting a high level of abstraction. In this context, the main manual part of the design process is the edition and the definition of a "functional" Synoptic model. Other models are obtained using a bunch of (almost) automated transformations (each arrow figures a chain of various transformations). The SPaCIFY development process is strongly based on the Synoptic language. Synoptic allows to describe an onboard software at different layers and from different viewpoints:

1. At the highest level, only functional aspects are described by using syntactic constructions such as dataflow diagrams, automata (including mode automata). Functional components may be imported from other formalisms such as Simulink/Stateflow. At this level, and from a semantic point of view, the systems is considered as a GALS (Globally Asynchronous Locally Synchronous) systems composed ). Notice that "functional" does not mean untimed. Temporal information such as rate, frequency, latency, etc. are taken into account in order to allow a complete and formal specification of the expected behavior of the system. Formal verification can be achieved at this level by transforming a Synoptic model into an AltaRica one and by model checking techniques. Such a formal verification method allows to check on the Synoptic specification functional properties such as recovery failure requirements.

2. Plateform information such as hardware and software architectures (in terms of threads, resources, and mapping from the firsts to the seconds) are taken into account at a lower level. The dynamic software architecture and the hardware architecture (specified in an external formalism, for instance, AADL) are then introduced. Synoptic functional components are split or grouped into threads components and mapped onto resources according to architectural choices defined by the designer.

3. Finally, two transformation are applied at the low level model: code generation, and middleware configuration generation. These transformation are sup-ported by an intermediate transformation from Synoptic to the synchronous Signal language, enabling the use at the Synoptic level of the Polychrony suite tools.

The Synoptic modeling language

Synoptic is a Domain Specific Modeling Language (DSML) which aims to support all aspects of embedded flight-software design. As such, Synoptic consists of heterogeneous modeling and programming principles defined in collaboration with the industrial partners and end users of the SPaCIFY project. The aim of this section is only to give a brief overview of this language. See [START_REF] Cortier | Synoptic: a domain specific modeling language for embedded real-time flight software design[END_REF] for a detailled presentation oo Synoptic. Used as the central modeling language of the SPaCIFY model driven engineering process, Synoptic allows to describe different layers of abstraction: at the highest level, the software architecture models the functional decomposition of the flight software. This is mapped to a dynamic architecture which defines the thread structure of the software. It consists of a set of threads, where each thread is characterized by properties such as its frequency, priority and activation pattern (periodic, sporadic). At the lowest level, the hardware architecture permits to define devices (processors, sensors, actuators, busses) and their properties. Synoptic permits to describe three types of mappings between these layers:

• mappings which define a correspondence between the software and the dynamic architecture, by specifying which blocks are executed by which threads;

• mappings which describe the correspondences between the dynamic and hardware architecture, by specifying which threads are executed by which processor,

• and mappings which describe a correspondence between the software and hardware architecture, by specifying which data is transported by which bus for instance.

Figure 2 depicts the principles discussed above. Our aim is to synthesize as much of these mappings as possible, for example by appealing to internal or external schedulers. However, to allow for human intervention, it is possible to give a fine-grained mapping, thus overriding or bypassing machine-generated schedules. Anyway, consistency of the resulting dynamic architecture is verified by the SPaCIFY tool suite, based on the properties of the software and dynamic model.

Figure 2. Global view : layers and architecture mappings

At each step of the development process, it is also useful to model different abstraction levels of the system under design inside a same layer (functional, dynamic or hardware architecture). Synoptic offers this capability by providing an incremental design framework and refinement features.

To summarize, Synoptic deals with dataflow diagrams, mode automata, blocks, components, dynamic and hardware architecture, mapping and timing.

In this section we focus on the functional part of the Synoptic language which permits to model software architecture. This sub-language is well adapted to model synchronous islands and to specify interaction points between these islands and the middleware platform using the concept of external variables. Synchronous islands and middleware form a Globally Asynchronous and Locally Synchronous (GALS) system. The development of the Synoptic software architecture language has been tightly coordinated with the definition of the GeneAuto language [START_REF] Toom | GeneAuto: An Automatic Code Generator for a safe subset of SimuLink/StateFlow[END_REF]. Synoptic uses essentially two types of modules, called blocks in Synoptic, which can be mutually nested: dataflow diagrams and mode automata. Nesting favors a hierarchical design and allows to view the description at different levels of details. By embedding blocks in the states of state machines, one can elegantly model operational modes: each state represents a mode, and transitions correspond to mode changes.

In each mode, the system may be composed of other subblocks or have different connection patterns among components.

Apart from structural and behavioral aspects, the Synoptic software architecture language allows to define temporal properties of blocks. For instance, a block can be parameterized with a frequency and a worst case execution time which are taken into account in the mapping onto the dynamic architecture.

The formal semantics of the Synoptic language relies on the polychronous paradigm. This semantics was used for the definition of the transformation of Synoptic models towards the synchronous language SIGNAL and SME models [START_REF] Brunette | A metamodel for the design of polychronous systems[END_REF] following a MDE approach. This transformation allows to use the Polychrony platform for model transformation hints for the end user, such as splitting of software as several synchronous islands and simulation code generation purposes. On the other hand, the formal semantics definition allows for neat integration of verification environments for ascertaining properties of the system under development.

Synoptic is equipped with an assertion language that allows to state desired properties of the model under development. We are mainly interested in properties that permit to express, for example, coherence of the modes ("if component X is in mode m1, then component Y is in mode m2" or "... can eventually move into mode m2"). Specific transformations extract these properties and pass them to the verification tools.

Verification methodology

Verification of the Synoptic model takes place at an early step in the software development process. It is mainly intended to track conception inadequacies and logic errors in the model. Thus, the model-checker is fed with the Synoptic model and does not handle the lower levels of the development process (source code generation and middleware configuration).

In short, the Synoptic model and its specifications are first translated into the AltaRica language [START_REF] Arnold | The AltaRica formalism for describing concurrent systems[END_REF][START_REF] Point | AltaRica -constraint automata as a description language[END_REF] and then verified with Arc1 or Mec 52 [START_REF] Griffault | The Mec 5 modelchecker[END_REF]. When an error is discovered by the model-checker, a concrete run is extracted from the symbolic trace and back-translated and mapped onto the Synoptic model.

AltaRica Language and Tools

AltaRica is a high-level language designed for the modelling of complex systems. The well-defined semantics of AltaRica is based on the Arnold-Nivat model but applied to Constraint Automata. Synchronisation of constraint automata is made up of: (a) the standard Arnold-Nivat strong synchronization of events; (b) boolean constraints on variables shared by automata; ans (c) a weakest synchroniza-tion mechanism of events that is similar to a broadcast mechanism.

Several tools exist for the analysis or the compilation of theAltaRica language. Below, are listed the ones developed mainly by the MF/MV theme of the LaBRI. There also exist commercial tools [START_REF] Bieber | Safety assessment with AltaRica -lessons learnt based on two aircraft system studies[END_REF][START_REF] Kehren | Advanced multisystem simulation capabilities with AltaRica[END_REF][START_REF] Kehren | Architecture patterns for safe design[END_REF] but these tools work with restricted variants of the AltaRica language.

• ARC is an AltaRica model checker based on both explicit and symbolic representation of transition systems. ARC computes the semantics with a syntactic flattening of the AltaRica hierarchical model. ARC can also be used as a gateway with other languages.

In particular, there exists translators linking the Al-taRica and Lustre languages.

• Mec 5 is a model-checker based on the Binary Decision Diagram (BDD) technology [START_REF] Bryant | Graph-based algorithms for boolean function manipulation[END_REF] and uses Al-taRica descriptions as input. Mec 5 computes the semantics inductively based on the hierarchy of the AltaRica model. It can be used to check µ-calculus formulas against AltaRica models but it can also be used as a simple µ-calculus calculator over finite domains. The current version of Mec 5 does not support the full syntax of the AltaRica.

Basically, the difference between the two tools can be summed up as follow: The ARC model-checker is used to deal with big models and simple properties, whereas Mec 5 is a more academic tools intended to deal with small models and complex properties.

Translation from Synoptic to AltaRica

The process of translating the Synoptic model into an Al-taRica model is preserving: the hierarchy of the original model, the operational semantics coded in the automata. Many other features are supported but the float variables and clocks.

The main problem raised while conceiving the automatic translation was to deal with the asynchronous model when AltaRica is synchronous. Anyway, this issue has been solved by forcing the synchronicity of all the components and exploring the different shifts that can occur. It also worth noticing that the translation has been done in a way that preserve back-translation of error trace onto the original model. It is thus possible to syntactically relate the error trace sent by the model-checker to the original Synoptic model.

SPaCIFY middleware

In order to support the execution of code generated from Synoptic model, a middleware has been defined. This SPaCIFY middleware addresses two main points: the scarceness of resources in a spacecraft, and the large variety of spacecraft platforms from one project to another.

To take into account the scarceness of resources, the middleware is tailored to the domain and adapted to each specific project. This notion of generative middleware is inherited from the ASSERT3 project which has studied proof-based engineering of real-time applications but is here specialised to the area of satellite software. AS-SERT defines a so-called virtual machine, which denotes a RTOS kernel along with a middleware and provides a language-neutral semantics of the Ravenscar profile [START_REF] Burns | Guide for the use of the Ada Ravenscar Profile in high integrity systems[END_REF]. It relies on PolyORB-HI [START_REF] Hugues | Combining Model Processing and Middleware Configuration for Building Distributed High-Integrity Systems[END_REF], a high integrity version of PolyORB refining the broker design pattern [START_REF] Buschmann | Pattern-oriented software architecture: a system of patterns[END_REF], which fosters the reuse of large chunks of code when implementing multiple middleware personalities. Satisfying restrictions from the Ravenscar profile, PolyORB-HI can suitably be used as a runtime support for applications built with AADL code generators. In our context, the support of a precise adaptation to the need of the middleware is obtained thanks to its generation based on the requirements expressed in the Synoptic models (mainly through the interaction contracts attached to external variables).

Middleware architecture

Figure 3 depicts the overall architecture of the SPaCIFY middleware. Following previous work on middlewares for real-time embedded systems [START_REF] Brinkschulte | Open System Architecture for embedded control applications[END_REF][START_REF] Schneider | A middleware approach for dynamic real-time software reconfiguration on distributed embedded systems[END_REF], the SPaCIFY middleware has a microkernel-like or service-based architecture. That way, high flexibility allows to embed only the services that are required, depending on the satellite. While previous work has focused on techniques to reduce the time during which the reconfigured system is suspended, along with an analysis to bound that time, our work aims at: (a) using application model to specify reconfiguration, (b) proposing a contract approach to the specification of relation between applications and the middleware, and (c) providing on demand generation of the needed subset of the middleware for a given satellite. The RTOS kernel offers the usual basic services such as task management and synchronisation primitives. The core middleware is built on top of this RTOS and provides core services of composition and communication. They are not intended to be used by application-level software. They rather provide means to structure the middleware itself in smaller composable entities, the services. Upon these abstractions are built general purpose services and domain specific services. These services are to be used (indirectly) by the application software (here the various synchronous islets). They can be organized in two categories as follows:

• The first layer is composed of general purpose services that may be found in usual middleware. Among them, the naming service implements a namespace that would be suitable for distributed systems. The persistency service provides a persistent storage for keeping data across system reboots. The redundancy service helps increasing system reliability thanks to transparent replication management. The reconfiguration service, further described in subsection 3.3, adds flexibility to the system as it allows to modify the software at runtime. The task & event service contributes real-time dispatching of processors according to the underlying RTOS scheduler. It provides skeletons for various kinds of tasks, including periodic, sporadic and aperiodic event-triggered tasks, possibly implementing sporadic servers or similar techniques [START_REF] Sprunt | Exploiting Unused Periodic Time for Aperiodic Service Using the Extended Priority Exchange Algorithm[END_REF][START_REF] Isovic | Efficient Scheduling of Sporadic, Aperiodic, and Periodic Tasks with Complex Constraints[END_REF].

• The second layer contains domain-specific services to capture the expertise in the area of satellite flight control software. These services are often built following industry standards such as PUS [START_REF] Esa | European space agency. ground systems and operations -telemetry and telecommand packet utilization (ecss-e-70)[END_REF]. The TM/TC service implements the well established telemetry/telecommand link with ground stations or other satellites. The AOCS (attitude and orbit control system) controls actuators in order to ensure the proper positioning of the satellite.

To support the execution the platform use hardware resources provided by the satellite. As the hardware plat-form changes from one satellite to another, it must be abstracted even for the middleware services. Only the implementation of specific drivers must be done for each hardware architecture. During the software development lifecycle, the appropriate corresponding service implementations are configured and adapted to the provided hardware.

As already exposed, one particularity of the SPaCIFY approach is the use of the synchronous paradigm. To support the use of the middleware services within this approach, we propose to use an abstraction, the external variable. Such a variable abstracts the interaction between synchronous islets or between a synchronous islet and the middleware relaxing the requirements of synchrony. In the model, when the software architect wants to use a middleware service, he provides a contract describing its requirements on the corresponding set of external variables and the middleware is in charge to meet these requirements. Clearly, this mediation layer in charge of the external variables management is specific to each satellite. Hence the contractual approach drives the generation of the proper management code. This layer is made of backends that capture all the asynchronous concerns such as accessing to a device or any aperiodic task , hence implementing asynchronous communications of the GALS approach. The middleware is in charge of the orchestration of the exchange between external variables, their managing backends and the services while ensuring the respect of quality of service constraints (such temporal one) specified in their contracts.

The middleware kernel and external variables

As stated above, the middleware is built around a RTOS providing tasks and synchronisation. As the RTOS cannot be fixed due to industrial constraints, the middleware kernel must provide a common abstraction. It therefore embeds its own notion of task and for specific RTOS an adaptor must be provided. The implementation of such adaptors has been left for future until now. Notice that the use of this common abstraction forbids the use of specific and sophisticated services offered by some RTOS.

The approach here is more to adapt the services offered by the middleware to the business needs rather using low level and high performance services.

The task is the unit of execution. Each task can contain Synoptic components according to the specification of the dynamic architecture of the application. Tasks have temporal features (processor provisioning, deadline, activation period) inherited from the Synoptic model. The middleware kernel is in charge of their execution and their monitoring. It is also in charge of provisioning resources for the aperiodic and sporadic tasks. Communication inside a task results from the compilation of the synchronous specification of the various components it must support. All communication outside a task must go through external variables limiting interaction to only one abstraction. External variables are decomposed in two sub abstractions:

• The frontend identified in the Synoptic model and that constitutes the interaction point. It appears as usual signal in the synchronous model and may be used as input or output. The way it is provided or consumed is abstracted in a contract that specify the requirements on the signal (such as its timing constraints). An external variable is said to be asynchronous because no clock constraint is introduced between the producer of the signal and its consumer.

In the code generated access to such variables are compiled into getter and setter function implemented by the middleware. The contract must include usage requirements specifying the way the signal is used by the task (either an input or an output). They may also embed requirements on the freshness of the value or on event notifying value change.

• The backend specified using stereotypes in the contract configure the middleware behavior for non synchronous concerns. For example, persistency contract specify that the external variable must be saved in a persistent memory. Acquisition contracts can be used by a task to specify which data it must get before its execution. Such backends are collected and global acquisition plan are built and executed by the middleware.

As the middleware supports the reconfiguration of applications at runtime, tasks can be dynamically created. The dynamic modification of the features is also provided by the middleware. The middleware will have to ensure that these constraints are respected. Beware that any modification must be made on the model and validated by the SPaCIFY tools to only introduce viable constraints. Each task has a miss handler defined. This defensive feature makes the middleware execute corrective actions and report an error whenever the task does not respect its deadline.

Reconfiguration service

Among, domain specific services offered by the middleware, the reconfiguration service is the one that had the most impact on the middleware conception.

The design of the reconfiguration service embedded in the SPaCIFY middleware is driven by the specific requirements of satellite onboard software. Reconfiguration is typically controlled from ground stations via telemetry and telecommands. Human operators not only design reconfigurations, they also decide the right time at which reconfigurations should occur, for instance while the mission is idle. Due to resource shortage in satellites, the reconfiguration service must be memory saving in the choice of embedded metadata. Last, in families of satellites, software versions tend to diverge as workarounds for hardware damages are installed. Nevertheless, some reconfigurations should still apply well to a whole family despite the possible differences between the deployed software.

In order to tackle these challenges, the reconfiguration service rely on the structural model (Synoptic models) of the OBSW enriched by the current state of the satellite as described in Figure 4. Using the structure of the software allows to abstract the low-level implementation details when performing reconfigurations. While designing reconfigurations, operators can work on models of the software, close to those used at development time, and specify so called abstract reconfiguration plan like: change the flow between blocks A and B by a flow between A and C. An abstract reconfiguration plan use high level elements and operations which may increase the CPU consumption of reconfigurations compared to low level patches. Typical operations such as pattern matching of components make the design of reconfiguration easier, but they are compute intensive. Instead of embedding the implementation of those operations into the satellite middleware, patterns may be matched offline, at the ground station, thanks to the knowledge of the flying software. We therefore define a hierarchy of reconfiguration languages, ranging from high-level constructs presented to the reconfiguration designer to low-level instructions implemented in the satellite runtime. Reconfigurations are compiled in a so called concrete reconfiguration plan before being sent to the satellite. For instance, the abstract plan upgrade A may be compiled to stop A and B; unbind A and B; patch the implementation of A; rebind A and B; restart A and B. This compilation process uses proposed techniques to reduce the size of the patch sent to the satellite and the time to apply it [START_REF] Von Platen | Feedback linking: optimizing object code layout for updates[END_REF]. Another interest of this compilation scheme is to enable the use of the same abstract reconfiguration plan to a whole family of satellites. While traditional patch based approaches make it hard to apply a single reconfiguration to a family, each concrete plan may be adapted to the precise state of each of the family member. Applying the previously model driven approach to reconfigurations of satellite software raise a number of other issues that are described in [START_REF] Buisson | Issues in applying a model driven approach to reconfigurations of satellite software[END_REF]. Work remains to be conducted to get the complete reconfiguration tool chain available. The biggest challenge being the specification of reconfiguration plan. Indeed, considering reconfiguration at the level of the structural model implies to include the reconfigurability concern in the metamodel of Synoptic. If reconfigurability is designed as an abstract framework (independent of the modeling language), higher modularity is achieved when deciding the elements that are reconfigurable. First experiments made on Fractal component model [START_REF] Buisson | Experiments with Fractal on Modular Reflection[END_REF] allow us to claim that focusing on the points of interest in application models, metadata for reconfiguration are more efficient. Indeed, separating reconfigurability from Synoptic allows to download metadata on demand or to drop them at runtime, depending on requested reconfigurations. Lastly, applying reconfiguration usually require that the software reach a quiescent state [START_REF] Kramer | The Evolving Philosophers Problem: Dynamic Change Management[END_REF]. Basically, the idea consists in ensuring that the pieces of code to update are not active nor will get activated during their update. For reactive and periodic components as found in the OBSW, such states where reconfiguration can be applied may not be reached. We have proposed another direction [START_REF] Buisson | Introspecting continuations in order to update active code[END_REF]. We consider that active code can be updated consistently. Actually, doing so runs into low-level technical issues such as adjusting instruction pointers, and reshaping and relocating stack frames. Building on previous work on control operators and continuation, we have proposed to deal with the low level difficulties using the notion of continuation and operators to manipulates continuations. This approach do not make updating easier but gives the opportunity to relax the constraints on update timing and allow updates without being anticipated.

Modeling environment

The SPaCIFY design process has been equipped with an Eclipse-based modeling workbench. To ensure the longterm availability of the tools, the Synoptic environment rely on open-source technologies: it guarantees the durability and the adaptability of tools for space projects which can last more than 15 years. We hope this openess will also facilitate adaptations to other industries requirements. The development of the Eclipse-based modeling workbench started with the definition of the Ecore meta-model of the Synoptic language. The definition of this metamodel has relied on the experience gained during the Ge-neAuto project. This definition is the result of a collaborative and iterative process. In a first step, a concrete syntax relying on the meta-model has been defined using academic tools such as TCS (Textual Concrete Syntax) [START_REF] Jouault | Tcs:: a dsl for the specification of textual concrete syntaxes in model engineering[END_REF]. This textual syntax was used to validate the usability of the language through a pilot case study. These models have helped to improve the Synoptic language and to adapt it to industrial know-how. Once the language was stabilized, a graphical user editor was designed. A set of structural and typing constraints have been formalized, encoded in OCL (Object Constraint Language), and integrated into the environment.

Industrial case study

The industrial partner of the project (Astrium and Thales Alenia Space) intend to experiment the SPaCIFY technologies and tool chain using two complementary case studies. The first one is a real industrial use case and the experimentation is meant to cover a horizontal slice of the SPaCIFY engineering process. The second one is a simplified use case meant to allow us, in turn, to cover the entire SPaCIFY process. The first case study targets on the one hand the evaluation of the Synoptic modeling language for early system engineering phases, and on the other hand the evaluation of the Altarica-based modelchecker, especially with respect to its scalability. During early system engineering phases, the main concern is to ensure the correctness of the system specifications that are defined. Such specifications include system architecture in terms of sensors, actuators, and command/control mode automata (in a later phase, the control algorithms are plugged on this architecture). Errors at this level usually have disastrous impact on the rest of the project, thus ensuring the correctness of the mode automata specifications is of prime importance. For classical satellites, this task is based on expert human reasoning. The increasing complexity of space systems, such as constellations of satellites flying in formation, makes it more and more difficult or even impossible, as the human faces combinatorial explosion. Formation flying is of increasing interest in the space domain, as it offers the possibility to distribute complex instruments over several spacecrafts. Indeed, the performance of today's space science missions is restricted by limitations on instrument size. The capabilities of telescopes, interferometers, coronagraphs, etc. are directly related to the size of their optics. Thus, several European Formation Flying missions composed of 2 or 3 satellites are under preparation. The main specificity of such missions is the importance of the coordination among satellites, especially for collision avoidance. Within the SPaCIFY project, we aim to model the command/control and FDIR (Failure Detection Isolation and Recovery) automata in Synoptic and to use the Altarica-based modelchecker to automatically check the expected properties of system the architecture. The resulting models may become the actual specification, while the model-checking results would definitely bring confidence in the specifications. The second case study targets the experimentation of the entire SPaCIFY process by going through all its phases. This experimentation will allow us to evaluate the SPaCIFY process in a realistic context and identify possible areas where tuning may be necessary. For practical reasons, the experimentation will be based on a simplified but sufficiently representative flight software for a classi-cal satellite.

Conclusion

The SPaCIFY ANR exploratory project proposes a development process and associated tools for hard real time embedded space applications. The main originality of the project is to combine model driven engineering, formal methods and synchronous paradigms in a single homogeneous design process. The domain specific language Synoptic has been defined in collaboration with industrial end-users of the project combining functional models derived from Simulink / Stateflow and architectural models derived from AADL. Synoptic provides several views of the system under design: software architecture, hardware architecture, dynamic architecture and mappings between them. Synoptic is especially well adapted for control and command algorithm design. The GALS paradigm adopted by the project is also a key point in the promoted approach. Synoptic language allows to model synchronous islands and to specify how these islands exchange asynchronous information by using the services of a dedicated middleware. In particular, SPaCIFY proposed a contract approach to the specification of the relations between applications and the middleware.

Figure 1 .

 1 Figure 1. SPaCIFY development process

Figure 3 .

 3 Figure 3. Architecture of the middleware.

Figure 4 .

 4 Figure 4. Process and responsabilities for reconfigurations.

http://altarica.labri.u-bordeaux.fr/tools:arc

http://altarica.labri.u-bordeaux.fr/tools:mec 5

http://www.assert-project.net/


Kathy Bru
email: k.bru@brgm.fr

Anne-Gwénaëlle Guezennec
email: a.guezennec@brgm.fr

Florent Bourgeois
email: florent.bourgeois@ensiacet.fr

Numerical Simulation: a Performing Tool for Water Management in Tailings Impoundments

Keywords: simulation, tailings impoundment, water management, tailings mechanical stability, consolidation, water exchanges with the aquifer

The mining industry produces very large quantities of fine-grained tailings that are generally disposed of in slurry form into dedicated impoundments. The twofold purpose of these impoundments is to contain the solids and achieve clarification of the process water for re-use. They are increasingly scrutinized with respect to their environmental performances, since they have impacts on both water availability and quality mainly through water exchanges with the aquifer, and with respect to the mechanical stability of their tailings. Currently, it is difficult to have such information through on-line measures. In this article, the authors present a simulation environment for water management in tailings impoundment. It is concluded that computer simulation is a powerful tool for an environmental standpoint as well as for assisting professionals with design and operation of tailings ponds.

Introduction

Mining activities provide economic benefits for many countries around the world. However, the mining industry also generates large amounts of various wastes that can have negative impacts on the environment if they are not properly managed [START_REF] Benzaazoua | Integrated mine tailings management by combining environmental desulphurization and cemented paste backfill: Application to mine Doyon, Quebec, Canada[END_REF]. Among these, significant amount of fine-grained wastes referred to as tailings are produced. Disposed of in slurry form, tailings are generally discharged into dedicated impoundments which purposes are to confine the solids within their boundaries and to achieve clarification of the process water for re-use (Environment Canada, 1987). These impoundments are becoming increasingly scrutinized with respect to their influence on water resources. Indeed, tailings disposal has an impact on the fresh water consumption since in many cases it is the largest source of water losses through residual moisture in the tailings and seepage. Recycling of clarified water in the mine process is then crucial since it allows reducing the environmental impact as well as the freshwater requirements [START_REF] Ritcey | Tailings management in gold plants[END_REF]. Tailings ponds can also be a source of pollution through migration of pollutants with water exchanges with the hydrogeological formations. Another potential implication is the mechanical stability of tailings once the impoundment is no longer in use. Indeed, the specific geotechnical properties of many fine-grained tailings, combined with the abundant presence of water, can lead in some situations to problems of instability [START_REF] Younger | Mining Impacts on the Fresh Water Environment: Technical and Managerial Guidelines for Catchment Scale Management[END_REF] which is of particular concern in terms of public safety and land reclamation for re-use. Currently, it is difficult to measure on line the water transfers between a tailings pond and its surrounding aquifer as well as the tailings mechanical stability over time. To obtain such information, a quantitative understanding of the complicated interactions between water flows; solids transport, deposition and consolidation; and morphological evolution is required. Simulation tools are then necessary to evaluate the various impacts of a tailing impoundment upon its environment. Existing numerical models have only been developed for predicting solids and water transport within a tailings impoundment [START_REF] Consoli | Soil formation from tailings: comparison of predictions and field measurements[END_REF] and they do not predict the water exchanges between the impoundment and its surrounding hydrogeological formations as well as tailings consolidation state. This article aims to fill this gap of numerical simulation by presenting a simulation environment for water management related to tailings impoundment in the mining industry.

Model presentation

The model takes into account three families of governing processes that interact with one another:

Water transport: in the impoundment, process water is transported between the impoundment inlet and outlet.

in the surrounding aquifer, water can be exchanged depending on the properties of the groundwater flow around the impoundment. Solids transport: the fine particles suspended in the process water are transported and deposited at preferential locations within the impoundment, depending on local flow field, which is itself modified by particle deposition. Sediments consolidation: particles deposition leads to the formation of a sediment deposit undergoing self-weight consolidation, thereby modifying the topography of the impoundment and the flow field inside the impoundment. The numerical model takes into account the transient nature of the involved phenomena. To reduce the calculation time, a 2-dimensional configuration has been chosen (depth and main direction). Figure 1 presents the discretization scheme for the impoundment and its surroundings. The calculation domain is divided into cells. An impoundment cell is characterized by flow parameters (flow velocity, water exchange flowrate between the aquifer and the impoundment, average concentration of the suspended particles) and sediment characteristics (sediment height, void ratio). An aquifer cell is characterized by its hydraulic head. The water stage is the same in all impoundment cells.

Figure 1 Schematic representation of the discretization of the impoundment and its environment

The simulation consists in calculating these parameters at each time step by solving the coupled equations of water transport, solid transport and sediment consolidation. By convention, all fluxes are positive when they come inside the impoundment and negative if they go out of it.

Case study Presentation of the case study

The simulation tool was applied to an impoundment formerly used in a phosphate mine in Senegal. This impoundment is represented in Figure 2. It has an area of 119.2 ha with a depth of 38 m. It is built in a multilayer aquifer. The process water, which contains 157 g/l of suspended solids with a 4 m mean diameter, fed it with a flowrate of 1440 m 3 /h. Clarified water is collected through the use of a spillway. As shown in Figure 2, two empty impoundments border the studied impoundment. This involves a zero head on the on-side wall. Moreover, there is a draining layer of marl of 1m thick bellow the pond. Recycled water corresponds to water collected by the spillway, drained water and water infiltrated through on-side walls.

Figure 2 Top view of the studied impoundment and its surroundings

Simulation results

The filling of this impoundment was simulated over 3.25 years, i.e. 1186 days. Some results given by the simulation are presented hereinafter. They allow predicting the impoundment filling, the amount of recycled water and the water exchanges with the aquifer over time. Figure 3 shows the evolution of the water stage with time. It should be indicated here that the first 7.5m correspond to the bottom levelling due to the presence of marl deposits. After 3.25 years, the water stage is 28.9m with a sediment outcrop over nearly 75% of the impoundment area. This simulation result is very close to what was noticed on the real impoundment, the deviation being about 1%. Evolution of the sediment deposit with time is also represented in Figure 3. Gentle sediment fronts are explained by slow settling velocity compared to the flow velocity. As it can be seen in Figure 4, the model is able to calculate the evolution of the void ratio profile of the sediment deposit. This figure highlights the bad consolidation properties of the sediments, the void ratio being always higher than 2 and the most consolidated layer (void ratio between 2 and 5) being lower than 10m. This is due to their composition, a high clay content, and to their low particle size. These bad consolidation properties explain the low water recycling rate (Figure 5) and involve that at the end of the pond lifetime, a high amount of water is entrapped in the sediment deposit (the residual moisture being always higher than 45%) and then will not be recycled. The consolidation state of the sediment deposit is a key parameter to determine which type of rehabilitation is adapted to the site after the complete filling of the impoundment. In this case, rehabilitation will be difficult due to its instability. Figure 6 shows the evolution of the water volumes exchanged at the interface between the impoundment and the aquifer, these volumes being positive if they come inside the impoundment and negative if they go out of it. It can be seen that water exchanges through the impoundment bottom are very low, this being due to the clogging of the impoundment bottom by the sediment deposit. Water volumes exchanged through the East dike are also very low and their trend, firstly increasing and then decreasing, underlines the influence of the aquifer properties (hydraulic conductivity and head) on the impoundment/aquifer interactions. Moreover, a great amount of water leaks through the on-side dikes (negative water volumes) due to the presence of empty impoundments on every side so this water transfer has an influence on the water budget of the impoundment. Here, this infiltrated water is collected and its fraction in the recycled water volume represents nearly 9% at the end of the simulation time. Information given by this model about tailings mechanical stability and about water exchanges between a tailings pond and its surrounding aquifer cannot be obtained through on-line measures or derived from empiricism. This latter information is particularly interesting for evaluation of the impoundment impacts on the groundwater quantity and quality because it allows evaluating water recycling rate and then the withdrawals in the aquifer for the mining process and it also allows predicting tranfers of pollutants from the impoundment to the aquifer.

Conclusion

This article presents a simulation environment for water management related to tailings impoundment in the mining industry. Based on coupling between transport, deposition and consolidation processes, this numerical model is able to predict the timed evolution of a full-scale tailings pond. Information given by this simulation tool makes it a potentially valuable tool for water management. Indeed, simulation results allow predicting water exchanges between a tailings pond and its surrounding aquifer and their influence on its water budget. This model can then be used to evaluate the impacts of a tailings impoundment on water availability and quality. Beyond the benefit of the simulation tool for an environmental standpoint, it can also be useful for design, production and rehabilitation purposes since it yields numerous information including instantaneous slimes storage volume reserves, available amount of clarified water, impoundment lifetime and consolidation state of the sediment deposit.

Figure 3 Figure 4 Figure 5 :

 345 Figure 3 Evolution of the impoundment filling over time

Figure 6 )

 6 Figure 6 Evolution of the water volume exchanged with the aquifer (added over time)


H D Nguyen

K P Tran

X Zeng

L Koehl

P Castagliola
email: philippe.castagliola@univ-nantes.fr

Industrial Internet of Things, Big Data, and Artificial Intelligence in the Smart Factory: a survey and perspective

Keywords: Industrial Internet of Things, Big Data, Artifical Intelligence, Smart Factory

Thanks to the rapid development and applications of advanced technologies, we are experiencing the fourth industrial revolution, or Industry 4.0, which is a revolution towards smart manufacturing. The wide use of cyber physical systems and Internet of Things leads to the era of Big Data in industrial manufacturing. Artificial Intelligence algorithms emerge as powerful analytics tools to process and analyze the Big Data. These advanced technologies result in the introduction of a new concept in the Industry 4.0: the smart Factory. In order to fully understand this new concept in the context of the Industry 4.0, this paper provides a survey on the key components of a smart factory and the link between them, including the Industrial Internet of Things, Big Data and Artificial Intelligence. Several studies and techniques that are used to enable smart manufacturing are reviewed. Finally, we discuss some perspectives for further researches.

Introduction

In Industry 4.0, the future factory will be more conscious and intelligent to independently perform complex tasks, i.e, "smart factory". The smart factory integrates advanced technologies like Industrial Internet of Things (IIoT), Big Data, Artificial Intelligent (AI) to optimize performance, quality, controllability and transparency of manufacturing processes. It now becomes the heart of Industry 4.0 and attracts a lot of interest from governments, enterprises and researchers. An extensive review on technologies for manufacturing systems based on the smart factory concept has recently been scanned in [START_REF] Alcácer | Scanning the industry 4.0: A literature review on technologies for manufacturing systems[END_REF].

The IIoT refers to the use of Internet of Things (IoT) technology to enhance industrial manufacturing processes. A vital characteristic in the IIoT is that sensors are embedded in all the components related to the manufacturing process. These sensors play the role of eyes for collecting data from the entire manufacturing process and the product life cycle. Along with the wireless sensor networks, they make the data collected from smart manufacturing systems grow exponentially, leading to the concept of Big Data.

The massiveness, complexity and heterogeneity of Big Data requires advanced computing technologies. It is now performed efficiently due to the availability of AI. In the past, the computers were programmed to perform a specific task. Now, the AI makes it intelligent with the ability of correctly interpreting external data, learning from data, and using those learnings to achieve specific tasks through flexible adaptation. The use of AI can revolutionize the industrial manufacturing process with a large number of application such as predictive quality analytics, automation, insightful identification of engineering systems.

Becoming a Smart Factory is a long-term and complex process, requiring a deep insight into advanced technologies that are integral to this process. This paper aims to provide a survey of techniques and applications of IIoT, Big Data and AI in Industry 4.0. The challenges and emerging topics of these crucial components in smart manufacturing are summarized. The rest of the paper is organized as follows. In Section 2, we present the background and techniques of the IIoT. Section 3 explains the concept of Big Data and presents the applications of AI in Industry 4.0. Section 4 is devoted to some perspectives for further researches on the application of IIoT and AI in the smart factory. The conclusion is given in Section 5.

The Industrial Internet of Things

Based on a large number of modern technologies such as cyber-physical systems, cloud computing, mobile technologies, and radio frequencey identification (RFID), the IIoT harnesses the sensor data and incorporates Big Data into machine-to-machine communication and automation technologies that have existed in industrial settings for years [START_REF] Saturno | Proposal of an automation solutions architecture for industry 4.0[END_REF]. As a result, it enables creating new business models by improving productivity, exploiting analytics for innovation, maximizing operational efficiency, optimizing business operations, and protecting systems. The advantages of IIoT in the intelligence manufacturing and smart factories are discussed broadly in the literature, see, for example [START_REF] Matthew No Sadiku | Industrial internet of things[END_REF] and [START_REF] Ray Y Zhong | Intelligent manufacturing in the context of industry 4.0: a review[END_REF].

The first essential basic platform for the IIoT is the Internet of Things (IoT), which is a network of physical devices embedded with sensors, actuators, electronics, software, and the network connectivity that enables these objects to connect and exchange data. The IoT is a bridge between the digital domain and the physical domain. Recently, the arising of novel communication infrastructures such as 5th generation (5G) wireless mobile communication and Low-power Widearea (LPWA) networks is also a significant contribution to the IIoT. Yang et al. [START_REF] Yang | The internet of things for smart manufacturing: A review[END_REF] provided an extensive review of the IoT in the smart manufacturing.

Another state-of-the-art technology of the IIoT is Cyber-Physical System (CPS). The CPS contains networked interactions that are designed and developed with physical inputs and outputs, along with their cybertwined services such as control algorithms and computational capacities [START_REF] Ray Y Zhong | Intelligent manufacturing in the context of industry 4.0: a review[END_REF]. It is now considered as one of the most significant advances in the development of computer science, information and communication technologies. Herterich et al. [START_REF] Herterich | The impact of cyber-physical systems on industrial services in manufacturing[END_REF] investigated the influence of the CPS on industrial services in manufacturing. Several defining characteristics, design techniques and the applications of the CPS have been presented in [START_REF] Kumar | Design techniques and applications of cyberphysical systems: A survey[END_REF][START_REF] Monostori | Cyber-physical systems in manufacturing[END_REF].

Big Data and Artificial Intelligence in industrial applications

In a smart factory, a large number of sensors is used to collect data. These sensors turn physical conditions of an object into electrical signals. These signals are then passed to a programmable logic controller for futher actions. Each component involving in smart manufacturing has a capability of communicating and sharing data based on new network technologies. The rapid development of advanced IIoT technologies makes the process of data acquisition and storage increasingly easy and convenient, promoting the era of industrial Big Data.

In the literature, the first definition of Big Data focuses on enlisting its characteristics, leading to '3V', namely, Volume, Velocity and Variety [START_REF] Sagiroglu | Big data: A review[END_REF]. These characteristics are then extended by adding multiple features like Veracity, Volatility, and Value [START_REF] Fahim Uddin | Seven v's of big data understanding big data to extract value[END_REF]. Other dimensions of Big Data like Vision, Validation, Variability have been recently mentioned in [START_REF] Alcácer | Scanning the industry 4.0: A literature review on technologies for manufacturing systems[END_REF]. The core feature of Big Data is that they require to be analyzed, i.e Big Data analytics. Without being analyzed, Big Data have not much value. Big Data analytics refers to the process of collecting data, transfering data into centralized cloud data centers, preprocessing data, analyzing data, and visualizing data. It helps enterprises planning, handling numerous problems of fault detection and diagnosis, optimization and control, management, transportation, fully understanding the potential of data-driven marketing, production analysis and a new product recommendation. The applying of Big Data analytics results in a 15% -20% increase in return on investment for retailers [START_REF] Perrey | Smart analytics: How marketing drives short-term and long-term growth[END_REF]. Recently, AI, a key factor that makes a smart factory "smart", emerges as a powerful tools in Big Data analytics.

The AI refers to the intelligence demonstrated by machines. This is a set of algorithms that enables a machine to perform complex tasks by perceiving working environment and taking actions to maximize the possibility of successfully achieving the predetermined goals. Nowadays, the term "Artificial Intelligence" is ubiquitous and its application has been witnessed in a large number of areas of everyday life. In industrial manufacturing, the AI also provides significant improvement in designing automatic robot, making decision, monitoring and scheduling the production process, predictive maintenance and analytics. It can be said that the manufacturing and factories in Industry 4.0 cannot be "intelligent" or "smart" without AI.

In the literature, machine learning (ML) algorithms are applied to a large number of applications such as classification of health monitoring systems, detection of faults after the occurrence of certain failures, predictions of the future working conditions and the remaining useful life [START_REF] Ahuett | A brief discussion on the trends of habilitating technologies for industry 4.0 and smart manufacturing[END_REF]. The advantages and challenges of typical techniques of the ML like Support Vector Machine, Random Forest, Bayesian Networks, and Artificial Neural Network in a wide range of industrial areas have been illustrated in [START_REF] Sharp | A survey of the advancing use and development of machine learning in smart manufacturing[END_REF][START_REF] Wuest | Machine learning in manufacturing: advantages, challenges, and applications[END_REF]. Gao et al. [START_REF] Gao | Cloud-enabled prognosis for manufacturing[END_REF] discussed the strengths and weaknesses of the machine learning methods for fault prognostic. To overcome the limitation of traditional machine learning methods, a number of deep learning algorithms have been recently investigated. The Convolutional Neural Network, the Deep Belief Network and the Stacked Auto Encoder have been applied to several fault diagnostics such as bearing, gearbox, wind generator and wind turbine [START_REF] Janssens | Convolutional neural network based fault detection for rotating machinery[END_REF][START_REF] Lei | An intelligent fault diagnosis method using unsupervised feature learning towards mechanical big data[END_REF]. Deep learning algorithms such as the Recurrent Neural Network (RNN) and the Support Vector Regression have been proposed for predictive analytics in [START_REF] Wang | A deep learning-based approach to material removal rate prediction in polishing[END_REF]. Wang et al. [START_REF] Wang | Deep learning for smart manufacturing: Methods and applications[END_REF] conducted a comprehensive review of applications of deep learning algorithms for smart manufacturing.

Another algorithm of the AI which also has a great impact on Industry 4.0 is the reinforcement learning (RL). The major contribution of RL to smart manufacturing is perhaps in Robotics, which is discussed broadly in [START_REF] Kober | Reinforcement learning in robotics: A survey[END_REF]. Levine et al. [START_REF] Levine | End-to-end training of deep visuomotor policies[END_REF] and Mnih et al. [START_REF] Mnih | Asynchronous methods for deep reinforcement learning[END_REF] utilized deep RL to tackle a wide variety of motion planning for industrial robots directly from sensory inputs. Then, these studies were improved in [START_REF] Meyes | Motion planning for industrial robots using reinforcement learning[END_REF] to avoid the computational effort of the learning problem. Deep reinforcement learning with a smooth policy update has been applied to robotic cloth manipulation in [START_REF] Tsurumine | Deep reinforcement learning with smooth policy update: Application to robotic cloth manipulation[END_REF]. The RL algorithms also significantly contribute to scheduling, which is the process of arranging, controlling and optimizing work and workloads in a production process. A large number researches on the scheduling problem have been conducted in the literature, see, for example, [START_REF] Leusin | Solving the job-shop scheduling problem in the industry 4.0 era[END_REF][START_REF] Wu | A heuristicbased genetic algorithm for the two-machine flowshop scheduling with learning consideration[END_REF]. According to the discussion in [START_REF] Shiue | Real-time scheduling for a smart factory using a reinforcement learning approach[END_REF], there are two main approaches in realtime scheduling from previous studies, involving the multipass simulation approach and the machine learning approach. The authors have pointed out several drawbacks of these two methods and then proposed a RL-based model for real-time scheduling for a smart factory. In previous sections, we presented the concepts, applications and current studies of IIoT, Big Data and AI for smart factories in the Industry 4.0. Figure 1 provides a framework for the smart factory, in which IIoT, Big Data and AI are three key components. In this section, we discuss some opportunities and futher perspectives of these important factors in intelligent manufacturing.

Monitoring production process

Production monitoring is an important task in smart manufacturing because it enables enterprises to detect timely abnormalities in production lines and then reduce waste. Recently, machine learning algorithms have been proposed for the use within Statistical Process Monitoring (SPM). This approach converts the monitoring problem to outlier detection problem or a supervised classification problem which classifies future observations as either in-control or out-of-control. From this point of view, the idea of using One-Class Support Vector Machines for detecting abnormality in [START_REF] Phuc | Data driven hyperparameter optimization of one-class support vector machines for anomaly detection in wireless sensor networks[END_REF] can be developed further for applying.

The use of IIoT technologies for the large production lines operating continuously creates real-time data. Moreover, the data in smart manufacturing are nowadays collected with a high frequency, high dimension and large variety which should not be treated straightforwardly. Therefore, advanced models for real-time Big Data monitoring are required. Recently, the Topological Data Analysis (TDA) emerges as a powerful tool to extract insights from high-dimensional, incomplete and noisy data of varying types such as images, 3D Scan, graph, point clouds, and meshes. The core idea of TDA is to find the shape, the underlying structure of shapes or relevant low dimensional features of high-dimensional data. As a result, the problem of treating the complex structure and massive data is brought to simpler problems. The first successful application of TDA in the manufacturing domain is conducted in [START_REF] Guo | Identification of key features using topological data analysis for accurate prediction of manufacturing system outputs[END_REF]. In this study, the authors applied the Mapper algorithm, a tool in TDA, for predictive analysis of a chemical manufacturing process data set for yield prediction and a semiconductor etch process data set for fault detection. In general, there are still very few studies on this promising approach and further researches need to be carried out to discover its numerous applications to smart manufacturing. For instance, the deep learning algorithms such as long short-term memory (LSTM) and RNN for Topological Data should be developed to monitor the smart manufacturing process.

Product Lifecycle Management

Product lifecycle management (PLM) refers to the succession of strategies for managing all data relating to the design, production, support and ultimate disposal of manufactured goods. From this point of view, monitoring production process could be considered as a component of PLM. The PLM brings tremendous benefits to manufacturing industries for improving product quality, reducing prototyping costs, identifying potential sales opportunities and revenue contributions, maintaining operational serviceability, and reducing environmental impacts at end-of-life. Venkatasubramanian [START_REF] Venkatasubramanian | Prognostic and diagnostic monitoring of complex systems for product lifecycle management: Challenges and opportunities[END_REF] reported that the petrochemical industry in the U.S. incurs approximately $20 billions in losses due to poor management of equipment and processes which lead to such abnormal situations. Similarly, U.S. manufacturers spend over $7 billions annually recalling and renewing over 2000 defective products. All of these costs are associated with the PLM. A key factor in PLM is prognostic and diagnostic monitoring. By comparing various existing approaches for prognostic and diagnostic in PLM, the author concluded that no traditional single method is adequate to handle all the requirements for a desirable diagnostic system. The application of the intelligent systems framework for this complex problem is then suggested. In this sense, the use of IIoT, Big Data and AI is a basic platform to design such intelligent PLM systems. The IIoT based PLM systems will be the first place where all product information from marketing and design comes together while the AI algorithms process these information and output a form suitable for production and support. As an example, Karasev and Sukhanov [START_REF] Vo Karasev | Product lifecycle management using multi-agent systems models[END_REF] recently designed a PLM system using multi agent systems models. In general, developing the AI based PLM systems in smart manufacturing is attractive for future research.

Predictive maintenance

Another application of IIoT, Big Data and AI in intelligent manufacturing is the predictive maintenance or just-in-time maintenance. The benefits and advantages achieved by the development of a comprehensive predictive maintenance are shown in [START_REF] Ferreiro | Industry 4.0: Predictive intelligent maintenance for production equipment[END_REF]. In the past, the maintenance was regularly scheduled at fixed intervals, leading to some limitations. It could be a large amount of money in lost productivity while process must be halted to fix the failures when a machine breaks before the maintenance. Otherwise, time and another amount of money would be wasted if the machine does not need any maintenance at the moment. Even, unnecessary maintenance operations may increase the failure rate because of installed defective items or human negligence. The advanced IIoT technologies allows engineering to carry out timely predictive maintenance. In particular, the sensors are applied to different piece of equipments to continuously update the individual equipment health. The AI tools can process this gathered data to monitor and forecast overloads, machinery failures, or related problems based on learning algorithms. The appropriate time that a machine need to be maintained will be determined exactly. The Online Learning, Transfer Learning and Domain Adaption are the trends for predictive maintenance and prognosis in Industry 4.0 [START_REF] Diez-Olivan | Data fusion and machine learning for industrial prognosis: Trends and perspectives towards industry 4.0[END_REF].

Cybersecurity

The exponential growth of IIoT also brings a significant challenge related to the cybersecurity problem in designing and implementing the smart factory. It would result in severe and heavy consequences if hackers could gain access to control networks or malware and worms could invade and destroy the operating systems of a factory. The cybersecurity is now a major concern in many researches. Twenty-four risk assessment methods developed for or applied in the context of a supervisory control and data acquisition system have been selected and examined in [START_REF] Cherdantseva | A review of cyber security risk assessment methods for scada systems[END_REF]. Tuptuk and Hailes [START_REF] Tuptuk | Security of smart manufacturing systems[END_REF] provided a large number of real reported attacks against smart manufacturing systems and existing active and passive countermeasures with their limitations. In general, several traditional existing cybersecurity solutions have become obsolete [START_REF] Mahmood | Security analytics: Big data analytics for cybersecurity: A review of trends, techniques and tools[END_REF]. The machine learning and deep learning algorithms for regression, classification and clustering are poweful tools to detect and identify different classes of network attacks. For example, the method for network intrusion detection based on nested one-class support vector machines presented in [START_REF] Quoc | Nested one-class support vector machines for network intrusion detection[END_REF], the method for anomaly detection in time series based on LSTM networks presented in [START_REF] Malhotra | Long short term memory networks for anomaly detection in time series[END_REF] could be applied and developed for futher applications to the cybersecurity problem in intelligent manufacturing.

Conclusion

The IIoT, Big Data and AI are three key components of a smart factory. The wide use of electronic sensing devices, wireless sensor networks and other advanced technologies in the IIoT make the process of collecting, transforming and storing data from all statges of production process easier and more convenient, promoting the era of big manufacturing data. The AI provides powerful analytics approaches for the insight into these Big Data. By extracting insightful information from the unprecedented amount of data, the AI algorithms bring numerous benefits to the smart factory such as optimizing the production process, enhancing the product quality, reducing cost and securing. Despite of a large number of studies contributing to the applications of these technologies to intelligent manufacturing, there are still many challenges for further researches. The new advanced inventions in IIoT and AI will make a decisive contribution to the development of Industry 4.0.

Fig. 1 :

 1 Fig. 1: A framework for the smart factory


Ch Lahellec

S Hochard

Leroch

A Girardot

N Lahellec

Ch Hochard

S Leroch

DAMAGE EVOLUTION UNDER LONG-TERM, HIGH AND CONSTANT LOADING OF A CARBON/EPOXY LAMINATE

Keywords: carbone/epoxy, laminate, damage, constant load

When a composite material of carbon fiber and epoxy resin is subjected to mechanical loading, different phenomena can lead to changes in its properties or even irreversible damage (propagation of cracks, debonding between folds, fiber breakage). The objective of this work is to study, under high loads and long periods, the propagation of transverse microcracks (diffuse damage) until the fracture of the laminate under matrix modes (instability). Since long term tests are necessary to characterize the damage evolution as well as the creep and stress relaxation phenomena, a testing machine was carried out. Optimal orientations ([45°,-45°]ns and [60°,-60°]ns) and specimen shape have been defined to study this phenomena. Experimental results are presented here and it is observed an evolution of the matrix damage under constant loads. This evolution is compared to the evolution of the matrix damage in the case of cyclic loads (fatigue) which in this latter case is faster.

Introduction

The manufacture of cylindrical structures is made by winding of fibers on a mold or a mandrel (Figure 1). This procedure is described as filament winding. Various applications exist for cylindrical structures (pressure vessels, piping ...). These structures can be subjected to static loadings, fatigue and sometimes at high constant loads for long periods. The evolution of damage in CFRP under monotonic and cycled load is studied since a long time [START_REF] Miot | Rupture de structures composites stratifiées sous chargements statique et de fatigue[END_REF][START_REF] Thollon | Analyse du comportement à rupture de composites stratifiés constitués de plis tissés sous chargements statique et de fatigue[END_REF]. Transverse micro-cracking appear from static loading, and they multiply under fatigue loading [START_REF] Ch | Modelling of the mechanical behaviour of woven-fabric CFRP laminates up to failure[END_REF]. However, the evolution of damage under constant loading and the existence of a threshold are less well known.

The objective of this work is to study, in the context of long-term, high and constant mechanical loading, the damage evolution and especially transverse crack propagation of a carbon/epoxy laminate. One of the failure modes of the composite materials is the matrix micro-cracking increasing until a meso-crack at the level of the ply and a macro-crack at the level of the laminate. Compare to a brittle fibber mode fracture, this matrix mode fracture of the laminate correspond to an instability due to the localization of the damage. Damage mechanisms involve at several scales but we limit ourselves to the intra-ply scale. The evolution of this damage depends on the combined transverse and shear loads and can be modelled as part of the mechanical damage [START_REF] Ladeveze | Damage modelling of the elementary ply for laminated composites[END_REF].

Since long term tests are necessary to characterize the damage evolution as well as the creep and stress relaxation phenomena, a testing machine was carried out. In order to study the evolution of the damage under shear and transverse constant loads, optimal orientations and specimen shape have been defined. The design of the testing machine is presented. Experimental results are presented here and the evolution of the matrix damage under constant loads is compared to the evolution of the matrix damage in the case of cyclic loads (fatigue).

Specimen and testin machine

Specimen shape and optimal orientations

In order to avoid a premature fracture at the level of the grips, we use dumbbell shaped specimen (Fig. 2) which leads to a fracture in the center of the specimen without stress concentrations. Initially, static tensile tests on specimen are performed by varying the orientation of the plies. The goal is to find the optimal orientation to obtain the shear and the transverse behaviour. The optimal orientation to get the shear behaviour is a [45°,-45°]ns (Fig. 3). The transverse behaviour is more complicated to get because the material is very brittle in this direction and is different of the behaviour inside a laminate (Fig. 4). The classical [67°,-67°]ns [START_REF] Ladeveze | Damage modelling of the elementary ply for laminated composites[END_REF] is still brittle and, after some experimental tests, we concluded that on [60°,-60°]ns specimens seem to be a good compromise as this orientation limits the shear and avoids premature rupture in the transverse direction (Fig. 5). The specimen rupture is due to an instability.

Testing machine

Since long term tests are necessary to characterize the evolution of the damage under constant loads and the creep and stress relaxation phenomena, a testing machine was carried out (Fig. 6). The creep test is performed simply by suspending weights on the specimen, and the relaxation test is performed thanks to a coil system. This system permit to tensioning the specimen. The force is measured with a sensor.

Figure 6. Testing machine.

Fatigue test

In case of cyclic loads (fatigue), the evolution of damage d corresponding to the decreasing of the Young modulus (E=E0(1-d)) can be observed. The decreasing of the modulus can be important and the damage can be greater than that obtained for a static loading, generally limited to 0.5 (Fig. 7).

Constant load test

After static tests, "damage-creep" test during a relatively long term are achieved. For a constant stress, the strain and damage significantly progress to cause the specimen rupture. The stress in terms of the strain are plotted (Fig. 8) and a ratio in the order of three between the initial and the final modulus are noticed. Damage in terms of the time is also plotted (Fig. 9). Again, the damage rate (0.7) is higher than the static test (0.5).

Fatigue versus constant load

The comparison of the evolution of the stress level (maximum in case of fatigue) with respect to the time is shown Fig. 10. The evolution of the damage until the fracture of the specimen is higher for cyclic loads that for constant laod, when the level of the stress is not to high.

Conclusions

A first experimental study showing the evolution of matrix damage in the case of a constant load is presented here. It is concluded that this evolution exists and is less important (with respect to time) that for cyclic laods. The next step will be the definition of a model at the level of the ply and the validation in case of any laminate.

Figure 1 .

 1 Figure 1. Cylindrical structures.

Figure 2 .

 2 Figure 2. Specimen shape.

Figure 3 .

 3 Figure 3. Shear behavior on [45°,-45°]ns.Figure 4. Transverse behavior on [90°]ns.

Figure 4 .

 4 Figure 3. Shear behavior on [45°,-45°]ns.Figure 4. Transverse behavior on [90°]ns.

Figure 5 .

 5 Figure 5. "Transverse behavior" on [60°,-60°]ns.

Figure 7 .

 7 Figure 7. Damage evolution in fatigue.

Figure 8 .

 8 Figure 8. Damage evolution with a contant load.Figure 9. Damage evolution in terms of time.

Figure 9 .

 9 Figure 8. Damage evolution with a contant load.Figure 9. Damage evolution in terms of time.

Figure 10 .

 10 Figure 10. Stress evolution in terms of time.