Marc Pallot

Brigitte Trousse

Bernard Senach

Dominique Scapin

Living Lab Research Landscape: From User Centred Design and User Experience towards User Cocreation

Keywords: Open Innovation, User Centred Design (UCD), User Driven Innovation (UDI), Web 2.0 and User Content Creation (web 2.0 UCC), User Experience (UX), User Group Experience (UGX), User Cocreation (UC), Domain Landscape

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

Introduction

Today, 212 Living Labs are members of the European Network of Living Labs (ENoLL). They are geographically located within the enlarged European Union and in other regions such as South Africa, Asia and South America. All of them have the goal to involve users at the earlier stage of the R&D process not only as observed subjects but rather as a participative force for cocreating value. A living Lab is an open research and innovation ecosystem involving user communities (application pull), solution developers (technology push), research labs, local authorities and policy makers as well as investors. While the Living Lab ecosystem, through openness, multicultural and multidisciplinary aspects, conveys the necessary level of diversity, it enables the emergence of breakthrough ideas, concepts and scenarios leading to adoptable innovative solutions. A Living Lab Empowers user communities like it is done with Web 2.0 [START_REF] Frappaolo | What is Web 2.0?[END_REF]O'Reilly & Battelle, 2009) applications such as YouTube, Flickr, Delicious, or Twitter where users are creating content and value. There are even examples of stigmergic or mass collaboration where citizens are collectively creating content (e.g. Wikipedia) for the benefit of the society at large. A Living Lab is an Open Innovation ecosystem frequently operating in the context of competitiveness clusters and public development agencies within social innovation environments engaging local authorities in territories such as cities, agglomerations, regions. A Living Lab can operate with a research and innovation platform for providing access to science and innovation services allowing enterprises and users/citizens either as entrepreneurs or communities. The main objectives consist to explore new ideas and concepts, experiment new artefacts and evaluate breakthrough scenario that could be turned into successful innovations. There are different application examples such as eHealth, Ambient Assisted Living, eInclusion, eTransportation, eGovernment, Smart City, ICT for Energy, and ICT for Environment. The Social dynamics of the Living Lab approach ensures a wide and rapid spread (viral adoption phenomenon) of innovative solutions through the socio-emotional intelligence mechanism (Goleman, 1998). A Living Lab environment needs to have one or several specific technology platforms (eHealth, eParticipation, eInclusion and so on), science & innovation services and user/citizen communities enabling the exploration of innovative scenarios including new concepts turned into technological artefacts. The experimentation and evaluation of the resulting scenarios and technological artefacts are driven by users within a real life context through a socio-economic (societal, environmental, health and energy cost/value), socio-ergonomic (user friendliness) and socio-cognitive (intuitive level) as well as adoptability perspectives (potential level of viral adoption). Living Labs are standing at the crossroads of different society trends like citizens engaged into a more participative approach, businesses and local authorities as well as user communities are gathering within public-private-people partnership initiatives. They are also at the crossroads of different paradigms and technological streams such as Future Internet, Open Innovation, User co-Creation, User Content Creation and Social Interaction (Web2.0), Mass Collaboration (i.e. Wikipedia), and Cloud Computing where the Internet is the cloud, also named "the disappearing IT infrastructure". However, there are still open questions such as articulating the various relevant research areas, methods and tools within the Living Lab research domain and identifying appropriate concepts for supporting user cocreation.

2 The Domain Landscape of Living Lab

The Living Lab Approach

As demonstrated by the Web 2.0 in empowering users, new R&D approaches are emerging where users are not considered anymore as being the observed subjects in functional tests but rather as being able to contribute and create value. William Mitchell 4 argued that a Living Lab represents a user-centric research methodology for sensing, prototyping, validating and refining complex solutions in multiple and evolving real life contexts. He identified several impact and benefits. The first noticeable impact is the integration of the users into the development process for ensuring highly reliable market evaluation. The second one is the reduction of technology and business risks. The third one is that a Living Lab is beneficial to SME, micro-organizations and start-ups, since they can share resources without so much venture capital. Finally, the fourth one is that large companies have access to a broader base of ideas. Ballon and colleagues (2005) found that Test and Experimentation Platforms (TEPs) constitute a new and relatively uncharted territory. Therefore, they launched an extensive exploratory research on TEPs theoretical literature and empirical data. They identified six types of TEPs, namely prototyping platforms (including usability labs, software development environments), testbeds, field trials, living labs, market pilots, and societal pilots. Interestingly, they gave the following definition to Living Lab, "An experimentation environment in which technology is given shape in real life contexts and in which (end) users are considered 'co-producers'." They elaborated a domain landscape of TEPs with three different dimensions (see Figure 2.2.1). The first dimension consists in the technological readiness that scales from low (immature technologies) to high maturity (mature technologies or applications that are almost market ready). The second one addresses the focus and balances in between testing and design. However, one can assume that this dimension is about evaluation. Finally, the third one consists in making a differentiation in between the degree of openness, ranging from in-house activities to open platforms. The different areas appearing like bubbles in the landscape correspond to the six identified TEPs. They are positioned in the landscape according to the two dimensions of focus and technology maturity they are intended to deal with 2.2.2 Domain landscape of Human-Centred Design Research [START_REF] Sanders | Co-creation and the new landscapes of design[END_REF] started to draft a domain landscape of design research (see Figure 2.2.2) for developing a paper on the state of design research. She found that the design research map is described by two intersecting dimensions, namely: the design research approach and the mind-set. She explained that the dimension on approaches is split into research-led on the bottom side and design-led on the top side. The dimension on mind-set is split into expert mind-set on the left hand side, where users are considered as subjects, and participatory mind-set on the right hand side, where users become value co-creators. Sanders identified the shift of the mind-set dimension as a significant cultural change. The largest areas in the map represent the most populated ones, such as User-Centred Design and Participatory Design. She explains that the UCD area includes social and behavioural sciences as well as human factors and ergonomics. Two smaller bubbles inhabit the UCD territory, namely contextual inquiry and lead-user innovation. On the right hand side, the Participatory design territory is inhabited by physical artefacts as thinking tools throughout the process, common among the methods issued by the Scandinavian research norms. The design and emotion bubble appeared in 1999, said Sanders, as a combination of research-led and design-led approaches to design research. Critical design where designers are the experts (instead of the researchers) appeared as an opposite force of UCD. It focuses on cultural probes rather than usability and utility. Finally, the generative design bubble appeared to empower people to create and promote alternatives to current situations. Generative tools instil a shared design language used by designers, researchers and stakeholders (users) for communicating visually. This technique suits particularly the Front-End of Innovation in order to feed the process with people ideas, dreams and insights. Later, [START_REF] Mulder | Co-Creating in Practice: Results and Challenges[END_REF] argued that Northern Europeans led the participatory approach (see Figure 2.2.2) combined with explorative actions using tools and techniques from design, such as making collages, diagrams, models, and other visualizations as a means to support self observation and reflection. She notes that these "Research techniques have not only evaluative power (prove/disprove a hypothesis or idea), but also generative value (provide insights not yet known to the researchers)." Mulder also states that the notions of co-creation and co-design have been growing within the participatory design landscape. She proposes to involve active users by making use of generative techniques in order to practice more the concept of engaging users as co-creation contributors as re-enforcing the living side of the Living Lab environment. Finally, she argues that "Cocreation in open innovation requires an open mindset towards sharing and collaboration. This is not trivial. Although board members preach open innovation in pre-competitive collaboration, companies seem not eager to share with competitors. Even within companies, employees are not always keen in sharing ideas."

Existing Related Domain Landscapes

Domain landscape of Test and Experimentation Platforms

Towards a Domain Landscape of Living Lab Research

As we were working on the development of a paper about the research area of User Experience and discussing about the scientific program of the first Living Lab Summer School and more specifically about the Living Lab domain mapping and landscaping sessions, it came to our mind that it could be useful to prepare a map as a tentative landscape of Living Lab research. The starting point was a previous article on Living Lab research that was published in the ECOSPACE Newsletter (Pallot et al, 2008). Several possible dimensions were identified and finally two main dimensions, namely the interaction mode and research type allowed designing four quadrants (see Figure 2.3-a). The main idea behind the design of this map is to show, like in the Sander's map, a progress from functional tests and usability analysis toward User co-Creation. However, the selection of these two dimensions is self-explained by the evolution of the role of users. The first dimension called "Interaction Mode" illustrates the way interaction with users is perceived. This dimension scales from Human-Computer Interaction (HCI), which addresses individual users, to Interpersonal Interaction that embeds social interaction within a group of people, especially the large ones like online communities. The second dimension "research type" splits the domain landscape into Observation Research where a user is considered as a subject and Participative Research where users actively contribute in co-creating value. This dimension resemble to the dimension on mind-set of Sander's map.

Figure 2.3-a -Dimensions and Four Quadrants of the Living Lab Research Map

There are two complementary dimensions that could be useful in order to better characterise the current R&D and innovation trends and evolution (see Figure 2.3-b). As a way to show the complementary to the main dimensions, they appear as diagonals. The first diagonal (BL, TR) illustrates the evolution current trend in terms of evaluation focus starting with reliability, as a first stage, where a functional test is applied in order to check if a feature works properly but without necessarily considering whether this feature could really be useful to the users. The second stage consists to carry on usability analysis for the obvious motivation of evaluating the user friendliness (degree of intiutivity) and ergonomic design. While the third stage "adaptability" brings the evaluation of personalisation capacities (degree of look and feel recomposing), the fourth one "adoptability allows users to create new features (composing their own services).

The second diagonal (BR, TL) shows the recent evolution of collaboration style induced by network technologies such as the Internet and the Web. This dimension scales from structure collaboration with for example Symbiotic collaboration style (physical collocation) up to unstructured collaboration [START_REF] Dorigo | Ant Colony Optimization[END_REF][START_REF] Elliott | Stigmergic Collaboration: The Evolution of Group Work[END_REF] with for example Mass collaboration style (virtual or online collocation). These two diagonal complementary dimensions are also important for positioning the different research areas in the landscape of the Living Lab research map. However, one could argue that another potential dimension could represents the current trend induced by a specific focus on societal issues (eCare, eInclusion, eHealth, eTransportation, eGovernment, Smart City, ICT for Energy, and ICT for Environment) as an R&D shift from technological innovations towards more socially based innovations. Technological innovation is included in the figure as corresponding to the HCI of the interaction dimension. Social innovation is also included in the figure as corresponding to the Interpersonal Interaction. While in the first case the focus is on developing a product (hardware), in the second case the priority is much more on developing specific services for people. The next step consists to populate this map with the existing research areas in order to design the landscape of the Living Lab Research Map. A number of research areas already exist for involving users in the R&D and innovation processes, such as Web 2.0 User Created Content (Web 2.0 UCC) [START_REF] Garrett | Elements of User Experience: User-Centered Design for the Web[END_REF], User Centred Design (UCD), User Experience (UX) (ISTAG EAR report, 2004;[START_REF] Aarts | The New Everyday: Views on Ambient Intelligence[END_REF][START_REF] De Ruyter | User Centered Research in ExperienceLab, European Conference, AmI 2007[END_REF], User Cocreation (UC), User Centric-Innovation (UCI) and Driven-Innovation (UDI). Like in Sander's landscape of design research, it makes sense to include participatory design. The largest areas in the map represent the most populated ones like in Sander's landscape on design research. User-Centred Design (UCD) and Participatory Design [START_REF] Schuler | Participatory Design[END_REF] as well as Web 2.0 User Content Creation (UCC) represent the largest areas that are confirmed by the number of published scientific papers. In contrast with Sander's Landscape, besides the fact that it also includes usability analysis as well as human factors and ergonomics, the UCD area overlaps with User Experience (UX). The concept of UX was widely disseminated by [START_REF] Norman | What You See, Some of What's in the Future, And How We Go About Doing It[END_REF] and became a research area by its own. Two smaller bubbles inhabit the UCD territory, namely contextual inquiry and lead-user innovation. On the right hand side, the Participatory design territory is inhabited by various artefacts intended to engage users in the group cognition leading to the emergence of new ideas, scenarios and concepts. Several smaller bubbles are overlapping the participative design territory; among them appear the Empathic Design (ED), User Cocreation (UC) (Interact, 2009), User Driven Innovation (UDI) or User-Centric Innovation [START_REF] Bilgram | User-Centric Innovations in New Product Development; Systematic Identification of Lead User Harnessing Interactive and Collaborative Online-Tools[END_REF] and Socio-Emotional Intelligence (SEI). Those bubbles are linking UCD with Participative Design. Action Research (AR) could be included as a bubble also linking UCD and PD. Even Participatory Action Research (PAR) has emerged in recent years as a significant methodology for intervention, development and change within communities and groups. The SEI bubble appeared in 1998 as a combination of views issued from Goleman books on Social Intelligence and later on Emotional Intelligence. In contrast with Sander's Landscape for a second time, this is the Web 2.0 UCC, where developers and users are the experts (instead of the researchers), appeared as an opposite force of UCD. It focuses on User Content Creation, Crowd Sourcing and Social Networking as a kind of cultural probes (Gaver, 1999;[START_REF] Norman | Emotional Design. : why we love (or hate) everyday things[END_REF] rather than focusing on usability analysis. Finally, the User Group Experience (UGX) bubble appears to have a group of users experience instead of individual user experience (UX) [START_REF] Fleming | Web Navigation: Designing the User Experience[END_REF] in order to let a community share experiences that lead to new insights, ideas and breakthrough scenarios. Contextual Design [START_REF] Beyer | Contextual Design: Defining Customer-Centered Systems[END_REF] is currently still to be included in the Participatory Design territory. We do believe that the concept of UGX brings the socio-emotional perspective into user experience. This would constitute a major step forward in the direction of experiential service platform with a strong connection to Empathic Design and Socio-Emotional Intelligence. This would allow researchers, developers and users to move more concretely towards User Cocreation. This new research area suits particularly the Front-End of Innovation in order to feed the R&D process with group and empathical insights unleashing the power of people ideas.

A table of concepts and definitions (see Table 2.3) provides useful information for disambiguating the used terminology. This table will be completed and extended. The lack of domain landscape on Living Lab research appears to be an important issue for researchers in the movement towards user cocreation. It would help to reach a broader understanding of the Living Lab concept. Exploring the domain landscape of Living Lab research was an exciting task as well as drafting the map with area bubbles inhabiting the various territories. During this work, UGX emerged as a necessary area bubble linking the traditional UX, which focuses very much on usability analysis, and UC in order to bring the social elements. This work was performed as a diversion in the UX study we are currently carrying on. Developing a domain landscape like this one is an important task but considerable amount of work. We hope that this first exercise and issued draft will motivate enough other researchers for contributing to its future development. Furthermore, the current figure of the domain landscape of Living Lab research we have developed, could be re-used for describing complementary layers for related techniques, methods and tools as well as examples based on previous studies that could be positioned in the landscape and illustrate the different areas. Another layer could be described for locating the already published papers on Living Lab and related research areas.

Figure 2

 2 Figure 2.2.1 -Conceptual Framework of Test and Experimentation Platforms (Ballon et al, 2005)

Figure 2

 2 Figure 2.2.2 -Domain Landscape of Human-Centred Design Research (Sanders & Stappers, 2008)

Figure

  Figure 2.3-b -Diagonal Dimensions of the Living Lab Research Map

Figure 2

 2 Figure 2.3-c -Domain Landscape of the Living Lab Research Map

Table 2 .3 -Concepts Belonging to the Domain Landscape of the Living Lab Research Map

 2

	3 Conclusions and Future Work


Mohamed-Hedi Karray

Brigitte Chebel-Morello

Christophe Lang
email: christophe.lang@univ-fcomte.fr

Noureddine Zerhouni
email: noureddine.zerhouni@femtost.fr

A Component Based System for S-maintenance

Keywords: maintenance, e-maintenance, component based system, knowledge based system. I

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 knowledge management, cooperation and collaboration are vital to any operation. Into this context, new services like intelligent maintenance, self maintenance, etc are required. To this end, a new concept called s-maintenance is emerged. This concept defines a new generation of maintenance systems founded on a knowledge based system. While existing systems don't respond to the characteristics of this new generation of systems, we design in this paper an architecture of a maintenance component based system respecting the characteristics of s-maintenance. Each component in the system is defined to respond to one or many characteristics of this concept.

INTRODUCTION

The role of maintenance is strategic in the industrial environment. Hence, while having this interest in company; industry has been seeing the developments of different generations of maintenance systems. New technologies of information and communication technologies (ICT) have helped to establish and evolve these systems [START_REF] Muller | On the concept of emaintenance: Review and current research[END_REF]. E-maintenance and s-maintenance are considered as the most important resulting concepts that have been developed and applied in the industry. A variety of definitions of e-maintenance are presented in the literature and summarized in [START_REF] Muller | On the concept of emaintenance: Review and current research[END_REF]. Building on this diversity of work, we propose a definition to the concept of emaintenance encompassing the entire maintenance process, as well the e-maintenance system. Hence, we define e-maintenance as the carrying out of maintenance where the all technical, administrative, and managerial actions or activities interact and collaborate electronically, using network or telecommunications technologies.

Regarding the e-maintenance system, we define it as a collaboration system offering a set of software components and software services of maintenance support (integrated and/or distant) all that enable maintenance actors to find each other and the information they need and to be able to communicate and work together to achieve maintenance process via a variety of devices .

Vis-à-vis s-maintenance, it comes as an evolution in maintenance systems extending the concept of e-maintenance and transforms the maintenance system from an integration tool to the core of the maintenance process.

This concept is presented by Rasvoska et al [START_REF] Rasovska | Process of s-maintenance: decision support system for maintenance intervention[END_REF] as a concept enlarging e-maintenance. Then in a previous work, we presented this work as a new generation of maintenance system focusing in semantic interoperability [START_REF] Karray | Towards a maintenance semantic architecture[END_REF]. Then, a more generic definition is provided in [START_REF] Morello-Chebel | New perspectives of Maintenance systems: "towards s-maintenance[END_REF] extending the s-maintenance concept to be more adaptable to the new industrial needs [START_REF] Lee | Informatics Platform for Designing and Deploying e-Manufacturing Systems[END_REF]. So, s-maintenance concept is defined as the carrying out of maintenance based on the domain expert knowledge, where systems in the network manage this knowledge (formalization, acquisition, discovery, elicitation, reasoning, maintenance use and reuse) and share the semantics to emerge new generation of maintenance services (as self-X services, Worker self-management, improvement of various types of maintenance, new collaboration methods, etc.) while including e-maintenance characteristics." When we speak about characteristics we mean what distinguish this concept according to its definition. In the other hand, smaintenance system is a based knowledge distributed and collaborative system providing self-management services [START_REF] Ganek | the dawning of the autonomic computing era[END_REF] to the overall maintenance process. It is a self learning system [START_REF] Leondes | Knowledge -Based systems: Techniques and Applications[END_REF] having the possibility to evolve its intelligence degree, including computational intelligence and knowledge [START_REF] Poole | Computational Intelligence: A Logical Approach[END_REF]. Based on semantics of the domain experts knowledge, it is a scalable, adaptable and contextual system (semantic interoperability, user oriented, intelligent HMI, processes orchestration, tracking users interactions, new process generation).

This concept emerges from the aggregation of the power of knowledge engineering and the integration of new aspects into the maintenance scope. The strong point of this concept is that the knowledge management system presents the core of the information system and allows manipulating the expertise knowledge of the domain (see figure1).

The s-maintenance system must ensure a high level of knowledge acquisition (based on self learning and tracking), elicitation, reasoning and re-use. This level enables more advanced predictive maintenance decision making basing on analytical reliability models, enables the achievement of intelligent maintenance and enables the automation of the maintenance process based decision making approach. For more details about these systems, please refer to the survey presented in [START_REF] Muller | On the concept of emaintenance: Review and current research[END_REF]. When analyzing these systems according to the s-maintenance definition, we note the lack between the characteristics of s-maintenance and what is provided by these systems. Most of these systems are built respecting some of e-maintenance definition. So, after a thorough analyze, we conclude the absence of a system responding to the s-maintenance characteristics and respecting the s-maintenance definition.

From the different methods of software engineering, Component Based System (CBS) seems the best candidate to model and set up an s-maintenance system respecting its definition given the philosophy of CBS which is integration centric with a focus on selecting components that match stakeholder requirements [START_REF] Mahmood | Analyzing Component Based System Specification[END_REF].

The computer-based system consists of all components necessary to capture, process, transfer, store, display, and manages information. Components include software, processors, networks, buses, firmware, application-specific integrated circuits, storage devices, and humans (who also process information) [9].

Hence, we propose in this paper a CBS for smaintenance. There are different methods, approaches and languages to design and describe a CBS like summarized and proposed in [START_REF] Stein | A Component-Based Modeling Approach for Systems Design: Theory and Implementation[END_REF], [START_REF] Garlan | Acme: An architecture description interchange language[END_REF], [START_REF] Kotonya | Viewpoints for Specifying Component-Based Systems[END_REF] and [START_REF] Gudas | Component-based modelling at the system design stage[END_REF], but while our system is specific to the concept of s-maintenance, we don't adopt any of these approaches. We just adopt a simple approach containing two phases, pre-analyze phase concerning the identification of the interesting components mach the s-maintenance requirements; and the second phase concerns the modeling of the system architecture by defining relations as well as interactions between these components.

The rest of this paper is organized as follow. Section 2 summarizes some related works on maintenance systems. Section 3 presents our proposed CBS architecture for smaintenance. Section 4 discusses our proposal as well as validation and some perspectives. Finally, Section 5 concludes the paper and sets guidelines for future work.

II. OVERVIEW ABOUT EXITING SYSTEMS

After a thorough study on maintenance systems developed in the academic setting and in research projects based on the review presented in [START_REF] Muller | On the concept of emaintenance: Review and current research[END_REF], we identified two systems developed respectively by Zhang and Cao that we consider as the closest systems to the definition of smaintenance system. These systems don't perfectly ensure s-maintenance characteristics.

Zhang proposed a multi-agent system for emaintenance based on knowledge management. This multi-agent system enables the exchange of knowledge/information between industrial automation systems [START_REF] Zhang | Knowledge Management for E-Maintenance of Industrial Automation Systems[END_REF]. All sources of information in the industrial automation systems are analyzed and modeled by agents. The relationships between these sources are highlighted in the context of maintenance, including proactive maintenance.

The system architecture consists mainly of a AMC (Agent Management Core) and four types of agents namely Knowledge Agent (KA), Configuration Agent (CA), Diagnostic Agent (DA), Field Agent (FA) and management agent (MA).

From an s-maintenance point of view, this system is consistent with some characteristics of this concept such as semantic interoperability and exploiting knowledge engineering. But the main issue of this concept (i.e. the dynamics of the services provided by the system) is not treated in this work. Moreover, the crucial point is that the AMC the most important component of the system is not knowledge oriented because it is not based on domain knowledge. Hence, this point let us wonder on its operation as component managing the creation and deletion of agents as well as the integration of new applications in the system.

In the other side, Cao et al develop the IIEMD (Integrated Intelligent Equipment Maintenance Decision) system for intelligent, distributed and cooperative Maintenance that provides a set of decision support tools for various maintenance activities [START_REF] Cao | Development of SOA Based Equipments Maintenance Decision Support System[END_REF]. IIEMD is a hybrid system supported by an ontology where it operates two types of logical reasoning that are the RBR (Rules Based Reasoning) [START_REF] Rissland | Combining case-based and rule-based reasoning: A heurestic approach[END_REF] and CBR (Case Base Reasoning) [START_REF] Rissland | Combining case-based and rule-based reasoning: A heurestic approach[END_REF] for the service of equipment maintenance decision-support in order to improve the performance of general maintenance process. IIEMD system is based on a Service Oriented Architecture (SOA) [START_REF] Thomas Erl | Service-oriented Architecture: Concepts, Technology, and Design[END_REF]. In this architecture, decision tools for maintenance (defined as Web services) can store, retrieve information from other tools and distribute information to other tools integrated into the system. This system integrates a knowledge base including an ontology and an inference engine.

We note in this work, the presence of some basic elements of s-maintenance characteristics. Firstly, this system is based on knowledge engineering. Thus, although it is not mentioned that the ontology was also used for the benefit of semantic interoperability, this is obvious since web services used in the SOA handle the ontology concepts. Compared to the s-maintenance characteristics, this system uses the knowledge engineering services for decision making in maintenance (intervention, repair) and not include all activities in the maintenance process (as diagnosis, prognosis, optimization of resources, planning) although it can integrate these systems thank to the SOA. But, it is also clear the lack of other basic elements of smaintenance as the self-learning and especially the generation of new services; it addresses only decision support services. In conclusion we can say that this platform is closest to the envisaged s-maintenance system but many aspects are neglected.

So after a brief analysis of existent systems, it seems clear that the overall characteristics of s-maintenance are not insured by these systems. This is understandable given the difference between the objectives of the initiated projects and the adopted concept. These systems are built to create e-maintenance system and try to respect smaintenance characteristics. We remember that emaintenance is about the integration of various systems of maintenance field and s-maintenance is about exploitation of existing knowledge in the system to emerge new services of maintenance while also including the integration aspect.

III. PROPOSED SYSTEM

We propose an architecture of a maintenance component based system respecting the characteristics of s-maintenance concept. The design approach is composed in two phases. In a first time, pre-analyze phase, we nominate the interesting components which must be present in the system. Then, in a second time, modeling phase, we design the system's architecture by defining relations as well as interactions between these components.

A. Pre-analyze

While a system is a collection of interrelated components that work together to achieve some objective, CBS success depends on the ability to select suitable components. An inappropriate component selection can lead to adverse affects such as short listing components that barely fulfill the needed functionality or they introduce extra costs in integration and maintenance phases [START_REF] Mahmood | Analyzing Component Based System Specification[END_REF]. Individual components usually provide fix capabilities that might not satisfy all system requirements and some of them may be unnecessary in a given system. This reduces the chance of a match between a component and stakeholder requirements.

That's why we begin by identifying the components that are generic and common for the proper functioning of the whole process of maintenance. Then, we identify the specific components for the s-maintenance.

To carry out maintenance of an automation system , it is typically recommended to use the following integrated applications [START_REF] Reboul | PROTEUS-An integration platform for distributed maintenance systems[END_REF]: a data acquisition system (SCADA, Supervisory Control And Data Acquisition), Diagnosis system, CMMS (Computerized Maintenance Management System), an ERP (Enterprise Resource Planning), a documentation system (eDoc), a Prognosis system , a scheduling system and finally a geo-location system. Each system relies on the model of the enterprise, the physical system or the equipment. All of these components can be integrated as extern applications in the system.

Then, we proceed now to identify specific components of s-maintenance. Concerning the Self management of maintenance process characteristic, a component for process management is needed.

Regarding to the Semantic based Maintenance, Self maintenance [START_REF] Labib | Next generation maintenance systems: towards the design of a self-maintenance machine[END_REF], Smart Maintenance, Intelligence and Expert knowledge characteristics; they require the presence of two major components which are a knowledge base to share semantics and to contain domain and expertise knowledge, as well as a reasoning engine inferring new knowledge and intelligence form the knowledge base.

Collaboration and cooperation need a coordination component; to share the knowledge it needs a knowledge base; a component ensuring security and manages users' roles as, well as a manger for human machine interface to adapt content to users' context and roles, then providing dynamic and contextual human machine interface.

Vis-à-vis semantic interoperability, a mediator component is needed to ensure this functionality based on the shared semantics.

For the Self Learning characteristic, a component ensuring traceability as well a component for reasoning is highly recommended to save and then analyze interactions in the system to learn and understand these interactions and save a new knowledge in the system.

And finally, About service generation which is a crucial point in s-maintenance, the presence of the reasoning engine is unavoidable, also a component for generation of new services must be present as well a directory to put on the new generated services.

In summary, we identify this variety of components which must be included in an s-maintenance system responding to its requirements (see figure 2). These components are: coordinator, mediator, HIM-human interface manager, AC-access controller, KBC--Knowledge Base Controller, KB -Knowledge Base, Reasoner, Slib -Service Library, SG-Service Generator, PM -Process Manager, TM -Traceability Manager.

The definition of these components and their functionalities will be provided in the next section.

B. System architecture

The core of this architecture is composed by four software layers allowing the integration of s-maintenance characteristics and applications in the system. Figure 3 gives an overview of the different layers of the core of the platform associated with the applications integrated into the platform as well as the smart technologies used by these applications. We can observe that components and mediator layers are based on the ontology layer.

We give now a brief description of these components and their functionalities. a-Coordinator: it coordinates between all the system's components and the integrated applications. In the system core, all components are connected via the coordinator. In addition, this component is also a conduit of communication between users with the system and between applications with the core. b-Mediator: it aims to ensure semantic interoperability between applications via the system. The architecture of s-maintenance system is based on knowledge and semantics represented by an ontology shared between its integrated systems. The local ontologies of these systems grow independently of each other. When ensuring semantic interoperability between these systems, the mediator takes into account the evolution of the local ontologies of these integrated systems [START_REF] Karray | A contextual semantic mediator for a distributed cooperative maintenance platform[END_REF]. c-HIM (Human Interface Manager): it manages all the postings on the Web interface in good shape and good content. Each actor has access to the maintenance system through HIM. A Maintenance actor (e.g. manager, expert, operator, etc) must be able to connect to the system via a Web browser on any type of client terminal. The client terminal may be a traditional PC, PDA, mobile phone or any other type of client, which it is possible to connect to the Internet. d-AC (Access Control): Different actors can intervene on the system. It must therefore be able to manage user rights as well as applications. In this case, the use of an authentication database can limit unauthorized access The AC gives access permission to a component or application requested by a query issued by a user or application. e-KBM (Knowledge Base Manager): it checks the consistency of outputs /inputs of knowledge with the ontology base (all knowledge that the other components inquire or register in the KB, are consistent with the ontology). reasoning engine is to seek information and relationships of the knowledge base and provide answers, suggestions and predictions similar to the way a human expert. That is to say, new knowledge is generated from existing knowledge through reasoning engine. The reasoning engine contains general algorithms that can afford to manipulate the knowledge stored in the knowledge base. h-SG (Generator Service): When a not exited service is required, Coordinator asks the SG to establish the new service (from requirements, provided information, reasoning, etc). After generation of this new service, it is registered in the SLIB. It may be a composition of basic services defined in the SLIB. Currently, we seek a mechanism or algorithm to implement this component. i-Slib (Service Library): it contains all services that are not provided by existing applications (integrated in the platform) such as: Traceability of functional mode of the equipment or Financial Analysis by indicators. For now, we will offer each service description as an XML file. j-PM -Process Manager: it orchestrates all the processes that pass through the system. That is to say that the PM component is responsible for managing the order process passing through the platform. k-TM (Traceability Manager): it allows knowing the actions done through the system. While all internal communications between the platform and the applications pass through the Coordinator, therefore the TM need just to be connected to the coordinator to trace the overall platform's interactions. The TM allows the tracking of all the interactions between applications, users with the platform and the interactions between components of the platform.

C. System functioning

The possible interaction between the user and the smaintenance system are shown in figure 4. There are two types of interactions, authentication request and service requests (already integrated or generated by the system). When user requests to access to the system through the web interface, his request passes from the HIM to the Coordinator. Coordinator sends the authentication request to the component AC to verify if that user can access the platform or not?

After a successful authentication to connect to the system, the user can querying services provided by the system according to his role rights.

When the Coordinator receives a query that requests a service provided by the system, two cases are possible. The First one, these services are provided by the applications integrated into the system. In this case Coordinator locates the right application which provides the requested service. Then it communicates with this application. The application is launched; if needed, it has the possibility to ask the Coordinator for communicate with other components of the system core.

The second case is if the requested services are not provided by the integrated applications. In this case, Coordinator seeks in the SLib (service library) to verify if these services exist or not. If the SLIB library contains these services then Coordinator launching these services. Else the Coordinator asks the SG (service generator) to generate these services through the use of existing knowledge.

Moreover, to illustrate the system execution, we present an example of a self-management of maintenance service provided by the system. This service aims to ensure automatically the OSA-CBM process without the intervention of human operators only in the intervention task. In this example we illustrate interactions between the system components throughout the OSA-CBM process [START_REF] Thurston | Open Standards for Condition-Based Maintenance and Prognostic Systems[END_REF]. The example treats the RUL (Remaining Useful Life) [START_REF] Tobon-Mejia | A Mixture of Gaussians Hidden Markov Model for failure diagnostic and prognostic[END_REF] generated by the prognostic application about a component x into an equipment Y.

Figure 5 shows the sequence diagram of these interactions. We note that the OSA-CBM process is already instanced in the knowledge base and used by the PM in the illustration. We note also that the diagnostic application used in the illustration is based on the equipment model as well as the behavior model of the functioning of the equipment. The diagnosis system identifies causes of failures and actions that will be done.

The prognostic application sends a query to coordinator asking for data about component x of equipment Y from sensor. Coordinator asks the SCADA for data about component x of equipment Y. The SCADA send the asked data to the Coordinator which forwards it to the prognostic application. After making its analyses, this later sends an urgent RUL to the coordinator that the component X will fail in 10 hours. When receiving the RUL, the coordinator doesn't know what action it should do, so it sends a query to the PM asking for what action it will be done in the scope of the OSA-CBM process. The PM responds to the coordinator that it will launch an expertise. So, the coordinator sends a query request for a diagnosis expertise about the equipment Y from the diagnosis application. This later asks the coordinator for sensors data and all information about the equipment model. The coordinator gets this information from the KB and the SCADA and forwards them to the diagnosis application, which asks also for the behavior model of the equipment Y. while this model is not given from any application integrated in the platform, coordinator consults the SLib to ask if there is a service providing the behavior model of an equipment. So when finding this service in the SLib, coordinator asks for the execution of this service for the equipment Y. Then, coordinator forwards the generated behavior model to the diagnosis application. After analyses and reasoning, this latter edits the expertise report recommending the change of component x and component z which causes the failure of the component x. The coordinator asks the PM what to do after the expertise. The PM mentions that it will plan an intervention. So, the coordinator asks the scheduler application to plan an intervention to change components x and z of equipment Y before 10 hours. The scheduler asks about availability of spare parts and human resources. So, the coordinator gets this information from the CMMS and the ERP applications and forwards them to the scheduler which books spare parts and maintenance operators and edits the intervention. After the intervention planned, the coordinator asks the next action form the PM which recommends the edition of the work order. So the coordinator asks form the e-doc application to edit this latter. While edited, the coordinator sends the work order to the operators planned in the intervention via the HIM.

IMPLEMENTATION AND DISCUSSIONS

After simulating a scenario in form of a sequence diagram, we are currently simulating the architecture with a multi-agent system MAS. Each component is simulated by an agent. After that, 4 groups of agents and their roles according to the definition and the behavior of the component are defined. Then two scenarios are specified to show three main characteristics of the s-maintenance. The first scenario is about self-learning through the TM component and self-management through the PM. The second scenario is about the generation of new knowledge via the SG. Some experiments should be planned to test some features of the system. In addition, the MAS will permit to test the charge of the messaging traffic for each particular component in the system. MADKIT platform is used to implement the MAS architecture.

Concerning the implementation of components, the KB is already developed by constructing a domain ontology of maintenance using the knowledge description language PowerLOOM [START_REF] Karray | Towards a maintenance semantic architecture[END_REF]. The mediator component is also already developed in a previous work [START_REF] Karray | A contextual semantic mediator for a distributed cooperative maintenance platform[END_REF].

In the other hand, concerning consistency of the proposed system, we identify two critical components in the platform which are the Coordinator and the KB. Indeed, we suppose that a large volume of queries can burden the Coordinator component that generates a large response time for query execution or even a crash on this component (to be tested and verified via the MAS). A failure on the coordinator means a total failure of the system. Different others problems may occur if any component fails. Such problem can cause a disturbance in the functioning of processes and workflow of the system. Even worse in the case of a crash at the knowledge base, the system is no longer usable. For this, we propose to replicate all components of the platform core, and especially highly recommend replicating the critical components. These replications can be put in the same server and/or in distant server or site. In addition, we can put a query dispatcher to manage the queries pile between the replicated coordinators and balance the processing load and the availability. As well, technologies and mechanisms of autonomic computing and self-healing systems can be added to each component to remedy this deficiency and enhance the robustness of the system. To conclude this section, we note that presented aspects about the consistency of the system will be investigated in future work.

V. CONCLUSION

After analyzing the existing maintenance systems we found that none of these systems meet all characteristics of s-maintenance concept that present the next generation of maintenance systems. For this purpose, we have proposed in this paper an architecture of a component based system responding to these requirements. Each component in this architecture answers to one or more of them. It should also be noted that the components of this architecture are defined according to their functionalities and not their technical specifications. These later are left for the engineers' choice when developing the system to implement them as software modules, web services or integrated applications. A scenario of execution is simulated via an UML sequence diagram. Also, other simulation scenarios via a multi-agent system are already ongoing.

Future works will be dedicated to integrate new services in the system. We are also working to develop all of the system components. Further, mechanism to the SG (service generator) component to generate complex new service will be done by composing elementary services provided in the SLib component. In addition, possibilities and benefices are studied to elaborate s-maintenance system by a cloud computing architecture to allow more scalability, potency and efficiency to the system.

Figure1

  Figure1. S-maintenance system Several maintenance systems have been developed and are in use today (ENIGMA, CASIP, ICASAME, Remote Data Sentinel, INTERMOR, INID, IPDSS, WSDF, MRPOS, PROTEUS, TELMA, etc.). These systems are a result either of the industrial world or of the academic one. Muller et al classify them as: proprietary platforms (i.e. ICAS), platforms developed within projects (i.e. PROTEUS) or platforms for research and education (i.e. TELMA).For more details about these systems, please refer to the survey presented in[START_REF] Muller | On the concept of emaintenance: Review and current research[END_REF]. When analyzing these systems according to the s-maintenance definition, we note the lack between the characteristics of s-maintenance and what is provided by these systems. Most of these systems are built respecting some of e-maintenance definition. So, after a thorough analyze, we conclude the absence of a system responding to the s-maintenance characteristics and respecting the s-maintenance definition.From the different methods of software engineering, Component Based System (CBS) seems the best candidate to model and set up an s-maintenance system respecting its definition given the philosophy of CBS which is integration centric with a focus on selecting components that match stakeholder requirements[START_REF] Mahmood | Analyzing Component Based System Specification[END_REF].The computer-based system consists of all components necessary to capture, process, transfer, store, display, and manages information. Components include software, processors, networks, buses, firmware, application-specific integrated circuits, storage devices, and humans (who also process information)[9].Hence, we propose in this paper a CBS for smaintenance. There are different methods, approaches and languages to design and describe a CBS like summarized and proposed in[START_REF] Stein | A Component-Based Modeling Approach for Systems Design: Theory and Implementation[END_REF],[START_REF] Garlan | Acme: An architecture description interchange language[END_REF],[START_REF] Kotonya | Viewpoints for Specifying Component-Based Systems[END_REF] and[START_REF] Gudas | Component-based modelling at the system design stage[END_REF], but while our system is specific to the concept of s-maintenance, we don't adopt any of these approaches. We just adopt a simple approach containing two phases, pre-analyze phase concerning the identification of the interesting components mach the s-maintenance requirements; and the second phase concerns the modeling of the system architecture by defining relations as well as interactions between these components.The rest of this paper is organized as follow. Section 2 summarizes some related works on maintenance systems. Section 3 presents our proposed CBS architecture for smaintenance. Section 4 discusses our proposal as well as

Figure 2 .

 2 Figure 2. Composition of the proposed system

Figure. 3 .

 3 Figure. 3. Layers of the s-maintenance system f-KB (Knowledge Base): In general, the ontology and all individual instances of concepts provide a knowledge base. In our case, knowledge base contains the ontology (concepts and rules [ontological meta-model]), ontology (instances of ontological meta-model), data (A: assertions [instances of ontologies]). g-Reasoner (reasoning engine): The overall goal of areasoning engine is to seek information and relationships of the knowledge base and provide answers, suggestions and predictions similar to the way a human expert. That is to say, new knowledge is generated from existing knowledge through reasoning engine. The reasoning engine contains general algorithms that can afford to manipulate the knowledge stored in the knowledge base. h-SG (Generator Service): When a not exited service is required, Coordinator asks the SG to establish the new service (from requirements, provided information, reasoning, etc). After generation of this new service, it is registered in the SLIB. It may be a composition of basic services defined in the SLIB. Currently, we seek a mechanism or algorithm to implement this component. i-Slib (Service Library): it contains all services that are not provided by existing applications (integrated in the platform) such as: Traceability of functional mode of the equipment or Financial Analysis by indicators. For now, we will offer each service description as an XML file. j-PM -Process Manager: it orchestrates all the processes that pass through the system. That is to say that the PM component is responsible for managing the order process passing through the platform. k-TM (Traceability Manager): it allows knowing the actions done through the system. While all internal communications between the platform and the

Figure 4 .

 4 Figure 4. User and system Interactions

Figure 5 .

 5 Figure 5. Interactions between platform components into self

ACKNOWLEDGMENT

This work was carried out and funded in the framework of SMAC project (Semantic-maintenance and life cycle), supported by European program Interreg IV between France and Switzerland.


Cyril Dumont
email: dumontcyril@yahoo.fr

Fabrice Mourlin
email: fabrice.mourlin@wanadoo.fr

Model checking applied to mobile agent system

Keywords: mobile agent system, process algebra, temporal logic, model checking

The subject of this contribution is about use of formal specification in order to prove business properties of a mobile agent system. First, we can be described this kind of system by the use of process algebra, in particular the π-calculus language. Then, from such formal specification, we can generate semi automatically automata using an XML transformation. Finally, we compute acceptance graph to validate a formal property. This validation is assisted by the use of a tool such Uppaal from Aalborg university.

I. INTRODUCTION

Mobile agent systems provide a new approach of software based on adaptability of the system against its runtime context. Also, this means mobile agent is a reactive component like a stimulus recorder device. For example, a mobile agent can interact with resource to extract data. If the resource is missing, it can adapt its behaviour and move on other computer to perform its task.

The relative informality and high level of abstraction of current practice in describing mobile agent system might at first glance suggest that mobile agent descriptions have little substantive value for software engineers. First, over time engineers have evolved a collection of idioms, patterns, and styles of agent system organization that serve as a shared, semantically rich vocabulary between engineers.

Formal models are needed for careful description and reasoning about agents, just as for other kinds of distributed systems. Important issues that arise in modeling agent computation are: agent communication, dynamic creation and destruction of agents, mobility, and naming. How to choose a formal approach ? There are multi factors and is based not only on application domain but also on past experience. And how can we check the specification from this formal approach ? Two questions we will try to answer in this paper.

II. FORMAL SPECIFICATION

Process algebra is widely used for studying concurrent processes (CCS: Milner's Calculus of Communicating Systems [START_REF] Milner | Communication and Concurrency[END_REF], ACP: Bergstra & Klop's Algebra of Communicating Processes [START_REF] Bergstra | Program algebra for component code[END_REF]). But the expression of mobile agent needs use of languages which allow higher order term. Actually a agent is not just a name or a channel but a data structure. More recently, π-calculus language provides such kind of term and mobile agent are expressed as simple as a function call [START_REF] Milner | Communicating and Mobile Systems: the Pi-Calculus[END_REF]. Several semantics are defined for this formal language and tools are built for creating new specification. Also, this language with extensions is selected for specifying our mobile agent system like the the Higher Order π-calculus (HOπ). Extensions are about polyadic communications and higher order term construction. Indeed in the HOπ-calculus not only names, but also agents of arbitrarily high order, can be transmitted.

This core language is rich enough to describe distributed protocol such as SLP (Service Location Protocol) [START_REF] Kempf | Service Location Protocol for Enterprise Networks: Implementing and Deploying a Dynamic Service Finder[END_REF] or detection intrusion system such as AAFID [START_REF] Balasubramaniyan | An architecture for intrusion detection using autonomous agents[END_REF]. We have now experience about process algebra and more precisely with this formal language. Also, we built case studies and our formal specifications were used to drive project construction. This means how mobile agent can move from one computer to another one. This means also the structure of exchanged messages over the network. Some programming logics have been proposed to express properties of π-calculus agents. We can cite the µ-calculus that allows to express a given property is verified by a given process (in π-calculus). Computer-assisted proof adapted to πcalculus are very few. However the Mobility Workbench allows to define agent and to verify some properties. Unfortunately some work as [START_REF] Bernard | Spécification en pi-calcul de l'étude de cas relative au contrôle d'accès[END_REF] show that, despite a important expressive power,the π-calculus and in particular its logics adapted have a lack of suitable model-checkers.

III. TEMPORAL PROPERTIES OF MOBILE AGENT SYSTEM

When mobile agent application is deployed over a network, it can be useful to check traditional assertions. This wish needs a specific approach where initial formal specifications are a basis.

Also we have examined the use of assertions in testing new and improved programming. The kind of properties can be about event occurrence such that specific communication between two agents on a given location. Of course, specifications define formal type for agents, messages, etc . . . But, type checking does not cover all features. Temporal logic is a formalism used to describe how a program state will change with time.

In addition to type checking, assertions provide a great way to determine that various properties are maintained in a mobile agent application. Our interest concerns three categories of common assertion properties. Traditionally, assertion properties fall into one of these three categories. First, preconditions assert that a property holds before execution of a code block. Then, post-conditions assert that a property hold after execution of a code block and finally invariants assert that a property holds before and after the execution of a code block.

As helpful as assertions of these typical forms can be, they don't quite have the range for all the properties we'd like to be able to hold in a mobile agent system. This is just a short list of the types of system properties that can be expressed in a traditional assertion language (properties that we would like verify in agent behaviour when we modeling a system of mobile agents)

• To ensure that any location (i.e. a computer) is visited only once

• To assert that resources are never accessed by unauthorized agents

• To assert that each agent is given a chance to run • To assert that the system will never get itself into deadlock (i.e. two or more agents are waiting on each other) Following are two very useful types of properties that a specifier likes to make that are simply not possible to express with conventional assertions:

• Safety assertions state that certain undesirable states of the agent system will never be reached under any circumstances.

• Liveness assertions state that certain events are guaranteed to occur eventually, for instance, that a given agent will eventually wake up instead of sleeping forever. Temporal logic can help make these assertions. This is a type of modal logic [START_REF] Emerson | sometimes and not never revisited: On branching versus linear time temporal logic[END_REF] that is used for reasoning about changing properties with time. Several modal operators are usually available in temporal logic: always, sometime, until, next.

Here's an example assertion for two agents that asserts they never deadlock. (Note that the boolean method isWaiting is used to check if one agent is waiting a task performed by the other.) always {agent1.isWaiting(agent2)} implies {! agent2.isWaiting(agent1)}

The translation of this formulae is : in all cases during the execution of the mobile agent system , if agent1 is waiting a task performed by agent2 then agent2 can't be waiting a task performed by agent1.

IV. FROM π-CALCULUS SPECIFICATION TO TEMPORAL

LOGIC

To prove that the previous formulae is verified, it is essential to transform our type definitions (written in π-calculus )into automata definition. Also, we defined operators to build timed automata from an agent definition with a structure close to term definition. Because concrete specifications are quite large, these operators are developed as data transformers.

In our case of mobile agent system, our ability to statically check such assertions is paltry, but quality tools exist for checking that these assertions hold during particular runs of the program. We can use UPPAAL [START_REF] Larsen | Uppaal in a nutshell[END_REF], where the two inputs to the model checking problem are the system model and the properties that such a system must satisfy.

We can cite the work done by the creators of the HD Automata Laboratory (HAL) described in [START_REF] Ferrari | A model checking verification environement for mobile processes[END_REF]. The goal of the HAL is to verify properties of mobile systems specified on π-calculus. They pass by an intermediate step, History Dependent automata (HD-automata), to generate ordinary automata from π-calculus agents.

In our case, we will use the power of XML formalism. A choice of more evident that UPPAAL uses this formalism.So we use a XSL transformation (XSLT for eXtensible Stylesheet Transformation) that is an XML operation which transforms an input XML graph into another one. The input XML graph is one of agent definitions. The output XML graph is a skeleton of timed automata. The translation is not complete because of clock definitions and token type. These clocks should not be confused with hardware clocks (local to computer). Clocks should rather be considered as stop watches or chronometers. Time is continuous and all clocks advance at the same rate, though it is possible to test the value of a clock or reset it.

V. CONCLUSION AND FUTURE WORK

Our formal approach has allowed us to model our earlier work on an architecture based on mobile agent for numerical solving [START_REF] Dumont | Space based architecture for numerical solving[END_REF].From a code written in the Java language, we got to specify agents in HOπ-calculus. Translated into a XML graph, these agents have been transformed into automata (with XSLT). This modeling allowed us to verify if such a computation, deployed on our platform, will always end whatever number of agents available for this calculation (using UPPAAL software).

Next step of our work is to manage code generation with the use of formal specification. We first computed a set of automata from pi calculus representations by using congruent operator. We want now to define new operator to get a skeleton of mobile code. Finally, this next step should keep initial assertions into programming definition.