Mohamed Hedi Karray

Brigitte Chebel-Morello

Noureddine Zerhouni

Brigitte Chebel Morello

Towards a maintenance semantic architecture

Keywords: maintenance systems, e-maintenance, interoperability, semantic maintenance, ontology. 1

come

INTRODUCTION

Today's enterprise must respond to increasingly demands in terms of quality and quantity of products and services, responsiveness and costs reducing. To deal with these demands, company must have a reliable production system, well maintained by an efficient and inexpensive maintenance system. A performance and well-organized maintenance service contributes to the production system consistency, it will extend the life of industrial equipment and thus the best overall performance throughout the company. This need for maintenance concerns any type of enterprise, industry or service provider.

Since the 80'Th, a phase of maintenance services structuring and standardization is being established. Markets' evolution, globalization and their emphasis on profit and competitiveness of the firm cause the development of new concepts of production organization as well as the maintenance organization. At the same time, the quality aspect is beginning to play an important role as well as the dependability and, specifically, the maintenance function in companies.

New technologies of information and communication technologies (ICT) have helped to establish and evolve these roles. Thanks to ICT, Web emergency and Internet, the achievement of maintenance services and monitoring can be performed automatically, remotely and through various distributed information systems. Hence the emergence of the concept of services offered through maintenance architectures, ranging from autonomic systems to integrated systems where cooperation and collaboration are vital to any operation.

On the other hand, the set up of these fundamental aspects is a complex task. Thus we are particularly interested in the type of exchanged information, and the complex relationships between different systems and applications in these architectures. At this level, we are confronted to a classical problem in information systems, which is interoperability. This latter means the ability of two or more systems or components to exchange information and to use the information that has been exchanged [1].

In this paper we focus on the semantic interoperability of this exchanged information and how it can grantee an understandable exchange and to evolve existing architecture form static architecture to an intelligent one based on knowledge. To make that, we build a maintenance ontology, which will be shared between different systems of the architecture.

The objective of this paper is twofold: (i) recense existing maintenance architectures and (ii) propose a new generation of maintenance architecture semantically interoperable.

The rest of the paper is organised as follow. Section 2 is devoted to present the complex characteristics of systems and its relations. Section 3 and 4 are devoted to tale maintenance system historic and various existed maintenance architectures. We present in section 5 the semantic interoperability problematic and its importance to set up the s-maintenance architecture. In the next section 6 we build a domain ontology of maintenance based on the analysis of the maintenance processes. Future work about our ontology use and evaluation and the conclusion are developed consequently in sections 7 and 8.

COMPLEX SYSTEMS CHARACTERISTICS

We develop in this section two classification criteria for characterizing software architectures from a macroscopic view freeing details to be studied (the protocols ...) when we want to improve these architectures, including the e-maintenance.

Information evolution

The information used in different applications in the field of maintenance has changed in the light of information technology developments and depending on the complexity of the industrial environment.

In the past, this information has been manually entered on paper (drawings, diagrams, manuals) and was verbally exchanged between operators in an informal way. Unlike today, the information is different. It has become formalized and structured to be manipulated by information systems. At the same time, enterprise environment becomes increasingly complex and production systems are becoming more dynamic, which makes the context of the information's use more variable and unstable. Information is uncertain; it evolves with the changing context. The way to reduce this uncertainty is through the implementation of this information in a context with meaning and direction, by turning it into knowledge in a given objective. This knowledge then becomes, along with other information and knowledge a source to acquire skills. Today's information systems handle this knowledge to provide a decision support for its users on problem solving and to improve their skills in this field.

Relations between systems

Thanks to technological and informatics evolution, information systems which were independent and autonomous begin to cooperate by exchanging and sharing information. More recently, new information technologies and communication (ICT) have enabled the migration of these different systems into an integrated system where cooperation and collaboration are essential to any operation. There are different types of relationships between systems under review and will be the basis for the classification of different architectures in maintenance (see Figure 1). -Autonomy relationship is a regime under which a system has the maximum power of management and is independent of all other systems and components. There is communication between systems and it must be self-sufficient in terms of necessary information.

-Communication relationship is a link between two or more systems that allows transfers or exchanges. The information transmitted in the communication is no longer limited to alphanumeric characters and also include images, sound and video clips. In this context, the term communication is often used as synonymous with telecommunications.

-The cooperative relationship presents a cooperative work being done by a work division in which each actor is responsible for part of the resolution of the problem. In our context, it is mainly technological and industrial cooperation, therefore, a cooperative agreement between independent systems that are committed to carry out joint production of maintenance services.

-The collaborative relationship is a strategic partnership to achieve excellence through a combination of skills, suppliers or products. Collaboration involves a mutual commitment of stakeholders in a coordinated effort to resolve the problem by pooling resources, information and skills to better adapt to their environment organizations.

HISTORY OF MAINTENANCE'S COMPUTING SYSTEM

The development of computer systems in the field of industrial maintenance began when the maintenance has been recognized as a fundamental function in the company and a particular stress was laid on the study and development of procedures of this function.

Information used in maintenance has changed in according to the evolution of information technologies and in according to the growth of enterprise environment complexity. The information structure has changed in order to be handled by information systems.

We can identify various aspects in the evolution of computer system maintenance [START_REF] Francastel | Externalisation de la maintenance : Stratégies, méthodes et contrats[END_REF][START_REF] Boucly | Le management de la maintenance : Evolution et mutation[END_REF]:

-Computerization of the procedures of maintenance: The automation of the business management allowed computerizing several maintenance procedures. Computer files of equipment, interventions, stocks, plans and diagrams etc were thus created. The integration of these files and the automation of the maintenance activities were possible thanks to CMMS packages (Computerized Maintenance Management System). The daily events of maintenance were treated: the blackout, preventive execution, stocks management.

-Interfacing with software packages: Thereafter, these software packages had to interface with the other enterprise software such as purchasing and accounting, already computerized. Large ERP systems (Enterprise Resource Planning) are a next step in streamlining the business processes and integration of maintenance with other corporate functions.

-Evolution of the technical field: Informatics has also made progress in the technical field of maintenance. Modern techniques of analysis of maintenance and control have emerged in parallel computing: vibratory analysis, oil analysis, IR thermography, hot ultrasounds etc. We can distinguish among these systems two main groups: analysis systems and acquisition and control systems. * Analysis systems, sometimes coupled with expert systems have been developed. The analysis systems are also intended to provide decision support in diagnosis, prognosis and repair of equipment operators, etc… * Among the acquisition and control systems, we can quote SCADA (supervisory control and data acquisition), command-control of the equipment, technical data and documentation management systems, etc… -Integration of intelligent modules in maintenance architecture: The presence of these various intelligent modules of maintenance leads us to make them communicate and collaborate. The construction of intelligent modules or bricks must contribute to provide indicators to make the right strategic decision and maintenance policy.

-Development of ICT: The development of new information and communication technologies, the extension of the Internet in the enterprise, application integration, and the emergence of new policies for maintenance indicate a new stage for the computerization of maintenance, that which some call "maintenance Intelligent". This leads to cooperative and distributed architectures of maintenance systems communicating between them or on a basis of networks. Implementation of these maintenance architectures can be done using maintenance platforms whose main idea is to offer a maintenance service via internet. Maintenance platforms proposed in Proteus or OSA / CBM projects can serve as examples.

DEFINITIONS OF VARIOUS ARCHITECTURES

We propose a terminology characterizing the various computer systems in maintenance and we classify those under two areas: the type of information used in the system and the intensity of a possible relationship with other systems (see Figure 2). More the relation is intense more the systems are connected and integrated and we speak about common architectures to be implemented across platforms. The volume of automatically managed information is concretized by the surface of the square of each system and increases with the intensity of collaboration and also with the complexity of shared information. We note that there is a parallel between our classification of systems and enterprises classification as presented in several work [START_REF] Dedun | Les systèmes d'information interorganisationnels comme médiateurs de la construction de la collaboration au sein des chaînes logistiques : Du partage d'information aux processus d'apprentissages collectifs[END_REF].

Figure 2. Maintenance architectures classification -The maintenance system includes a single computer system on this site and used on the site of maintenance. This system is autonomous with data exchange with other systems. In parallel with the classification of companies, this corresponds to the traditional company; therefore we are talking about a traditional architecture of an information system.

-The system of remote maintenance consists of at least two computer systems a transmitter and a receiver of data and information distantly exchanged. According to the definition of AFNOR remote maintenance is "the maintenance of a well executed without physical access of the staff to the equipment". We are talking about a distributed architecture, based on the concept of distance that can transfer data by radio, telephone line or through a local network.

-With the extension of Internet, the systems of remote maintenance emergent towards the concept of E-maintenance. The system of e-maintenance will be implemented on a platform integrating various cooperative distributed systems and maintenance applications. This platform must take support on the global Internet (from where the E-maintenance term) and Web technology allows to exchange, to share and distribute data and information and to create common knowledge. Here the concept intelligent maintenance can be exploited and the proactive and cooperative strategies of maintenance are installed.

-Finally, we propose an architecture intended to improve the performance of the architecture of E-maintenance on the level of the communication and exchange of the data between systems and which makes it possible to take account of the semantics of processed data in the applications -S-maintenance (where " S " means semantic) [START_REF] Rasovska | Process of s-maintenance: decision support system for maintenance intervention[END_REF]. We will describe with section 5 this concept which takes support on semantic-knowledge via an ontology of maintenance.

Maintenance

This is the basic notion where the system is completely autonomous. AFNOR defines it as "combination of all technical, administrative and managerial actions during the life cycle of an item intended to retain it in, or restore it to, a state in which it can perform the required function".

A maintenance system is represented by an application for maintenance or reliability of the various activities of the maintenance function such as logistics, planning interventions, inventory (managed by the CMMS, ERP), diagnosis and repair (expert systems, databases), monitoring equipment (SCADA, digital control equipment). The architecture of these systems can range according to various objectives. Therefore we propose to describe architectures of these systems by a generic scheme valid for any enterprise system. This scheme consists of two main parts, namely the physical system and management system. This latter produces the whole of the results or decisions based on information coming from the physical system [START_REF] Kaffel | La maintenance distribuée: concept, évaluation et mise en oeuvre[END_REF]. The acquisition of information is manual or rather limited in its automation and the decisions are thus done by the intermediary of an information system.

Remote maintenance

The architecture of remote maintenance consists of two or several systems or subsystems apart from each other and exchange data between them. One of the systems can function as a data acquisition system, representing the issuer of structured data. The second system is the receiver, functioning as a data processing system. The transmitter can send data automatically or in response to a request from the receiving system data.

The results of data processing (output) are used by human actors or may be referred to the purchasing system to arrange the data acquisition. So that data can be exchanged and acceptable by both systems they must be structured. Always by keeping the aspect of distance, remote maintenance can be installed on only one production site as it may be distributed among different production or maintenance site and/or a maintenance center. An example of remote maintenance architecture (cf figure 3) was created in the project TEMIC (Industrial Cooperative Remote Maintenance) which allowed cooperative remote maintenance: not only maintenance staff can perform work at a distance (remote maintenance) but it can do it in collaboration with other experts (cooperative work).

Emphasis was placed on the mobility aspect of the cooperating members on several levels:

-Distant Level: the actors of remote maintenance will be reachable wherever they are via the mobile network (GSM / GPRS).

-Local Level (nomadism): by detection of the presence of remote maintenance actors in a preset perimeter (about 100m) within the company which manages maintenance, to join the most experienced technician on a particular problem.

E-maintenance

The architecture of e-maintenance is done via Internet that allows to cooperate, exchange, share and distribute information to various partner systems of the network (see figure 4). The principle consists in integrating the whole of the various systems of maintenance in only one information system [START_REF] Muller | Contribution à la maintenance prévisionnelle des systèmes de production par la formalisation d'un processus de pronostic[END_REF]. Systems offer different formats of information that are not always compatible for sharing; this requires coordination and cooperation between systems to make them interoperable. According to [START_REF] Spadoni | Système d'information centré sur le modèle CIMOSA dans un contexte d'entreprise étendue[END_REF], interoperability is "the ability of two communication systems to communicate in an unambiguous way, such systems are similar or different. One can say that making interoperable is creating compatibility". The architecture of e-maintenance must ensure interoperability between each of these different systems.

The project MIMOSA (Machinery Information Management Open Systems Alliance) was the first in 90th years in the United States to develop a complex information system for maintenance management [START_REF] Kahn | Overview of MIMOSA and the Open System Architecture for Enterprise Application Integration[END_REF]. The project aimed to develop a collaborative network of maintenance by providing the open standard protocol EAI (Enterprise Application Integration). The organization recommends and develops characteristics of information integration to allow the management and the control of added value by the opened, integrated and industry oriented solutions. This latter developed from information blocks to create e-maintenance platform have been proposed in this project [START_REF] Mitchell | MIMOSA -Four Years Later[END_REF]. A functional architecture OSA / CBM (Open System Architecture for Condition-Based Maintenance) dedicated to the development of strategies for conditional or predictive maintenance [START_REF] Lebold | Open standards for Condition-Based Maintenance and Prognostic Systems[END_REF] was developed from the relational schema MIMOSA CRIS. It contains seven flexible modules whose contents (methodology and algorithms) are configurable by the user (cf figure 5). It can be simplified and adapted to each industrial requirement by reducing modules.

Figure 5. OSA/CBM project An E-maintenance architecture was presented in the European project Proteus (cf figure 6). The project was designed to provide a cooperative distributed platform of E-maintenance including the existing systems of data acquisition, control, maintenance management, diagnosis assistance, management of documentation, etc. The concept of this platform is defined by a single and coherent description of the installation to maintain, through a generic architecture based on the concepts of Web services and by proposing models and technological solutions of integration. These techniques help to guarantee interoperability of heterogeneous systems to ensure the exchange and sharing of information, data and knowledge. The aim of the platform is not only to integrate existing tools, but also to predict the evolution of these through the introduction of new services. Figure 6. Proteus e-maintenance plateforme[wwww.proteus-iteaproject.com] Web services were conceived to guarantee interoperability between the various applications of the platform. But they prove that interfaces interconnection protocol does not treat semantics of the output and input data. XML used as bases for data exchange manages structures punts and must be used with the RdF standard to guarantee the bonds between these entities. This architecture guarantees technical interoperability -link between IT systems and services which they provide but does not take account of the semantic interoperability, which consists in giving "Meaning" (semantics) to exchanged information and to make sure that this meaning is distributed in all the interconnected systems. Taking into account this semantics makes possible these systems to combine the information received with other local information and to treat them in a suitable way compared to this semantics [12].

The European project PROMISE (Product Lifecycle Management and Information Tracking Using Smart Embedded Systems) [START_REF] Lee | Infotronics-based intelligent maintenance system and its impacts to closed-loop product life cycle systems[END_REF] proposes a closed-looped design and lifecycle management system. The objective of PROMISE is to allow information flow management to go beyond the customer, to close the PLC (Product Lifecycle) information loops, and to enable the seamless e-transformation of PLC information to knowledge [START_REF] Kiritsis | Ubiquitous product lifecycle management using product embedded information devices[END_REF]. This project focused in three working areas related to e-maintenance issues [START_REF] Muller | On the concept of e-maintenance: Review and current research[END_REF]:

-Area 1: E-maintenance and e-service architecture design tools (design of e-maintenance architecture as well as its platform for e-service applications).

-Area 2: Development of watchdog computing for prognostics (development of advanced hashing algorithm for embedded product behaviour assessment and prognostics).

-Area 3: Web-based and tether-free monitoring systems (development of ''interface technologies'' between the product eservice system platform and Web-enabled e-business software tools). DYNAMITE (Dynamic Decisions in Maintenance) is an European project which aims to create an infrastructure for mobile monitoring technology and create new devices, which will make major advances in capability for maintenance decision systems incorporating sensors and algorithms [START_REF] Holmberg | Prognostics for industrial machinery availability[END_REF]. The key features include wireless telemetry, intelligent local history in smart tags, and on-line instrumentation [START_REF] Muller | On the concept of e-maintenance: Review and current research[END_REF].

In [START_REF] Muller | On the concept of e-maintenance: Review and current research[END_REF], Iung et al outline most e-maintenance platforms in order to evaluate their capacity from different points of views as collaboration, process formalization, knowledge management, knowledge capitalization, interoperability, etc… In term of knowledge capitalization the major contribution has especially provided by OSA-CBM and Promise Project platform. This latter has the major contribution in the context of knowledge management too. Regarding interoperability, MIMOSA and OSA-CBM standards have the most relevant contribution in this topic. On the other side, Iung et al didn't talk about semantic interoperability, and in our knowledge, existing platforms do not focus on this issue. Hence, in this work we stress this problematic and we present s-maintenance ("S" for semantic) architecture which guarantee a high level of semantic interoperability between the various systems of the maintenance platform.

SEMANTIC INTEROPERABILITY IN MAINTENANCE ARCHITECTURES

We seek to set up an architecture treating of the semantic interoperability of data.

Semantic interoperability

The IEEE Standard Computer Dictionary defines interoperability as the "ability of two or more systems or components to exchange information and to use the information that has been exchanged" [1]. From this definition it is possible to decompose interoperability into two distinct components: the ability to exchange information, and the ability to use the information once it has been received. The former process is denoted as 'syntactic interoperability' and the latter 'semantic interoperability'. A small example suffices to demonstrate the importance of solving both problems. Consider two persons who do not share a common language. They can speak to one another and both individuals will recognize that data has been transferred (they can also probably parse out individual words; recognize the beginning and end of message units, etc.). Nevertheless, the meaning of the message will be mostly incomprehensible; they are syntactically but not semantically interoperable. Similarly, consider a person who is blind and one who is deaf, but who both utilize a single language. They can attempt to exchange information, one by speaking and one by writing, but since they are incapable of receiving the messages, they are semantically but not syntactically interoperable [START_REF] Komatsoulis | caCORE version 3: Implementation of a model driven, service-oriented architecture for semantic interoperability[END_REF]. In other words, Semantic interoperability ensures that these exchanges make sense-that the requester and the provider have a common understanding of the "meanings" of the requested services and data [START_REF] Heiler | Semantic Interoperability[END_REF].

Achieving semantic interoperability among different information systems is very laborious, tedious and error-prone in a distributed and heterogeneous environment [START_REF] Mao | Ontology mapping: Towards semantic interoperability in distributed and heterogenous environments[END_REF]. Currently it interests various works which was classified according to Park and RAM [START_REF] Park | Information System Interoperability: What Lies Beneath?[END_REF] in three broad approaches:

1. Cartography interoperability (mapping based approach). It aims to build cartographies between data or elements of models semantically connected [START_REF] Baïna | Apport de l'approche MDA pour une interopérabilité sémantique[END_REF]. A set of transformation Rules are installed to translate or federate local pattern with a global pattern. One therefore adopts an approach to study semantic interoperability via transformation [START_REF] Rahm | A survey of approaches to automatic schema matching[END_REF][START_REF] Halevy | Composing mappings among data sources[END_REF].

2. Interoperability by interoperable languages. These query languages take into account data and metadata to solve semantic conflicts between several data bases interrogation [START_REF] Fauvet | Evaluation coopérative de requêtes sur des données semi-structurées distribuées[END_REF].

3. Interoperability through intermediate mechanisms such as mediators or agents. These mechanisms must have a specific knowledge of the area to coordinate different data sources generally via ontologies [START_REF] Maedche | Semi-automatic engineering of ontologies from texts[END_REF][START_REF] Halevy | Schema mediation for large-scale semantic data sharing[END_REF] or via middleware like the Common Object Request Broker Architecture (CORBA) which based on metadata messaging to facilitate interoperability at each level [START_REF] Tannenbaum | Repositories: potential to reshape development environment[END_REF].

Other promising ways are presented by Chen et al in [START_REF] Chen | Architectures for enterprise integration and interoperability: Past, present and future[END_REF] who propose two new approaches to resolve semantic interoperability, a model driven interoperability architecture and a Service oriented architecture for interoperability. The model driven interoperability (MDI) architecture based on MDA and enterprise interoperability concepts. The objective of this approach is to allow transforming automatically the models designed at the various abstraction levels of the MDA structure [29]. The service oriented interoperability is based on a Service-Oriented Architectures adopting a federated approach [START_REF]Concepts and Rules for Enterprise Models[END_REF], i.e. allowing interoperability of services 'on the fly' through dynamic accommodation and adaptation.

As for the above classified approaches, we choose the approach of intermediate mechanisms using ontology engineering. Indeed, Heiler, Mao et al, Yang et al and others researchers are in agreement that ontology engineering is recognized as the key technology to deal with the semantic interoperability problem [START_REF] Heiler | Semantic Interoperability[END_REF][START_REF] Mao | Ontology mapping: Towards semantic interoperability in distributed and heterogenous environments[END_REF][START_REF] Yang | Semantic interoperability in building design: Methods and tools[END_REF]. Ontologies specify the semantics of terminology systems in a well defined and unambiguous manner [START_REF] Guarino | Formal ontology and information systems[END_REF], by formally and explicitly representing shared understanding about domain concepts and relationships between concepts. In the ontology based approach, intended meanings of terminologies and logical properties of relations are specified through ontological definitions and axioms in a formal language, such as OWL (Web Ontology Language) [START_REF]W3C OWL Web ontology language overview[END_REF] or UML (Unified Modelling Language) [START_REF] Cranefield | UML as an ontology modelling language[END_REF]. This agreement seems promising to us and supports the work of knowledge management which we implemented on a repair and diagnosis module applied to an E-maintenance platform [START_REF] Rasovska | Process of s-maintenance: decision support system for maintenance intervention[END_REF]. One of the problems arising from this approach is the definition of common ontology. In our case related to a business approach on maintenance, an ontology relating to the equipments was made during the development of the E-maintenance platform within the framework of European project PROTEUS. The conceived ontology, oriented towards a business approach for the maintenance of industrial equipments, is a common denominator between the various applications implemented in an E-maintenance platform. However this ontology was not exploited by all assistance modules of the platform, but only by our assistance module of diagnosis and repair. This did not guarantee the semantic interoperability of the platform.

We propose to generalize with the other applications of maintenance assistance, the use of common ontologies in order to guarantee this semantic interoperability. An obstacle to such use is to have a knowledge management approach during the development of the assistance maintenance systems.

S-maintenance architecture

The architecture of S-maintenance platform takes support on the architecture of E-maintenance where the interoperability of the various integrated systems in the platform is guaranteed by an exchange of knowledge represented by an ontology. So that information sharing in the E-maintenance cooperative network is without difficulty, we are required to formalize this information in a way to be able to exploit it in the various systems belonging to the network. We are extending coordination between network partners and we develop an ontological base of the sharing information. Systems share the semantics created for the common architecture of the E-maintenance platform (cf figure 7). This terminological and ontological base models the whole of knowledge of the domain. It will play the role of a memory to set up a knowledge management and capitalization system and to thus exploit the experience feedback to improve maintenance system functioning. This system will use the knowledge engineering tools as well as knowledge management. The software tool must play the role of service integrator able to be connected to the other systems, specific to companies.

This knowledge system makes possible to identify, capitalize and restore necessary knowledge to control, using a support environment [START_REF] Kramer | Proteus: Modélisation terminologique[END_REF]. Semantics has three levels, namely the general concepts of maintenance, application domain concepts, and specific concepts to each company. This system takes support on the concept of E-maintenance with an exchange of information either on the Web services but requiring additional constraints based on standard "OKC" resulting from the semantic Web. The semantics of exchanged information requires the creation of a domain ontology common to the various systems. It allows using and creating knowledge and skills which lead to the use of knowledge management techniques and allows capitalizing acquired knowledge. Systems collaborate, which requires a coordinated effort to solve problems.

DOMAIN ONTOLOGY OF MAINTENANCE

Several research works tried to build a maintenance ontology. In the software maintenance area , KITCHENHAM et al in [START_REF] Kitchenham | Towards an Ontology of Software Maintenance[END_REF] suggest that empirical studies of maintenance are difficult to understand unless the context of the study is fully defined. We developed a preliminary ontology to identify a number of factors that influence maintenance. The purpose of the ontology was to identify factors that would affect the results of empirical studies. We present the ontology in the form of a UML model. Ruiz et al in [START_REF] Ruiz | An ontology for the management of software maintenance projects[END_REF] developed a semi-formal where the main concepts, according to the literature related to software maintenance, have been described. This ontology, besides representing static aspects, also represents dynamic issues related to the management of software maintenance projects. REFSENO (A Representation Formalism for Software Engineering Ontologies) [START_REF] Tautz | A Representation Formalism for Software Engineering Ontologie[END_REF] was the methodology used in this work. Matsokis and Kiristis in [START_REF] Matsokis | An Ontology-based Approach for Product Lifecycle Management[END_REF] propose an ontology-based approach for product lifecycle management, as extension of the ontology proposed in Promise project [40]. This latter provide a Semantic Object Model for Product Data and Knowledge Management. The SOM provided a commonly accepted schema to support interoperability when adopted by different industrial partners.

However, these works can be analyzed within two points of view: what does it present? And what does it regard? The two first works try to conceptualize the entire maintenance domain; nevertheless the second two works focus only on the product lifecycle and essentially the middle of life phase [START_REF] Kiritsis | Research issues on product lifecycle management and information tracking using smart embedded systems[END_REF]. Within the second point of view last works regard to ensure interoperability between industrial partners contrariwise to the first two works which especially aim to ensure the best management of software maintenance and reuse activities.

Thus, we develop a general product maintenance ontology which covers the whole of the maintenance domain having the goal to ensure semantic interoperability among different systems in the maintenance platform.

We take advantages of the classification made by Rasovska et al in the study of maintenance process [START_REF] Rasovska | A conceptual model of maintenance process in unified modeling language[END_REF] to set up our ontology. In fact, like shown in figure 8, authors define four fundamental technical and business fields, identified in the general maintenance: (i) equipment analysis which consists of functional analysis and failure analysis; (ii) Fault diagnosis and expertise which aim to help the operator, during his intervention, to diagnose the problem and the prognostic to anticipate the breakdown and to solve it without the recourse to an expert; (iii) Resource management which deals with the resource planning for all maintenance interventions; (iv) Maintenance strategy management which represents decision support concept for maintenance managers.

Fault diagnosis and expertise

Resource management

Maintenance strategy (contract) management Equipment analysis Figure 8. Maintenance process concepts Based on the study of the maintenance process, dependability concepts and maintenance experts practice, we developed this ontology of maintenance expertise including maintained equipment model associated to maintenance system components as an UML class diagram.

The choice of UML as language of our ontology is based on its graphical expressivity's and the semantics' power recommended in various research works. Cranefield et al in [START_REF] Cranefield | UML as an ontology modelling language[END_REF] focus on the benefits of using UML as an ontology's language, Bézivin et al in [START_REF] Bézivin | De la programmation par objets à la modélisation par ontologie[END_REF] stresses that the meta-models (e.g. UML) in the sense that they are used in the OMG (Object Management Group) address the concept of representation and more specifically to the ontology definition presented in [START_REF] Charlet | Ontologie et réutilisabilité : expérience et discussion[END_REF].

We have built our own framework, so that from its conception it takes into account the different scope of the maintenance process. This ontology was developed as a tool for sharing semantic between different actors in the e-maintenance platform.

The ontology of the domain, although established independently of the methods of reasoning has a structure which depends on how acquired knowledge will be used for reasoning because experts deliver the knowledge adapted to their reasoning.

The model domain consists of twelve parts (i.e. packages) corresponding to both the structure of the enterprise memory and the maintenance process (see Figure . 9). There are the monitoring management system, site management system, equipment expertise management system, resource management system, intervention management system, the maintenance strategy management model, maintenances management system, equipment states system, historic management system, document management system, functional management system, dysfunctional management system.

The equipment expertise management system is characterized on the one hand, by the equipment components and sub components in a tree form (Component).

Site management system: defined as a unity characterized by emplacement. This site can be a production site which contains operating equipments or a maintenance centre which is the central location to operate and maintain equipments.

Equipment states system: during its operation, equipment may be in one of the following states: Normal state, Degraded state, Failure state, Programmed stop state. We include in programmed stop any stopping of the carried equipment by the authorized personnel. Among scheduled stops, we are interested only to maintenance.

Maintenances management system: this package is related with programmed stop included in the equipment state system. This package manages the different types of maintenance, which are corrective maintenance, conditional maintenance, and preventive maintenance. The monitoring management system consists of sensors (sensor) installed on the equipment and various measurements (Measure) coming from these sensors. A model of data acquisition (Data acquisition model) manages the acquisition and the exploitation of these measures. This model can trigger the procedure of intervention request according to a threshold measures and is therefore connected with the intervention management model. The intervention management system focuses on the maintenance intervention. Intervention lets to remedy the equipment failure and is described by an intervention report and characterized by maintenance type.

The maintenance strategies management system is based on technical indicators (Technical indicator) and financial (Financial indicator) for each equipment in a maintenance contract. The resources management system describes the resources used in the maintenance system, namely human, material, document and their subclasses: operators (Operator), expert (Expert) and manager (Manager) are subclasses of human resource. Tools (Tool), consumables (consumable) and spare parts (Spare part) are subclasses of material resource. The document resource and their subclasses are presented in a separated package. Document management system: this package presents documentation resources which are indispensable in maintenance as: the equipment plan which contains the design and the model of the equipment and its components, technical documentation where is defined all technical information of an equipment and its use guide, contract which presents maintenance contract, and finally intervention report. This latter is composed by observation, work order, technical comments. Functional equipment management system functional analysis and associated model (Functional equipment model) characterize the equipment operation by MainFunction and SecondFunction classes. They represent the equipment main and secondary functions to ensure the running smooth of the main function. Dysfunctional equipment management system each equipment can suffer from breakdowns and failures described in the Failure class and analyzed in the failure Analysis (Failure equipment model). A failure is identified by symptoms (symptoms) caused by origins (Origin) and remedied with a remedial action (Action). It also has characteristics (Characteristics) such as criticality, appearance frequency, non detection and the gravity which are evaluated in the FMECA (Failure Mode, Effects and Criticality Analysis).

Historic management system contains life history which stocks the life historic of an equipment. It is composed by equipments states, interventions and different measurements of the monitoring system. Modelling the domain ontology is very beneficial. But how can we exploit this benefice?; is the question which must be responded. Presenting the ontology via UML class diagram is very beneficial in term of clearness and comprehensibility, but it does not allow the ontology evaluation and the ontology use in the e-maintenance platforms. In other words, we cannot validate the ontology's reasoning, soundness and completeness [START_REF] Uschold | Ontologies: Principles, methods and applications[END_REF], and we cannot navigate on an UML class diagram. The ontology must be translated to an ontology language allowing reasoning and understandable [START_REF] Uschold | Knowledge Level Modelling: Concepts and Terminology[END_REF] by the technical components of the platform which use the ontology. Currently we are working to evolve this ontology by the translation on a description logic language to allow the reasoning on the ontology and to implement it throw an interpreted or compiled language. This will permit to us the study of our ontology capacity and quality to guiding us to trails and areas of the ontology development.

In the other hand, we aim to enrich this domain ontology models by adding more concepts and more information to cover all domain areas which can be used to evolve the e-maintenance platform. In the same time we aim to relate this domain ontology with a task ontology providing dynamic activities in the maintenance system as diagnostic, prognostic, detection, acquisition, etc…

CONCLUSION

To improve system availability and safety as well as product quality, industries are convinced by the importance role of the maintenance function. Consequently various works are made to evolve this latter. Taking advantages of new information technologies -which allow the integration of various assistance systems via platforms-these works permit to expand and develop maintenance systems.

In this paper we proposed a classification of various existing maintenance architectures to infer a support system architecture for maintenance services. This classification is made according to relations intensity between systems (autonomy, communication, cooperation, collaboration) in a particular architecture. Collaborative or cooperative relation generates a problem on the interoperability level between the architecture systems. The semantic interoperability is considered as one of the complex interoperability's problems that is why we focus on it in this paper. Thus we highlighted the semantic maintenance architecture (S-maintenance) which is based on a common ontology for various systems. Indeed, this developed ontology witnesses a semantic interoperability level. This ontology is related to the maintained equipment and common for the platform to guarantee interoperability between integrated systems and applications. It is based on the maintenance process, dependability concepts and maintenance experts practice, including maintained equipment model associated to maintenance system components as an UML class diagram. The choice of UML as language of our ontology is based on the power graphical expressivity and the semantic of this language. To be operational this class diagram will be translate to an ontology language allowing reasoning like OWL DL language or LOOM.

Figure 1 .

 1 Figure 1. Relationship intensity between systems.

Figure 3 .

 3 Figure 3. Example of remote maintenance architecture

Figure 4 .

 4 Figure 4. E-maintenance architecture.

Figure 7 .

 7 Figure 7. S-maintenance architecture

Figure 9 . 7 FUTURE

 97 Figure 9. Domain ontology of maintenance


Shahram Nourizadeh
email: shahram.nourizadeh@loria.fr

Y Q Song
email: song@loria.fr

J P Thomesse
email: thomesse@loria.fr

A Distributed Fuzzy-based Failure Management for Wireless Sensor Networks

Keywords: Failure management, Wireless sensor networks, distributed algorithm, Fuzzy logic I

In addition to limited energy resources in wireless sensor networks, failure of the nodes is a constraint to provide a reliable communication. As the failure of a node may have many reasons like mobility of the node and node or link failure, it is clear that in a real environment, we cannot control or reduce the number of failure in a network but it's possible to manage it. In this paper, we propose a technique to improve routing protocols by considering both energy and failure constraints and managing them. By using this technique, the routing protocols dynamically adapt to nodes' failure. The simulations results show the efficiency of this technique in two sample routing protocols.

INTRODUCTION

Wireless Sensor networks have recently emerged as a premier research topic. Generally, the communication in sensor networks, with battery powered nodes, suffers from failure, low transmission power even more so than in regular wireless networks. Despite of many research projects, failure management in sensor networks is an open research challenge. Nodes' mobility, communication problem and link failure may be detected as a failure, on the other hand, in some networks, like healthcare networks, failure of a sensor can be detected as a health anomaly. These 2 cases can cause false alarms.

Let's continue with our last example, healthcare networks. A healthcare network is resource-constrained medical sensor network which is deployed in an environment like patient's home or a hospital, in order to collect data about some vital signs. The main objective of a healthcare network is the gathering the health information of the patient and delivering them to a server in which the information will be saved in a medical record and also will be processed to detect any abnormally in health state of the patient. Node's or link's failure is one of the common problems in healthcare networks that causes faulty alarms. If the network doesn't be able to grantee a robust data delivery, the healthcare system will have a lot of fault alarm.

For these reasons, it is essential to provide failure management techniques for distributed ad-hoc networks, and particularly healthcare sensor networks. Many recent studies in this area take drastically different approaches to addressing the fault tolerance issue in routing, transport and/or application layers. In addition, in the ad hoc networks, due to the mobility of the nodes and we have faulty alarm problem.

Implementing failure detectors over local networks is, by now, a rather well-known issue, but it is still far from being a solved problem with wireless sensor networks. But traditional solutions fail to solve important problems such as the potentially large number of monitored processes, the higher probability of message loss, the ever-changing topology of the system, and the high unpredictability of message delays [START_REF] Hayashibara | The F Accrual Failure Detector[END_REF].

A number of high profile applications for wireless sensor networks have been envisioned [START_REF] Weiser | The Computer of the Twenty-First Century[END_REF][3] [START_REF] Estrin | Embedding the Internet: Introduction[END_REF]. Fault tolerance in measurements by a group of sensors, was first studied by Marzullo [START_REF] Marzullo | Tolerating failures of continuousvalued sensors[END_REF]. Marzullo proposed a flexible control process program that tolerates individual sensor failures. Issues addressed include modifying specifications in order to accommodate uncertainty in sensor values and averaging sensor values in a fault-tolerant way.

[6] developed an algorithm that guarantees reliable and fairly accurate output from a number of different types of sensors when at most k out of n sensors are faulty. The results of the scheme are applicable only to certain individual sensor faults and traditional networks. They are not extendable to the reliability needs in complex network levels and most importantly; they do not address the reliability issues that are induced by the ad-hoc nature of the wireless sensor networks.

Multi-sensor data fusion is a problem that recently has attracted a great deal of attention in a number of scientific and engineering communities [START_REF] Brooks | Multi-Sensor Fusion: Fundamentals and Applications With Software[END_REF][8] [START_REF] Hager | Task-Directed Sensor Fusion and Planning -A Computational Approach[END_REF]. Majority of these works are restricted to sensor fusion of sensors of the same modality.

The remainder of this paper is structured as follows: section II discusses challenges. Our proposal is described in section III, while our simulations are resented in section IV and section V provides concluding remarks.

II. CHALLENGES

As we said, the traditional failure management systems fail to address the needs of distributed systems because they are simplify made for wired local area networks and limitedscale systems.

In particular, traditional implementations are not designed to cope with a large number of processes, a high message loss rate, a dynamic network topology, and the unpredictability of wireless sensor networks.

Message loss, Message saving, Mobility and Topology change are some basic problems that failure detection protocols must address in a distributed system. Because of mobility, topology changes and also limited energy resources, in WSNs, a node's failure that sometimes causes network partitions occurs significantly more frequently than in wired LANs.

Network dynamics resulted by node mobility and node state transitions due to the use of power management or energy efficient schemes may be detected as node failures or wireless link failures. Such a highly dynamic network greatly increases the complexity of failure management.

Also, with bandwidth limitation in a sensor network the failure detector must generate a minimum number of control messages.

However, the traditional failure detectors and management systems assume that all of the nodes of the network are synonymous, that means there is no difference between a node that was crashed n times in t hours, with a node that was crashed m times (m>n) in the same period of time. That will causes an unclear decision making and electing between different nodes.

In addition, in the traditional failure detectors, when a node failed, it will be assumed as a dead node and we don't have a return of the node. That will be a restriction, for example, when a node is in maintenance.

For these reasons, we propose an adaptive and dynamic algorithm for failure management in a mobile network. As the failure of a node may have many reasons like mobility of the node and node or link failure, it is clear that in a real environment, we cannot reduce the number of failure but it's possible to manage it, and this is the main idea of our proposal. In our algorithm, the failure history of the nodes is a parameter to differentiate between them.

But, how we can do this? Can we compare the nodes just with their failure history? Which are the best parameters to do this evaluation? Next sections will answer all these questions.

III. PROPOSITION

We assume that all nodes are integrated with a failure detection system and are able to detect the failure. First, in section A, we give the definitions used in the algorithm and in section B we describe the algorithm.

A. Some definitions

 confidence: This parameter shows the level of confidence that we give to a node, and has three possible values: High, Medium, Low. This parameter shows the priority of nodes for taking part of routing.

 failure: This parameter shows history of the failure of a sensor detected by its neighbor. This parameter will be computed by using the number of sensor's failures during its lifetime. It is also a fuzzy variable that has 3 levels: High, Medium and Low.

 energy: this is the battery charge of the node. Like the other parameters, energy is a fuzzy variable with 3 levels: High, Medium and Low.

B. How does it work?

Figure 1 shows as an example a mesh network. The black node is the sink and the others are the wireless mobile nodes. As shown in this figure, the nodes are connected together and we have a P2P connection between them.

By using a traditional failure management algorithm, in this network, all the nodes are equal for us. That means we have not an idea about their failure rate; a node that crashed 10 times and a node that crashed 5 times in the same period, are equal. But by using our algorithm, we will color the network with the confidence level of the nodes.

In our algorithm, each node of the network has a neighbor table which has one row for each neighbor. In a dynamic network, the number of rows changes because of the mobility of the nodes. In this table we keep four parameters for each node: energy, failure, Received Signal Strength Indicator (RSSI) and confidence.

To complete the neighbor table, each node runs a function to compute the confidence parameter of its neighbors. This function uses fuzzy logic [START_REF] Zadeh | Fuzzy Sets, Information and Control[END_REF] [START_REF] Zadeh | Outline of A New Approach to the Analysis of Complex Systems and Decision Processes[END_REF]. We use fuzzy logic because it can manipulate the rules in a natural way, it can be used in context by blending different parametersrules combined together to produce the suitable result. Fuzzy logic is capable of making real time decisions, even with incomplete information.

Note: Instead of fuzzy logic, any another technique or logic can be used.

The confidence parameter is a dynamic parameter which means it can change from Low to High and also High to Low, because the failure parameter is dynamic. Each time the failure of a node change, we will update confidence of the node also. In each node A, failure of its neighbor B will be computed by: failure = fuzzy (n / L); where fuzzy is a function to convert decimal value to fuzzy value, n is number of B's failures and L is the life time of A.

To re-compute the failure and so updating of confidence, we have 2 methods:

1. Periodical update: In each network, due to the mobility or failure frequency of the nodes, base station will define an update period, in which the failure of the neighbors will be recomputed.

2. Event-based update: Each time that a node detects a failure in its neighbor, it re-computes its failure parameter and updates confidence of the node. Figure 2 shows an example of failure re-computing and confidence updating methods. As we can see in this figure, computed confidence for B, in node A, change by frequency of B's failure. If number of B's failure remains constant, its confidence in A will start to increase. Figure 3 shows an example of neighbor table in a sample network. We have the nodes A and B, and their common neighbors, x and y. We can see in this figure that x and y, the common neighbors of A and B, have different levels of confidence in neighbor table of A and B. But how can we explain this?

As we said, we use 3 parameters to compute confidence of each node: its energy level, its RSSI and its failure. The energy level of x will be same in neighbor table of A and B, as the energy level of y. But, RSSI and failure history will be different. A, and B may detect different number of failures in x, and the RSSI may be different because of difference of environmental conditions between the nodes. Therefore in our proposal, even a common neighbor of two nodes, may have different level of confidence in each of them.

Figure 4 shows the fuzzy decision making process. As the energy, RSSI and failure have each of them, 3 possible values, in Inference state, we have in total 27 rules to evaluate for each node.

IV. EVALUATION

This section presents the evaluated performance of our proposition. We integrated OPNET simulators to implement the physical and MAC layer, with an application developed in C to implement Fuzzy rules. Our simulation focuses on the delivery ratio of the network packets as a performance metric and in each step of the simulation; number of faulty nodes is variable.

A. Some assumptions

To evaluate our protocol, and to reduce simulation complexity, to have clear results, we have these assumptions:

 The network consists of several wireless nodes and a base station and nodes have a low mobility.  To focus on the assessment of the performance of the proposed algorithm, we do not generate any user data traffic during a simulation.  All the nodes are able to detect correctly the failure of the other nodes. They can use heartbeat or any other failure detection.  When a node fails or crashes, it is not dead; it will be return to the network after a variable time, t≠∞.

B. Simulation parameters

Table II, shows our simulation parameters. We evaluated our algorithm in a random deployed sensor network, and with 2 different algorithms:

 ZigBee Mesh routing protocol [START_REF]ZigBee routing protocol: Z. Alliance "Zigbee alliance[END_REF]  a cluster based routing algorithm [START_REF] Nourizadeh | A Location-Unaware Distributed Clustering Algorithm For Mobile Wireless Sensor Networks Using Fuzzy Logic[END_REF]

C. Simulation results

In the simulation of our algorithm, we focus on the network delivery ratio. Network delivery ratio is defined as the total received packets divided by the total sent packets in the sensor network. We compared this metrics in normal ZigBee mesh routing protocol with the one that is integrated with our failure management algorithm. Figure 3 shows the result of this simulation. The simulation shows that by applying our algorithm, we can increase the data delivery ratio by 20%. As we can find in this figure, when we have 25% or more of faulty router nodes in a ZigBee network, by applying our algorithm, we have a greater data delivery ratio, compared to a normal ZigBee routing protocol.

We also applied our failure management algorithm, to a clustering protocol [START_REF] Nourizadeh | A Location-Unaware Distributed Clustering Algorithm For Mobile Wireless Sensor Networks Using Fuzzy Logic[END_REF]. We can find the simulation result in figure 4 that compares 2 versions of [START_REF] Nourizadeh | A Location-Unaware Distributed Clustering Algorithm For Mobile Wireless Sensor Networks Using Fuzzy Logic[END_REF]: with and without our algorithm. Simulation results show that by using our algorithm, the data delivery ratio in [START_REF] Nourizadeh | A Location-Unaware Distributed Clustering Algorithm For Mobile Wireless Sensor Networks Using Fuzzy Logic[END_REF] is increased by 5%.

V. CONCLUSION

A fuzzy logic based failure management algorithm was proposed in this paper. Stable route recovery and high data delivery ratio are the main characteristics that the proposed protocol adds to the routing algorithms.

This algorithm is especially effective in networks that use sensor nodes for data collection and in which the data delivery ratio is important.

In all of the data acquisition systems like health monitoring systems, either the data is collected from the network periodically or on the occurrence of an event, the data are highly vital and we must have a minimum number of faulty alerts. This necessitates the use of a protocol for data collection that readily adapts to the failures of the nodes and changes in the data delivery rate.

In such networks health events and information is sensed by several nodes and therefore, this protocol can help the network to deliver these sensed events and avoid data loss in the network. The simulation results show that the proposed protocol is well suited for such applications.

Figure 1 .

 1 Figure 1. A sample random deployed network

Figure 2 .Figure 4 .

 24 Figure 2. Updating Confidence parameter

Figure 5 .Figure 6 .

 56 Figure 5. Delivery ratio in ZigBee

Table of B

 of Neighbor confidence

	…	…
	x	High
	…	…
	y	Medium
		Neighbor Table of A

TABLE I .

 I

					SIMULATION PARAMETERS
		Node Number				50
		Surface						50m x 50m
		Transmission range				15m
		Data transmission rate			15 packet/sec
		Failure model				Random
		Packet size					128 bytes
		Initial Energy					5J
		Energy consumption (Calculation, receive and send)	10 nJ/bit
		1
		0,9
		0,8
		0,7
	ratio	0,6
	Deliver	0,4 0,5
		0,3
		0,2
		0,1
		0
		5	10	15	20	25	30	35	40	45	50
					Faulty nodes' percentage
				ZigBee routing		ZigBee with our proposition


Shahram Nourizadeh
email: shahram.nourizadeh@loria.fr

Y Q Song
email: song@loria.fr

J P Thomesse
email: thomesse@loria.fr

A Failure Adapted, Load-balanced Distributed Routing for Wireless Ad-hoc Sensor Networks

Keywords: Adaptive routing, Dynamic Clustering, Mobility management, Failure management, Load balancing, Fuzzy Logic I

this paper proposes a distributed routing protocol for ad hoc sensor networks which uses Fuzzy Logic. Each sensor uses a Fuzzy decision making process to find the best Cluster Head. Simulation shows that this protocol is able to dynamically adapt to sensors' mobility and failure. By a new load balancing method, it provides also stable clusters and so a cluster head have greater lifetime, which results minimum message exchange and so minimum energy consumption.

INTRODUCTION

In all ad-hoc wireless networks, like health monitoring systems, either the data is collected from the network periodically or on an occurrence of an event, in such systems, the data are highly vital to have a stable monitoring and have a minimum number of faulty alerts. Hence, none of them adapts completely themselves to the failure of the nodes and the temporal variations in data delivered by the sensor network. This necessitates the use of a routing protocol that readily adapts to the failures of the nodes and changes in the data delivery rate. One of the suitable solutions to manage the mobility of the nodes is dynamic clustering. However the existing clustering protocols use many assumptions which make them not able to address the needs of real application. Some algorithms are based on centralized control that makes them not to be scalable. Some algorithms use periodic rounds to change cluster head and elect a new one. The new cluster head will be fixed for one round, but in an ad-hoc network with dynamic topology, cluster topology may change during this period, and in this case a new cluster head must be elected. Therefore this type of algorithms will be good for networks with fixed or very low mobility nodes.

The zone routing protocol (ZRP) [START_REF] Haas | The zone routing protocol (ZRP) for ad hoc networks[END_REF] is a hybrid strategy which attempts to balance the trade-off between proactive and reactive routing. In ZRP, each node maintains its own hopcount constrained routing zone; consequently, zones do not reflect a quantitative measure of stability, and the zone topology overlaps arbitrarily. LEACH [START_REF] Heinzelman | An Application-Specific Protocol Architecture for Wireless Microsensor Networks[END_REF] is an applicationspecific data dissemination protocol that uses clustering to prolong the network lifetime. LEACH clustering terminates in a constant number of iterations, but it does not guarantee good cluster head distribution and assumes uniform energy consumption for cluster heads. A fuzzy logic approach to cluster-head election is proposed in [START_REF] Gupta | Cluster-head Election using Fuzzy Logic for Wireless Sensor Networks[END_REF], based on three descriptors -energy, concentration and centrality. This technique is proposed to use in LEACH [START_REF] Heinzelman | An Application-Specific Protocol Architecture for Wireless Microsensor Networks[END_REF], but it cannot support the mobility of the node and in addition it is centralized algorithm and therefore it cannot be scalable.

In addition, network topology changes resulted by node mobility and node state transitions due to the use of power management or energy efficient schemes may be detected as node failures or wireless link failures. A highly dynamic network greatly increases the complexity of failure management. Also, with bandwidth limitation in a sensor network the failure detector must generate a minimum number of control messages. Marzullo [START_REF] Marzullo | Tolerating failures of continuousvalued sensors[END_REF] proposed a flexible control process program that tolerates individual sensor failures. Issues addressed include modifying specifications in order to accommodate uncertainty in sensor values and averaging sensor values in a fault-tolerant way. The authors in [START_REF] Jayasimha | Fault tolerance in multi-sensor networks[END_REF] developed an algorithm that guarantees reliable and fairly accurate output from a number of different types of sensors when at most k out of n sensors are faulty. The results of the scheme are applicable only to certain individual sensor faults and traditional networks. However, the traditional failure detectors and management systems assume that all of the nodes of the network are synonymous, that means there is no difference between a node that was crashed n times in t hours, with a node that was crashed m times (m>n) in the same period of time. Inadition, in the traditional failure detectors, when a node fails, it will be assumed as a dead node and we don't have a return of the node. That will be a restriction, for example, when a node is in maintenance.

Finally, because of restricted energy resources, load balancing is another important challenge in sensor networks. To balance the load in the network, most of the clustering protocols use different parameters to choose cluster-heads. Cluster ID [START_REF] Baker | A Distributed algorithm for Organizing Mobile Radio Telecommunication Networks[END_REF], connectivity degree [START_REF] Gerla | Multicluster, mobile, multimedia radio network[END_REF][START_REF] Parekh | Selecting Routers in Ad-Hoc Wireless Networks[END_REF] and periodical cluster heads election [START_REF] Heinzelman | An Application-Specific Protocol Architecture for Wireless Microsensor Networks[END_REF] are used in order to share the load among all the nodes of the network. By applying cluster ID or highest connectivity methods, the same node may be chose as clusterhead every time, and that will result resulting in this sensor to drain its energy very fast. Changing the cluster head in the cluster, connectivity degree or periodical choosing, changes the topology of clusters frequently and this will impose huge overhead since all other cluster-heads have to be notified about the change. The remainder of this paper is structured as follows: section II explains our proposal. The functionality of our proposal is described by using some exaples in section III, while section IV describes our simulations and section V provides concluding remarks.

II. OUR PROPOSAL

In order to address Mobility and Failure management and Load balancing, our approach has 5 main parts: Fuzzy logic decision making, Clustering (Cluster-head election), Mobility management, Load balancing and Failure management (Figure 1). To make it scalable the protocol is totally distributed, it has also a load balancing part. Fuzzy decision making is the basic part of our proposal and other parts of the protocol, use fuzzy logic to make decision or to process an event. In our proposal, we use fuzzy logic because it is capable of making real time decisions, even with incomplete information. Conventional control systems rely on an accurate representation of the environment, which generally does not exist in reality. Moreover fuzzy logic can be used for context by blending different parametersrules combined together to produce the suitable result. In the next sections we will explain role of fuzzy decision making in different parts of our protocols.

Our protocol uses a cluster hierarchical architecture. The root node of the network tree is Base Station (BS) which can be a central computer or a receiver. In the second level, all mobile or stationary nodes that communicate directly with BS are Zone-Heads (ZH); each ZH constructs a Zone (set of one or more cluster). In the third level of the network tree, we have Cluster-Heads (CH) which is the nodes (mobile or stationary) that can communicate with one or more ZH or a node with some children that can communicate with other CHs. Finally the end level of the tree is Leaf-Nodes (LN). LN is a node without child. Figure 2 shows a sample network tree. In this figure, BS is the base station, Z1 and Z2 are zone heads, C1...C4 are cluster heads and the black nodes are the leaf nodes.

We have 7 different messages in this protocol. Ok, invie, hello, find, join and join-other are the messages used in our protocol. Invitet is a message, between the nodes to exchange the information. This message is used by a ZH or CH to invite the other nodes to join them. Hello is used by a node to announce a change or event to its neighbors. Find will be used by nodes to find a new parent. Join is used by a node to answer an Invite message. If the node has just one possible candidate to choose as its parent, it will indicate that, in this message. Quit is sent by a node to its parent node to advertize leaving it. Finally, join_Other is a message that a ZH or a CH sends to one of its child to ask him to find another parent to reduce its load by reducing number of its child. This will be when the ZH or CH, received a new request of join from a node with no other possible parent, and the admission condition is not satisfied. This message will be used also when the ZH or CH is in a low level energy state.

In this protocol we proposed a new parameter named Mobility. This parameter shows frequency of parent, level or zone change of a node. (Number of CH or level change of a node in his life time). Therefore each time that the node changes its CH or his level, it must increment value of a variable named Change and divide it to his lifetime to find the Mobility. It is clear that the mobility of a fix node can be greater than zero, because of the mobility of his parent.

Our protocol has also a load balancing strategy. It considers the cumulative load of data traffic from child nodes in a load tree on their parent nodes. We use Load tree and admission condition for load balancing. Figure 3 shows a sample load tree. The load tree is rooted in the base station. The load of child sensor nodes adds to the load of each upstream parent in the tree. Hence, the sensor nodes nearest the base station will be the most heavily loaded. The goal of this load balancing technique is to evenly distribute packet traffic generated by sensor nodes across the different branches of the Load tree. But here Load has a special definition. Load is the sum of the QoL (see next section) between a node and his children. It is a new definition that can be used as a new parameter in QoS. In a load tree, the weight of each link, in load tree is QoL between each node and his parent, and load of each node is the sum of the QoLs between the node and his child. In order to balance the load between nodes of the network, we use admission condition to accepte a new child node. The condition is, to accept a new child node, the QoL of the parent node must be greater than its load. In this approach we have also a parameter named failure shows the failure history of a sensor. This parameter will be computed by using the number of sensor's failures during its lifetime. Like the other used parameters, it is also a Fuzzy variable that has 3 levels: High, Medium and Low. That is not a static parameter, that means, for each node it can change from Low to High and also High to Low. To manage the failure of nodes or links, each time that the node detects a failure in a neighbor, it updates failure parameter for this node, by using: failure = fuzzy (n / L); where fuzzy is a function to convert decimal value to fuzzy value, n is number of neighbor's failures and L is our life time, therefore the failure parameter has different value for each node in the other nodes. In each network, due to the mobility or failure frequency of the nodes, BS will defines a update period, in which each node will update the failure table, therefore failure and Reliability parameters are really dynamic parameters that can change not only from Low to High but also from High to Low.

The protocol uses four parameters: Energy level of the node (Battery charge), Mobility, Quality of Link -QoL (Reliability between a node and his parent) and the failure, to evaluate a node that is candidate to be a ZH or CH. These parameters will be the Fuzzy Logic Descriptors and each of them has three possible values: low, medium, high. Therefore we have 81 rules to evaluate a node. The result of the rules will be Reliability with five possible levels: Very Low, Low, Medium, High and Very High (See figure 4).

In each Invite message the node will send necessary information to be evaluated by the other nodes, as like as: Energy level and QoL, and the node will compute the QoL of the connection between candidate and itself. The QoL of a node is Reliability parameter that he was calculated for his parent. This parameter helps us to choose the best parent node, a node with maximum energy, maximum stability, and higher reliability of connection. By finding the Reliability of a candidate we must evaluate the chance of the candidate to be a parent. To restrict depth of network's tree when a node receives more than one Advertisement, it will choose the node with smaller level, therefore we use: Chance = Reliability / Level

III. HOW DOES IT WORK?

In this section we will explain our protocol with some examples. Figure 5 shows thet node n search a parent. It sends find message, CH1 and CH2 receive its message and to answer the find message they send a invite message to n. By receiving 2 invite message, n start a fuzzy decision making function to find the best cluster head to join. In this example CH2 is the best one, therefore n sends a join message to it. CH2 verifies the admission condition, and as it is OK, it sends a ok message to n and n joins CH2.

In figure 6 we have a different scenario as the second example. In this example node n sends a join message to CH. The admission condition in CH is not OK, and n has just one posible cluster head to join (CH). Therefor CH sends a Joinother message to its children n1. By receiving this message n1 sends ao message to its neighbeur, n2. As n2 is a leaf node, it doesn't need to verify admission condition, therefore it sends a ok message to n1, and then changes its role to cluster head. By receiving ok message from n2, n1 send a ok message to CH and join n2. CH send a ok message to n and n joins CH. In this example, the role of n2 has changed, therefor it sends hello message to its neighbeurs to announce this change.

IV. EVALUATION

In this section evaluated performance of our proposition will be presented and will be compared with ZRP [START_REF] Haas | The zone routing protocol (ZRP) for ad hoc networks[END_REF]. In our simulation we focus in load of the zone heads and average QoL in each zone and network's data delivery ratio as performance metrics. Table I, shows our simulation parameters. We used random waypoint model [START_REF] Lin | Mobility Models for Ad hoc Network Simulation[END_REF] in our simulations. The Network consists of several low mobility wireless nodes, just 20% of the nodes are mobile and their speed is 0.5 m/s. Each node is initially placed at a random position within in the simulation area. In adition, to focus on the assessment of the performance of the proposed algorithm, we do not generate any user data traffic during a simulation. We assume that all the nodes are able to detect correctly the failure of the other nodes and when a node failed or crashed, it is not dead, it will be return to the network after a variable time, t≠∞. In our simulation, a round is the period of time in which all the mobile nodes change their zone. Figure 7 shows load in ZHs of the simulated network. We find in this figure that after 10 rounds, network has 6 zones and load of 4 ZHs are medium, one between medium and high, and one between medium and low. After 100 rounds network has 7 zones and the load of 6 ZHs is between medium and low and load of one of them is medium. The average of load in ZHs after 10 rounds is medium and after 100 rounds is between medium and low. These results show that our protocol can balance correctly the load between ZHs and CHs. A QoL with value of high shows a good connectivity between the nodes and a low QoL shows unstable connection between the nodes. Figure 8 shows average QoL in the zones of the simulated network. We find in this figure that after 10 rounds, network has 6 zones and average QoL in the zones in between medium and high, and after 100 rounds network has 7 zones with average QoL near to high. These results show the efficiency of our protocol to establish reliable and stable connections between the nodes.

In our simulation, we focus also on the network delivery ratio (the total received packets to the total sent packets in the sensor network). We compared this metrics in ZRP routing protocol and our protocol. As we said 20% of the nodes of the network are mobile and for the simulation, in each step, we change the number of faulty nodes from 5 to 50 percent. We can find the simulation results in figure 9. The simulation shows that our protocol increases the data delivery in the network and greatly adapts mobility and failure of the nodes.

V. CONCLUSION

In this paper, we have presented a distributed, load balanced routing for mobile wireless sensor networks which can adapt to mobility and failure of the nodes. This approach uses fuzzy logic to select the cluster heads. It can be applied to the design of sensor network protocols that require energy efficiency, scalability and mobility adaptation. This protocol is especially effective in networks that use sensor nodes to data aggregation and in which the data delivery ratio is important and the nodes are mobile, like health monitoring sensor networks. In such networks health events and information is sensed by several nodes and therefore, this protocol can help the network to deliver sensed events and avoid of data loss in the network. Through simulations we showed the effectiveness of our protocol for these applications.

Figure 1 .

 1 Figure 1. Protocol's architecture

Figure 4 .

 4 Figure 4. Cluster head election

Figure 6 .

 6 Figure 6. Example 2

Figure 7 .Figure 8 .

 78 Figure 7. Network's ZHs' load after 10 and 100 rounds

TABLE I

 I

	.	SIMULATION PARAMETERS
	Node Number	50
	Surface	100m x 100m
	Transmission range	15m
	Data transmission rate	15 packet/sec
	Failure model	Random
	Packet size	128 bytes
	Initial Energy	5J
	Energy consumption (Calculation, receive and send)