Caractérisation de services métiers PLM : Un exemple d intégration dans le cadre du projet PEGASE

Transcription

1 Caractérisation de services métiers PLM : Un exemple d intégration dans le cadre du projet PEGASE MOUHCINE ZROUKI 1, SOUMAYA EL KADIRI 1, PHILIPPE PERNELLE 1, RACHID BENMOUSSA 2 1 Laboratoire LIESP-DISP, Université de Lyon 1 17, rue de France, Villeurbanne, France abm.mahdi@gmail.com, soumaya.elkadiri@gmail.com, philippe.pernelle@gmail.com 2 Laboratoire MSESYP Ecole Nationale des Sciences Appliquées Marrakech (ENSAM) Université Cadi Ayyad (UCA) Av Abdelkrim khattabi BP 575 Marrakech, Maroc benmoussa@ensa.ac.ma Résumé L approche SOA dans les systèmes d information industriels doit notamment permettre de simplifier l intégration globale des composants métiers. Cette intégration est facilitée grâce aux différents standards permettant de rechercher et d utiliser un service comme une ressource indépendante de la plateforme ou il s exécute. Dans le cadre des systèmes PLM, le besoin d interopérabilité au sein d une entreprise (ou d échange de données inter-entreprises) favorisent la mise en place de ce type d architecture. Cet article présente une démarche d intégration de services métiers de type PLM en complément des approches de normalisation de PLM Service de l OMG. Les services modélisés portent sur le monitoring des activités utilisateurs. Cette intégration est réalisée dans le cadre d une expérimentation du projet PEGASE qui couple une plateforme SeriousGame à une plateforme PLM et mène un suivi de l activité effectuée au sein du SeriousGame. Abstract - SOA approach in industrial information systems aims particularly to carry out the overall integration of business components. This integration is facilitated through various standards that allow researching and using services as an independent resource within the performing platform. In a PLM context, the need for interoperability within a company (or inter-companies) leads to the establishment of this type of architecture. This paper aims at presenting an approach for PLM business services integration, as an extension of standardization approaches defined by OMG PLM Services. The modeled services are mainly dealing with users activities monitoring. Their integration is performed through an experimental project named PEGASE: the main objective is first to connect a Serious Game platform and a PLM system; and then to conduct monitoring control within the SeriousGame. Mots clés PLM, Service de monitoring, ESB. Keywords PLM, ESB, Monitoring Service. 1 INTRODUCTION Les systèmes d informations de type PLM sont un des composants principaux du SI des entreprises industrielles qui développent des produits physiques. En tant qu élément structurant, ces systèmes doivent s intégrer globalement au SI et fonctionner en interaction avec ses autres composants métiers (ERP, MES, CRM, ). D un point de vue générale, l approche SOA (Service Oriented Architecture) donne un cadre générique de structuration, de médiation et d interaction au sein des SI, qui facilite cette intégration, notamment en s appuyant sur des standards (Guennoun M.K., 2006). Si on se place dans le contexte des systèmes PLM, l approche SOA apparait pertinente au vu des interactions nécessaires avec d autres composants métiers. D ailleurs, on peut considérer deux approches principales de standardisation : PLCS Web Services et PLM Services. Bien que portées par des consortiums différents, ces deux approches sont relativement similaires dans leur objectif puisqu elles sont initialement dédiées à l échange de données entre systèmes. De fait, ces propositions autour d une architecture technique, ne répondent pas de façon complète aux besoins métiers induit par l usage d un PLM. Cet article propose une illustration d extension des services métier principalement dédiée au suivi de l activité au sein d un PLM. Dans la première partie, nous présentons les principaux concepts de PLCS-WS (OASIS 2009) et PLM Services (OMG 2009). Puis dans la deuxième partie, nous caractérisons une extension de services PLM centrée sur des services de monitoring. Enfin dans la troisième partie, nous présentons le cadre d expérimentation de ces services autour du projet de recherche PEGASE. 2 L APPROCHE SERVICE DANS LES PLM 2.1 Les SOA et ESB Les Architectures Orienté Service (SOA) se caractérisent par une approche qui permet d intégrer les composants logiciels applicatifs d entreprise comme des services interopérables. Ces services sont basés sur un ensemble de standards, et peuvent simplement être réutilisés pour développer des nouveaux

2 services. Finalement, ce concept est un paradigme pour la réalisation et la maintenance des processus métiers au sein des applications logicielles réparties (Josuttis N.M., 2007). Dans ce contexte, un Service est un composant logiciel autonome et distribué, exposant les fonctionnalités d'un domaine métier. Techniquement un service est logiquement unique, invocable à distance, localisable (notion d annuaires de services) et propose une interface connue et pérenne. La contrainte de base sur les services est le découplage qui correspond à une démarche de réduction des dépendances entre composants. L objectif étant de minimiser l effet des modifications dans un système à processus métier distribués (Anderl R. 2007), (Ben Hmida M., 2007). Dans ce contexte les ESB (Entreprise service Bus) représentent une infrastructure logicielle d intégration permettant de mettre en relation les différents composants logiciels d une SOA au sein de l entreprise, et ce indépendamment des types de protocoles et de messages utilisés (Salatgé N., 2006). permettent notamment de compléter la sémantique du modèle de base dans le cadre d un échange de données. La spécification PLCS-WS complète la démarche de structuration en proposant une interface standardisée d accès et de manipulation de ces structures au sein d un PLM. Le tableau 1 présente un extrait des services définis dans la version 2 de PLCS-WS. Tableau 1. Extrait des principaux WS de PLCS-WS PLCS-WS version 2 BreakdownManagement ChangeManagement DocumentManagement InformationCollectionManagement InLifeManagement MaintenanceManagement PartManagement QueryManagement RequirementManagement SetupManagement SystemManagement WorkspaceManagement Figure 1. Schéma d ESB (Enterprise Service Bus) Les ESB se concentrent sur les fonctions de médiation et de communication des messages entre les services (figure 1) et s'appuient pour cela sur un ensemble de standards des Web Services (SOAP, WSDL,UDDI, JMS, JCA). Les systèmes PLM (Product Lifecycle Management) sont des systèmes d information spécialisés ayant émergés à partir d un ensemble de besoins spécifiques liés aux données techniques du produit industriel : forte complexité des données (CAO, FAO,...), gestion de la traçabilité, contrôle des processus... Ces systèmes ne peuvent donc être considérés comme un service unitaire (Gunpinar E., 2007). En revanche, il est nécessaire de caractériser le cœur des services fournis par un PLM afin de permettre son intégration au sein d une SOA et/ou d un ESB. C est notamment l objet des standards fournis par l OMG et l OASIS PLM Services PLM Services de l OMG est le résultat d une étude menée dans le cadre du projet PDTnet dont l objectif était de fédérer les formats AP214 et XML afin de simplifier les échanges de données entre donneurs d ordre et fournisseur ( PLM Services s appuie sur un modèle de données intégrant PDM Schema, le protocole d application AP214 de la norme STEP, et PDM Enablers ( 2.2 Le contexte normatif L activité normative dans les services (pour le PLM) est principalement développée autour de deux standards : PLCS Web Services de l OASIS et PLM Services de l OMG PLCS -WS PLCS (Product Life Cycle Support) est une norme internationale (ISO ) qui couvre tout le spectre du cycle de vie produit. Initialement, PLCS a pour objectif de permettre la création et la gestion temporelle d un ensemble cohérent d informations relatives à la maintenance des produits. Ces informations sont utilisées pour spécifier et contrôler l ensemble des activités durant le cycle de vie du produit. PLCS propose un modèle de données générique et flexible qui peut être adapté à des besoins industriels spécifiques via l utilisation de bibliothèques de données de référence (Reference Data Libraries RDL). Ces bibliothèques Figure 2. Contexte PIM/PSM de PLM Services (Srinivasan V., 2009) Les spécifications de PLM Services 2.0 s appuient sur un modèle PIM (Platform Independent Model), décomposé en deux modèles : le «informational PIM», représenté en UML

3 (figure 3), couvrant les aspects structurels des données gérées par les services PLM et le «computational PIM» représenté également en UML (Unified Modeling Language) et couvre les aspects fonctionnels des services PLM. Le modèle PSM (Platform Specific Model) est utilisé pour les processus de transformation et de collaboration. Le PSM tel que défini par l'omg est représenté par des schémas XML pour les structures de données et par le WSDL pour les descriptions de services (El Kadiri S., 2010). ordre de difficulté que les processus métiers. Il est relativement aisé de trouver des exemples où l imbrication d un processus métier et un processus de gestion du SI sont tel qu il est impossible de les dissocier car la non-corrélation entre le niveau métier / sémantique et informationnel / instanciation n est pas toujours complète. Dans le cas de PLM Services, ces services se positionnent sur le PIM et le PSM mais le besoin métiers est sur le niveau CIM. Les spécifications de PLM Service proposent finalement une configuration générique pour définir des services au PLM. Cette généricité est possible dans la mesure où la couche PIM structurante (informational PIM) est centré sur les données de type CAO. Toutefois, si l on considère le PLM comme un élément central du système d information, les besoins en termes de services à fournir ne peuvent être totalement fournis par ce standard. Figure 3. Modèle de base du PLM de PLM Services Les deux standards proposés pour les services PLM sont essentiellement pertinents pour l échange de données entre systèmes. Cependant, les services proposés sont relativement peu exploitables dans la construction d un processus métiers. La partie suivante présente d autres services qui ont vocation à caractériser le besoin PLM dans un processus métier. 3 CARACTERISATION D UN SERVICE METIER PLM 3.1 Contexte d identification des services PLM Le besoin de services métiers PLM a été identifié dans le cadre du projet de recherche PEGASE. Ce projet vise à définir une plateforme permettant d aider à la conduite de changement lors de la mise en place d un système PLM. En effet, la mise en place d un projet PLM modifie en profondeur l organisation de l entreprise et les pratiques professionnelles occasionnant des résistances voir des rejets (El Kadiri S., 2009). La réussite et l acceptation d un tel projet, nécessitent la mise en place d une réelle politique de changement. L objet de ce projet est d outiller cette conduite de changement grâce aux Serious Games et à des scénarios d apprentissage (et/ou de découverte et/ou de formation) spécifiques (Bissay and al, 2011). En corrélation aux aspects ludiques des Serious Games, la définition de scénarios pédagogiques a montré la nécessite d associer un certain nombre de fonctions métiers représentatives des avantages et des inconvénients du PLM. Cela nécessite par conséquent une forte interopérabilité entre l environnement de jeu et la plateforme de contenu du PLM, qui sera établie à travers l identification d un ensemble de services. Tableau 1. Disponibilité des services de base pour un PLM Service PLM Ser. PLCS-WS Contrôle d accès / + + Autorisation Echange de données + + Gestion de modification + + Gestion du suivi - - Recherche d informations + + Gestion de configuration Vers un service de monitoring PLM Le besoin de monitoring est peu couvert par les normes PLCS- WS et PLM Services. Ce type de service doit permettre de connaitre l activité réalisée au sein d un système PLM. Cette activité est diverse : - Action collaborative d un groupe sur les objets - Action individuelle d un utilisateur sur les objets - Evénement de transformation (état, version, dépendance, statut) des objets dans le cadre d une action manuelle ou automatique. Les principes d un système de monitoring pour le PLM (El Kadiri S., 2009) sont définis par deux caractéristiques principales (Figure 4) : - L observation des actions menées au sein du PLM pour déceler d éventuels points de blocages. Cette observation se fait via l analyse des traces générées par le système (rapports de traces) complétée par l analyse des données issues des différentes bases de données. - La mise en place d indicateurs de suivi, afin d assurer un pilotage régulier et d analyser et repérer les manques de fluidité. 3.2 Discussion sur les services métier pour le PLM Les services proposés dans les standards PLM Service et PLCS WS sont décrit sous la forme de WebService. Ces services ont vocation à être implémentés au sein d une architecture PLM mais ils ne permettent une couverture exhaustive des différentes fonctionnalités d un tel système. Implicitement, la question des services métiers du PLM se pose dans le même Figure 4. Niveau fonctionnel d un service de monitoring pour un système PLM

4 La figure 5 décrit l architecture globale des services de monitoring avec les participants identifiés. La figure 6 présente un extrait des contrats entre les participants et notamment les liens «consommateur-fournisseur» de service. Figure 5. Diagramme SoaML de l architecture du service PLM Monitoring Figure 7. Cas d usage UML d un service de monitoring pour un PLM Il est à noter que les rapports de traces représentent la suite des interactions mémorisées de l acteur interagissant avec le système. L acteur utilise en effet des ressources pour mener une action dans le cadre d une activité donnée. Les rapports de traces nécessitent un traitement pour collecter et structurer les informations nécessaires à l observation. Afin de mettre en œuvre une analyse spécifique, nous proposons dès lors de une structure de trace générique applicable aux PLM <Acteur, Activité, Action, Objet, Contexte> selon un schéma XSD (Figure 8). Figure 6. Diagramme SoaML des contrats de services Dans ce contexte nous distinguons les actions de gestion (construire les sondes, produire les indicateurs) des actions d utilisation des utilisateurs finaux (qui pourraient être d ailleurs d autres services). Par ailleurs, le service de monitoring doit ainsi permettre de gérer les sondes sur les deux sources d observation utilisées (rapports de traces et BD) afin de mettre en place le processus d observation. Ces sondes permettent la génération d éléments abstraits, et constituent une base effective pour la construction des indicateurs de suivi. La méthodologie proposée dans (El Kadiri, 2009) permet de définir deux catégories d indicateurs : élémentaires et flous. Enfin, les besoins en termes d outils de notification et de visualisation sont indispensables afin de faciliter l interprétation des résultats obtenus via les indicateurs (Figure 7). Figure 8. Représentation XSD du contexte d observation Cette structure peut notamment utiliser les objets définis dans OMG PLM services. En l occurrence les packages de modèles de données associés aux éléments constituant le contexte d extraction : Change_and_work_management_Package ; Part_identification_Package ; Authorization_Package (Figure 9).

5 Figure 9. Diagramme de classe des messages du service de monitoring La structure générique des messages et des actions élémentaires permettent de créer des sondes en construisant un processus BPMN (Figure 10) qui invoquent les Web Services élémentaire. L intérêt de cette démarche, qui est facilité par le fait qu il n y a pas d interaction utilisateur, est d avoir un processus descriptif qui peut être converti dans un processus exécutable (de type BPEL). Figure 11. Processus de mise au point d outillage du projet PEGASE Ce processus industriel nécessite l usage, en termes de services PLM, des éléments suivants : - Service de connexion - Service de recherche d objet métier - Service création d objet métier - Service d exécution d un processus - Service de monitoring de l activité utilisateur Dans notre contexte, le choix d ESB permet de garantir le transport et des flux de message tout en proposant des mécanismes d accès divers (SOAP, REST,..). La figure suivante (Figure 12) présente l architecture globale du projet autour d une plateforme de jeu et d une plateforme de contenu. Figure 10. Exemple de diagramme BPMN de construction de sonde Les différents éléments présentés dans cette partie caractérisent notre proposition de service générique de monitoring pour le PLM. Dans le paragraphe suivant, nous décrivons une illustration de l usage dans le contexte du projet PEGASE. 4 CONTEXTE D EXPERIMENTATION DES SERVICES PLM 4.1 L architecture d expérimentation Dans le cadre du projet PEGASE, nous avons utilisé la plateforme PLM Audros (Audros technologie) et la plateforme Serious Game (basée sur Java Monkey Engine et RedDwarf) développée par le laboratoire SYSCOM (Figure 12). Initié par les besoins des scénarios pédagogiques, les actions d apprentissage et de découverte ont été identifiées à partir d un processus métier simple qui permettait de mettre en évidence des fonctions de base d un système PLM. Ce processus concerne le traitement d une commande de mise au point d outillage (moule) dans le domaine de la plasturgie (Figure 11). Figure 12. Architecture du projet PEGASE le modèle du scénario pédagogique étant bâtit en fonction de processus métiers, ils permettent de mettre en évidence (ou d utiliser) des services métiers PLM. L intérêt majeur de cette architecture est notamment dans la capacité dynamique des scénarios. Il est possible en cours de séance de rajouter une tâche ou une action afin d adapter dynamiquement la séquence d apprentissage. Cette possibilité est réalisable grâce aux outils de recherche d un service PLM (notamment de monitoring), et à son usage. 4.2 Utilisation des services de monitoring Dans ce contexte d expérimentation, l activité de l utilisateur avec le PLM est conduite par un processus industriel de traitement de commande d outillage dans le domaine de la plasturgie. Le rapport de traces est l élément d observation et

6 d analyse le plus important dans le contexte d une expérience d observation. D autant plus que les systèmes PLM sont dotés de grandes capacités de traçabilité. Le service de monitoring structure la trace du PLM et fournit les méthodes de son exploitation (mise en place de sonde/d indicateur). Le scénario de découverte que nous avons expérimenté, met en évidence des actions et des situations de jeu dont quelques usages sont explicités ci-dessous : 1. Service de connexion : l utilisateur se connecte sur la plateforme de jeu avec un personnage joueur virtuel qui s identifie sur le système PLM (Serveur de Jeu ESB) 4. Service de suivi de l activité : les actions du joueur au sein du système PLM sont tracées et reconstruites sur la structure présentée en figure 6 (par le vecteur <Acteur, Activité, Action, Objet, Contexte>). Dans ce contexte l intérêt des services de monitoring est de pouvoir définir un ensemble d indicateurs spécifiques pour les besoins d un scénario. Dans notre cas, le service de construction (manager) a défini des sondes sur : - les actions de création de tous les joueurs - l événement de déclenchement du processus de validation - l action de choix du formateur sur le processus de validation Il faut par ailleurs préciser que ces services sont accessibles selon deux modes d usage différents : par le formateur qui construit son scénario (via WS & SOAP) et/ou par le serveur de trace (via REST) qui gère les traces globales du jeu (déplacement, interaction PNJ, activités). Figure 13. Access au service de connexion 2. Service de recherche : en cours de jeu, le processus industriel simulé nécessite la recherche d informations sur des objets métiers caractéristiques du processus industriel choisi et présent dans le PLM. (Serveur de Jeu ESB, ESB Serveur de Trace) Figure 16. Action spécifique dans Audros tracée et restituée par le service de monitoring Figure 14. Recherche d une présentation 3. Suivi de création d objet métier : la création d une commande de mise au de moule est mise en œuvre manuellement par l utilisateur virtuel puis dans le PLM. Ici, c est cette action qui est suivie par le service de monitoring et puis «poussée» dans le serveur de trace (ESB Serveur de Trace) 5. Service de reconfiguration de scénario : le formateur peut reconfigurer le scénario dynamiquement en associant un service métier à un taches/objectif de jeu (ex : demander une «recherche par cas d emploi» à un joueur pour le ralentir et valider la sonde qui permet de vérifier si la requête a bien été faite) Figure 17. Formateur présent dans le Jeu Figure 15. Création d une commande 5 CONCLUSION Le cycle de vie complet des produits fait intervenir de nombreux processus complexes et emploie de nombreux applications et systèmes. Mener une approche PLM implique la modélisation, la capture, la manipulation, l'échange et l intégration de l'information dans tous les processus décisionnels le long du cycle de vie du produit, et ce quelque soit les domaines d'application. C est dans ce contexte que les efforts de normalisation viennent répondre à cette complexité. Plus particulièrement, nous nous sommes intéressés à l étude de deux approches de standardisation PLCS WebServices et

7 PLM Services. Ces deux standards s appuient sur une approche orientée services. Cependant, ils ne répondent pas de façon complète aux besoins métiers induit par l usage d un PLM. Cet article présente une démarche d intégration de services métiers de type PLM en complément des approches de normalisation de PLM Services de l OMG. Les services modélisés portent sur le monitoring des activités utilisateurs. Cette intégration est réalisée dans le cadre d une expérimentation du projet de recheche PEGASE qui couple une plateforme SeriousGame à une plateforme PLM et mène un suivi de l activité effectuée au sein du PLM. OMG, (2009) Product Lifecycle Management Services Salatgé N., (2006) Conception et mise en œuvre d une plateforme pour la sûreté de fonctionnement des Services. Thèse, INPT. Srinivasan V., (2009) STEP in the context of Product Data Management in Advanced Design and Manufacturing Based on STEP, Springer. Au travers la modélisation de services PLM, nous avons pu montrer l intérêt d une architecture de médiation basée sur un bus de services. L intérêt est double : - Le premier est d être capable de proposer finalement une indépendance vis à vis du système PLM, et ce grâce à l emploi d un modèle de données standard couplé avec le «Informational PIM» de l OMG PLM Services ; - Le second est de pouvoir s adapter dans les usages. En effet, dans une approche basée sur la reconfiguration dynamique d un processus (pour notre expérimentation, le scénario d apprentissage), on peut faire appel aux services métier en les associant à une tache ou un objectif précis (exemple de PEGASE : demander une recherche par cas d emploi à un joueur pour le ralentir et valider la sonde qui permet de vérifier si la requête a bien été faite). Les services de monitoring que nous avons proposé facilitent la mise en œuvre d une approche par les services. Il serait nécessaire de vérifier si une approche peut être validée avec des services métiers plus complexes, notamment lors que le service à un couplage très fort avec les données du PLM. 6 REFERENCES Anderl R., Rezaei M., (2007) Federative Factory Data Management. An Approach Based Upon Service Oriented Architecture (SOA). Springer US. Ben Hmida M., Haddad S., (2007) Vers une adaptabilité dynamique des architectures orientées services : une approche basée sur la programmation par aspect et les algèbres de processus. In JFDLPA 07, pages Bissay A., Zrouki M., Cheballah K., Pernelle P. (2011) PEGASE: a platform tool to help change management support during the implementation of a PLM system in an industrial company PLM 11, Eindhoven. El Kadiri S., Hossain S.A., Bouras A., (2010) Etude et analyse des standards pour les solutions techniques dédiées au PLM, CIM 10, Tunisie. El Kadiri S., (2009) Management des processus collaboratifs dans les systèmes PLM. Thèse, Université de Lyon. Guennoun M.K., (2006) Architectures Dynamiques dans le Contexte des Applications à Base de Composants et Orientées Services. Thèse, ENIS. Gunpinar E., Han S., (2007) Interfacing heterogeneous PDM systems using the PLM Services, International Journal of Advanced Engineering Informatics, Elsevier. Josuttis N.M., (2007) SOA in practice: the art of distributed system design. O'REILLY. OASIS (2009) PLCS Web services V2