Cooperative Systems Modeling, Example of a Cooperative e-maintenance System

Cooperative Systems Modeling, Example of a Cooperative e-maintenance System David Saint-Voirin PhD Student LIFC 1 -LAB 2 saint-voirin@lifc.univ-fcomte.fr Christophe Lang Assistant Professor LIFC 1 lang@lifc.univ-fcomte.fr Noureddine Zerhouni Professor LAB 2 noureddine.zerhouni@ens2m.fr Hervé Guyennet Professor LIFC 1 guyennet@lifc.univ-fcomte.fr July 4, 2005

2 Laboratories 1 : Laboratoire d Informatique de l Université de Franche-Comté. CNRS FRE 2661 16, Route de Gray 25030 BESANCON Cedex-FRANCE http://lifc.univ-fcomte.fr 2 : Laboratoire d Automatique de Besancon CNRS UMR 6596 25, rue Alain SAVARY 25 000 Besancon, FRANCE http://www.lab.cnrs.fr/index2.html Abstract Cooperation is an efficiency factor in many activities like design, medicine or maintenance. Several researches try to optimize cooperation activity by using tools or algorithms designed to enhance human interaction. Few researches are made on conceptual cooperation modeling. However, industrials want to compare different algorithms, organizations or cooperation modes. It is also useful to represent these systems in order to simplify design operations. We proposed our cooperating systems modeling in our previous work [13]. This one provides a simulation approach to answer this needs. In this paper, we present an application of our modeling principles on an existing e-maintenance system. This system is part of our work on the European PROTEUS project [ITEA 01011, http://www.proteus-iteaproject.com/] [6]. By using these modeling principles, industrials should be able to represent and simulate their remote maintenance systems in order to optimize them. 0.1 Context, related work New technologies used in industrial context open the gate to new interconnected system abilities. Cooperative systems take advantage of this situation. New ways of communication means, mobile terminals and data access modes to improve cooperation possibilities. Mobility inside the cooperative system is for example a major contribution which allows users to work together in new places. However, we can t quantify the profit generated by the use of a technology or another, or the use of a particular organization in a given cooperative system. There is a strong need for an efficient model. The lack of cooperative systems formal models is in fact due to their complexity. Cooperation has been studied a lot in a general meaning, often oriented

0.1. CONTEXT, RELATED WORK 3 by sociological researches revolving around human direct cooperation [2]. Cooperative systems are studied in the CSCW (Computer Supported Cooperative Work) researches [14, 3, 6]. These researches propose cooperation tools in accordance with cooperation needs and technical restrictions. New cooperation tools are created using more and more technological improvements. However, efficiency of cooperation within a complex computerized remote system (with several different tools, with a particular cooperation algorithm...) is still a preoccupation for industrials who are users of these systems. We presented our cooperative systems meta-model in [13]. It is based on our cooperative systems components classification in four different parts. We admit that cooperation is a complex mechanism involving 1 : Knowledge possessed by actors, Specific behavior of the actors, Organization of the actors group, Communication means between actors. Our meta-model is built on the use of multi-agent systems because of their ability to represent individual behaviors and individual knowledge [2, 1]. Multi-agents systems allow computer models and simulation of cooperative systems. Artificial intelligence level of each agent is what makes the model precise or not. Specific cooperative behaviors have to be integrated. We defined a concrete nomenclature of human agents, equipment agents, communications possibilities and shared data access possibilities [13]. Colored Petri nets [7, 9] allow us to represent mutual exclusion on synchronized communications and shared data accesses. Network availability constraints are also represented using Petri nets. Knowledge of cooperative members is represented using an XML formalism. Individual behaviors are modeled with a PLOOM - UNITY formalism. This one is based on UNITY formalism [12] on which we add inheritance. In this paper, we present an application example of this modeling. This example is taken from our work on the European PROTEUS project [ITEA 01011, http://www.proteus-iteaproject.com/] [6] which concerns the development of a generic e-maintenance cooperative platform. In a first part, we describe the system to be modeled in terms of members, organization and communication means. Then we specify our modeling hypothesis. The third part shows the use of our meta-model to represent the e-maintenance system. 1 In the following definition, an actor can be a person or an equipment

4 0.2 The system to be modeled The system we propose to model is a prototype of a complete e-maintenance platform. In it s final version, this platform is designed for a firm working on the maintenance tasks of several distributed industrial sites. However, in the prototype, only one site has to be maintained. In this part, we describe the system proposed in the prototype according to our cooperative systems description in four points (see part 0.1). 0.2.1 e-maintenance members A member may be an equipment or a human working in the system. We speak about human members and equipment members. Members are the basis for the cooperation [13]. Equipment members are described by the information they can deliver and by their behaviors representing their functions or services. Human members are described by their own knowledge and their individual behaviors. Behaviors and knowledge of each member are described in the next part. Equipment members SORMEL Transfer system : it is basically an industrial tool which have to be maintained by the maintenance firm. This equipment break down depending on a known probabilistic law. SCADA PC Vue : this system is composed of sensors representing SORMEL Transfer system state. It also proposes an interface to access these sensors data in real time. The SCADA automatically checks the sensors data within a defined period of time. It is also able to produce an alarm when a sensor data is out of preselected limits. Web camera with integrated web server allowing remote movement control : this camera allows authorized users to see the SORMEL transfer system. Only authorized users are allowed to pilot camera movements. e-documentation : in our prototype, there is only one e-documentation server. This one is an XML e-documentation server containing several different kinds of data : videos, repair task lists, drawings etc... The behavior of this server is to return or not a document requested by an user. CMMS (Computerized Maintenance Management System) Maximo (software tools) : This is a set of software tools used in maintenance activity to improve specific tasks of maintenance. These tools may be considered as e-documentation, but they are more specific because of their particular functions.

0.2. THE SYSTEM TO BE MODELED 5 Human members Maintenance technician : he is the person who works on technical aspects of the maintenance (repairing tools...). He has knowledge in a specific work domain. He may be in a different site than the breakdown site. In this case, he is able to help another technician to do his work. His goal is to repair the breakdown and his behavior is to respect maintenance manager orders. In the prototype, an electricity specialized technician is present at the breakdown site and a mechanical specialized technician stay in another site. Both technicians have a partial environment representation : They don t know the existence of CMMS tools They know the existence of all other equipment and members in the system Maintenance manager : He manages maintenance operations in respect of signed contracts. He knows the speciality of each member of his team. His role is to manage human resources, tools and spare parts. His goal is to fix the breakdown the fastest, using human and equipment resources. 0.2.2 Members group organization Organization of a group is present at several levels : Geographically speaking, hierarchically speaking and legally speaking. We describe these three aspects in this part. Geographical organization In the PROTEUS prototype, members are distributed in three sites : Workshop 1 : SORMEL transfer system, SCADA, electricity specialized technician (electrician), web-camera Workshop 2 : e-documentation, CMMS Maximo, mechanical specialized technician (mechanist), Maintenance driving room : maintenance manager. Hierarchical organization Hierarchical organization concerns human members. In our system, maintenance manager is the immediate superior of the two technicians who are at the same hierarchical level.

6 Class human Declare : name : String // Agent name belief : XML DTD // agent environment knowledge, XML DTD // agent skills desire : XML DTD // agent goals End Class Figure 1: Human agent formal model Class maintenance Manager Extends Human Declare : Function givecommunicationauthorisation(agent) Function stopcommunication() Function giveacces(agent, Resource) Function stopacces(resource) Function includenewagentingroup Function removeagentfromgroup Function applycooperationrules() Initially : belief= <cooperation rules> Centralized manager cooperation rules </cooperation rules>... desire= <Goal> Work on the maintenance problem until its solution </Goal> Assign : While (!desire) do applycooperationrules() End while End Class Figure 2: Maintenance manager

0.2. THE SYSTEM TO BE MODELED 7 Class maintenance Technician Extends Human Declare : Function asktospeak () Function askforjoininggroup () Function askforleavinggroup () Function applycooperationrules() Initially : belief=<cooperation Rules> Centralized cooperation member rules </Cooperation Rules>... desire= <Goal> Work in cooperation with people of cooperating groups </Goal> Assign : While (!desire) do applycooperationrules() End while End Class Figure 3: Maintenance technician Tech1 Tech2 maintenance manager SORMEL transfer system A D M V SCADA V V V Camera V V V M e-doc server V V V A D M Software tools (CMMS) V A D M V : Visualisation / D : Delete / A : Add / M : Modification Table 1: Access rights on shared resources Legal organization Legal organization is composed of laws or rules that represent access rights authorizations and communications authorizations. It also includes the group members management mode. In the PROTEUS prototype, communications and shared resources access must be accepted by the maintenance manager. Group member management follows this pattern : If a member wants to join or leave the group, his request must be accepted by maintenance manager. The maintenance manager can force a member to leave or join the group. Access rights on shared resources in the PROTEUS system are defined in the table 1.

8 0.2.3 Communication means Each person using the prototype system has a PDA which is connected to the Internet by a wifi local LAN. Software and hardware specific tools are used on these PDA to allow peer to peer communications (microphone, headphones, camera, glasses with integrated micro-screen). Workers in the system also use PDA to consult e-documentation or web-camera. 0.3 Modeling hypothesis In this part, we describe our modeling hypothesis, which define the limits of our representation. 0.3.1 System determinism level Communication establishment time between modeled members is represented by probabilistic rules. However, we consider that messages always get their goal. We also consider that members always understand each other. That s the reason why for the moment, we don t represent semantic content of communication exchanges or documentation queries. At last, we consider that members always behave the way we expect. This means that members will react to a specific situation using the adapted behavior. 0.3.2 Mobility in the system A geographical position change is what we call mobility in our problem. In PROTEUS prototype, we don t represent mobility of the members. In fact, it does not need to be represented because PROTEUS prototype does not allow geographical position change for its members. 0.4 Sample system modeling Members are represented by agents which possess behaviors and knowledge. This representation is completed by an interaction model and an organization model (see figure 4). Communication establishment follow colored Petri nets description. 0.4.1 Agent representation Knowledge representation There is three knowledge types to be represented :

0.4. SAMPLE SYSTEM MODELING 9 SORMEL Workshop 1 1 2 Electrician Workshop 1 SCADA Workshop 1 Class maintenance_technician Machinist 1 Workshop 2 CAMERA Workshop 1 1 Class maintenance_technician 2 1 Maintenance manager Maintenance driving room Class maintenance_manager 1 e doc 2 Workshop 2 CMMS Maximo Contracts Breakdown Human res DataBase history DB planification Tools management Spare parts management Workshop 2 Workshop 2 Workshop 2 Workshop 2 Workshop 2 Figure 4: Organization and interaction model

10 member wants to communicate with member 2 <1 2 4, 1 3 4, 2 3 4> <1 2 4, 1 3 4, 2 3 4> <1,3> <1,3> Communication <2,3> <1,2> Member available Network channels availability 1,2,3 4 4 4 Member wants to communicate with member 1 <2,3> <1,2> member wants to communicate with member 3 <1,2,3> <1,2,3> Member does not want to be disturbed Figure 5: Mutual exclusion representation for peer to peer communications establishment Skills Goals Environment knowledge Agent knowledge is represented using an XML formalism based on an XML tag description (DTD). Here is the XML description for the mechanical specialized technician : <environment knowledge> <Geographical position>workshop2 </Geographical position> <Hierarchical rank>2 </Hierarchical rank> <Known equipement members> SORMEL Transfer system, SCADA, Camera, e-doc server </Known equipement members> <Known human members> Electricity specialized technician,

0.4. SAMPLE SYSTEM MODELING 11 Maintenance manager </Known human members> <Cooperation rules>wait for maintenance manager authorization for communications and shared data access </cooperation rules> </environment knowledge> <Skills> <Speciality domain>mechanic </Speciality domain> </Skills> <Goals> <Primary Goal>Fix the breakdown </Primary goal> <Secundary goal> Respect cooperation rules </Secundary goal> </Goals> Behavior representation a PLOOM-UNITY [12] formalism is used to describe agents behaviors. It s an object typed formalism which allows agent description using inheritance. In figure 1, we see the generic human class which is the father of maintenance manager class, (see figure 2), and the father of maintenance technician class (see figure 3). 0.4.2 Interaction and organization model Our nomenclature defined in [13] helps us to draw interaction model and organization model of the studied system (see figure 4). Interaction between members is specified with communication nomenclature and shared data access nomenclature. Mutual exclusion is represented with colored Petri nets (see figure 5). The three colors (1,2,3) represent the three human actors (1 = Electrician, 2= Mechanist, 3 = Maintenance manager). Organization is graphically shown in the agent nomenclature representation (geographical and hierarchical organization), however, organization characteristics are described in environment agent knowledge. Organization information are given for graphical reading on figure 4.

12 Idle member Member is using <1 3, 2 3> web camera <1 3, 2 3> 1,2 3 web camera available Figure 6: Mutual exclusion representation using colored Petri nets for webcamera control actions 0.5 Conclusion and prospects In this work we show the generic and unified aspect of our meta-model. Indeed, existing system representation is rather easy and complexity representation level is flexible. A specific XML DTD for maintenance knowledge representation is being developed. XML knowledge representation allows us to create a relevant ontology for agent communications and data requests. ACL (Agent Communication Language) researches help us in this task. Adaptative agents could be used in our representation to improve simulation realism by allowing agents to learn new capacities. However, our current work is to compute this example in order to extract simulation results and compare them to the real system. The goal is to extract quantitative and qualitative results about system performances. This work is done in two parts. First, communication establishment Petri nets are upgraded to stochastic Petri nets. This allow to integer basic agents behaviors in these Petri nets as probabilistic rules. Quantitative results will be extracted from this work. In a second time, the real multi-agent system will be developed with JAVA and MadKit library. Communication Petri nets will be used as algorithm specification in this case. We want then to propose generic optimisation principles for cooperative systems. This work needs to represent and simulate several cooperative systems.

Bibliography [1] Multi-Agent System: An Introduction to Distributed Artificial Intelligence. JASS, 1999. [2] S. Abrilian, S. Buisine, C. Rendu, and J. C. Martin. Specifying cooperation between modalities in lifelike animated agents. In Working notes of the international workshop of lifelike animated agents : tools, functions and applications, Held in conjunction with the 7th Pacific Rim International Conference on Artificial Intelligence (PRICAI 02), pages 3 8, Tokyo, Japan, August 19 2002. [3] T. Ba, E. Garcia, H. Guyennet, J. C. Lapayre, N. Zerhouni, and R. Zemouri. Temic : Industrial cooperative telemaintenance. In ICCIE 01 International Conference on Computers and Industrial Engineering, page a trouver, Montreal, Canada, November 2001. [4] S. Buisine and J. C. Martin. Design principles for cooperation between modalities in bi directional multimodal interfaces. In CHI 2003 workshop on principles for multimodal user interface design, Florida, 5-10 April 2003. [5] M. Diaz. A logical model of cooperation. Technical Report 92016, LAAS, January 1992. [6] M. Thron J.P. Thomesse X. Reboeuf C. Lang E. Garcia J. Szymanski, T. Bangemann. Proteus - a european initiative for e-maintenance platform development. In 9th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA2003, Lisboa Portugal, 16-19 September 2003. [7] Kurt Jensen. An introduction to the practical use of coloured petri nets. Lecture Notes in Computer Science, Lectures on Petri Nets II: Applications, 1492:237 292, 2004. [8] J-C. Martin. six primitive types of cooperation for observing, evaluating and specifying cooperations. In AAAI Symposium on Psychological Models of Communication in Collaborative Systems, Sea Crest Conference Center on Cape Cod, North Falmouth, Massachusetts, USA, November 1999. 13

14 BIBLIOGRAPHY [9] G. Saake N. Aoumeur. A component-based petri net model for specifying and validating cooperative information systems. Data and Knowledge Engineering Journal, 44(2):143 187, August 2002. [10] J. Odell, H. Van Dyke Parunak, and B. Bauer. Extending uml for agents. In AOIS Workshop at AAAI 2000, 2000. [11] L. M. Rodriguez Peralta, T. Villemur, and K. Drira. An xml on-line session model based on graphs for synchronous cooperative groups. In International conference on parallel and distributed processing techniques and applications PDPTA 2001, pages 1257 1263, 25-28 June 2001. [12] Gruia-Catalin Roman, Peter J. McCann, and Jerome Y. Plun. Mobile UNITY: Reasoning and specification in mobile computing. ACM Transactions On Software Engineering And Methodology, 6(3):250 282, 1997. [13] D. Saint-Voirin, C. Lang, and N. Zerhouni. Distributed cooperation modeling for maintenance using petri nets and multi-agents systems. In International Symposium on Computational Intelligence in Robotics and Automation, CIRA 03, pages 366 371, Kobe Portopia Hotel, Kobe, Japan, July 16-20 2003. IEEE. [14] Johann H. Sclichter Uwe M. Borghoff. Computer-supported cooperative work, introduction to distributed applications. Springer, 2000.