Sortie d’OpenPLM version 1.1

Posté par  . Édité par Davy Defaud, baud123, Nÿco, Benoît Sibaud, claudex, Florent Zara et Benoît. Modéré par Nÿco. Licence CC By‑SA.
Étiquettes :
24
11
sept.
2012
Commercial

OpenPLM, solution libre (GPL v3) de Product Lifecycle Management (PLM — gestion du cycle de vie d’un produit), développée par LinObject vient de sortir en version 1.1. OpenPLM est une solution Web qui repose sur le framework Web Django et est naturellement écrite en Python.

Parmi les nouveautés de la version 1.1, on peut noter les améliorations suivantes :

  • affichage de barres de progression lors de l’envoi de fichiers au serveur ;
  • transfert de plusieurs fichiers à la fois ;
  • des nouvelles possibilités pour explorer les contenus gérés ;
  • diverses améliorations de l’affichage des fichiers 3D via WebGL (sélection des vues, meilleur rendu) ;
  • l’affichage des fichiers STL (binaire et ASCII) ;
  • une application permettant d’exporter une nomenclature définie dans OpenPLM vers un serveur OpenERP ;
  • le support partiel de WebDAV pour récupérer, modifier et créer des fichiers ;
  • une documentation plus complète et partiellement traduite en français : la priorité est donnée à la traduction des documents destinés aux utilisateurs et administrateurs.

La liste complète des nouveautés (avec de nombreuses captures d’écran) est disponible via le lien ci‐dessous.

Sommaire

Principes du PLM

Une solution PLM permet de gérer le développement d’un produit en structurant celui-ci et en facilitant la gestion des documents qui lui sont liés.

Dans le monde du PLM, on sépare les produits (également nommés articles, ou parts) des documents. Les parts possèdent des attributs et sont décomposables suivant une ou plusieurs nomenclatures. Une nomenclature (nommée Bill Of Material — BOM — dans la littérature anglophone) liste l’ensemble des parts composant un assemblage.

Les documents représentent les fichiers ou des ressources similaires (comme une donnée en ligne ou un livre papier). Les documents sont attachés à un ou plusieurs parts.

Ainsi, il est possible de suivre l’évolution d’un ensemble cohérent (le produit, ses sous‐ensembles et leurs documents) ou de ne s’intéresser qu’à un seul document. La séparation entre part et document peut paraître superflue, mais elle permet de lier plusieurs parts vers un même document (telle qu’une norme ou une licence) et de tracer l’évolution d’un produit.

Par exemple, une entreprise qui conçoit des vélos peut structurer ses différents vélos suivant les pièces qui les composent. À chaque pièce peuvent être attachés plusieurs documents, tels que des plans de conception, des résultats de simulations, etc. Un PLM permet alors (s’il est bien conçu) de facilement suivre le développement des vélos et de faciliter la création de nouvelles versions (révisions) des produits.

Dans un PLM, chaque part ou document est lié à un cycle de vie. Ce cycle de vie représente les différents états que peut prendre l’élément. Généralement, un part commence dans un état brouillon, et peut être promu d’état en état afin d’être officialisé, l’officialisation pouvant signifier que la production peut être lancée. Un PLM permet également de marquer des éléments comme obsolètes. Il est ainsi possible de s’assurer de l’intégrité d’un assemblage, et d’être certain que tous ses composants sont officiels et non pas à l’état brouillon ou obsolètes, et qu’il peuvent donc être fabriqués.

La gestion des fichiers dans un PLM est assez similaire à celle d’un gestionnaire de versions, et dans le cas d’OpenPLM, centralisé. Cependant, compte tenu des tailles des fichiers (qui dépassent souvent la centaine de Mio), il n’est pas possible de stocker en local l’ensemble du dépôt. De plus, la plupart des formats de CAO ne permettent pas de proposer une interface simple de fusion de documents contrairement aux gestionnaires de versions, qui se débrouillent plus ou moins bien avec des fichiers texte.

Les solutions PLM sont très utilisées par les industries automobiles et aéronautiques, notamment en raison des contraintes légales qui obligent ces industries à conserver sur de longues périodes les plans de conception de leurs produits.

Parmi les concurrents d’OpenPLM, on peut citer les solutions propriétaires Enovia MatrixOne de Dassault Systèmes, Teamcenter de Siemens PLM, Windchil de PTC ou encore Audodesk 360. Parmi les alternatives open source, il y a OpenERP-PLM, RanchBE, ou encore Aras Innovator.

Pour ceux qui souhaitent en savoir plus sur le PLM, je ne peux que conseiller de lire les documents de l’association PLM lab, dont ce PDF qui récapitule les définitions des termes liés au monde du PLM.

Petit tour des fonctionnalités

OpenPLM présente les fonctionnalités principales d’un PLM : la gestion des parts et des nomenclatures, ainsi que la gestion des documents et de leurs fichiers.

Dans OpenPLM, le typage des parts et documents se fait de manière hiérarchisée, en suivant un principe très similaire à l’héritage des classes en programmation orientée objet. Ainsi, il est possible d’ajouter des attributs aux parts et documents, et d’étendre les fonctionnalités en rajoutant des modèles de données. Cela permet notamment de renseigner des champs spécifiques.

Plusieurs moyens sont disponibles pour explorer les données. Il est possible de parcourir les parts, documents et autres données suivant leur état, date de création, etc. Bien entendu, il est possible d’effectuer une recherche. OpenPLM est également capable de créer des graphes pour représenter visuellement une nomenclature et voir quels sont les liens entres parts et documents.

La gestion des droits d’accès se fait via des groupes. Chaque part ou document appartient à un groupe et un élément non officiel n’est visible que des membres du groupes. Chaque propriétaire de groupe gère lui‐même les membres, et un utilisateur peut demander à joindre un groupe. Un utilisateur peut déléguer ses droits en cas d’absence. Il existe également un type de compte particulier très restreint. Ce type de compte ne peut accéder qu’à un résumé d’éléments dont on lui a accordé l’accès. Cet accès restreint est prévu pour permettre à des clients ou fournisseurs d’accéder à une partie des données gérées par le PLM.

Support du standard STEP

Le monde du PLM est historiquement très lié au monde de la CAO. La plupart des logiciels de CAO sont propriétaires et utilisent des formats de fichiers fermés et non documentés. Néanmoins, il existe un standard, STEP, pour l’échange de données de produit, standard normalisé par l’ISO et supporté par de nombreux logiciels de CAO et de simulation numérique. Grâce à Python-OCC, OpenPLM peut exploiter les fichiers STEP et propose notamment les fonctionnalités suivantes :

  • l’affichage des géométries 3D dans le navigateur si celui‐ci prend en charge WebGL ;
  • la décomposition de la nomenclature définie dans le fichier STEP en parts et documents, cela facilite notamment l’importation de données existantes ;
  • la recomposition du fichier STEP en tenant compte de l’état actuel de la nomenclature.

Vous pouvez suivre le lien pour tester l’affichage d’un assemblage en 3D via WebGL.

Intégration avec des logiciels tiers

OpenPLM est pleinement exploitable en utilisant un navigateur Web, mais il est également possible de s’en passer pour effectuer certaines tâches.

Un accès WebDAV est disponible. La prise en charge de WebDAV n’est pas encore complète, mais l’on peut d’ores et déjà parcourir les documents et accéder aux fichiers en lecture. La création et la suppression de fichiers sont également supportées, mais les verrous et modifications de propriétés ne sont pas encore implémentées.

Des greffons pour Open/LibreOffice, FreeCAD et Thunderbird permettent de se passer d’un navigateur pour créer des documents et envoyer des fichiers. On peut imaginer une intégration avec d’autres logiciels ou un client en ligne de commande.

Comme indiqué dans la liste des nouveautés, OpenPLM peut interagir avec OpenERP. Il existe également des types de documents faisant référence à des ressources externes dont un type Subversion pour pointer vers un dépôt subversion (les autres VCS sont à venir) et un type GoogleDocument qui pointent vers un document hébergé par Google. Normalement, l’une des raisons de l’utilisation d’un PLM est d’être capable de maîtriser ses données, mais pour des entreprises qui utilisent les services de Google, ce type de document est un premier pas vers une migration totale sur une infrastructure maîtrisée.

La version 1.1 couvre désormais 90 % des fonctionnalités d’un PLM. La version 1.2 permettra d’étendre cette couverture (notamment ce qui concerne la gestion des modifications), sachant qu’il restera une partie irréductible liée au besoin d’adapter la solution aux spécificités de chaque entreprise.

Une version de démonstration est disponible en ligne à cette adresse.

Historique et feuille de route

Le développement d’OpenPLM a commencé en 2010. Les premières pré‐versions se sont concentrées sur le développement des fonctionnalités de base d’un PLM. L’année dernière, le conception a été entièrement revisitée. La version 1.0 d’OpenPLM est sortie au début du mois de mai de cette année. Parmi les nouveautés à venir, on peut noter :

  • la gestion des liens dits « alternate » dans les nomenclatures ;
  • une prise en charge plus complète de WebDAV, voire de l’extension sur la gestion de versions ;
  • le rajout des « engineering change requests » (ECR) et « engineering change orders » (ECO) ;
  • des badges à la StackOverflow ;
  • plus de préférences utilisateurs, notamment pour gérer les notifications par courriel ;
  • la possibilité de synchroniser les cycles de vie de plusieurs objets.

Si le développement est majoritairement assuré par LinObject, toute contribution est la bienvenue.

Petites notes sur le code

OpenPLM est principalement écrit en Python et utilise le framework Web Django. Le code est organisé en un cœur qui fournit les principales fonctionnalités et en applications Django qui l’étendent. Étant (principalement) une application Web, OpenPLM sert des pages HTML. L’un des principes derrière OpenPLM est de garder des URL intelligibles, qui affichent clairement vers quelle ressource elles pointent. La plupart du code JavaScript est écrit en utilisant la bibliothèque jQuery. L’affichage des modèles 3D se fait grâce à la bibliothèque Three.js.

Outre Python et Django, OpenPLM repose sur de nombreuses bibliothèques libres qui ont nettement facilité le développement. Du côté des applications Django, on peut citer le couple django-haystack/xapian sur lequel repose la recherche. Pour ceux qui développent des applications Django et qui souhaitent leurs apporter de la recherche, je ne peux que leur conseiller Haystack. Haystack permet de définir les index à la manière des modèles Django et l’exécution d’une requête est très proche de l’utilisation des QuerySet. Haystack gère plusieurs moteurs de recherche, dont SolR et Woosh. Personnellement, j’apprécie Xapian pour sa facilité de déploiement (pas de serveur, un seul répertoire qui contient toutes les données). OpenPLM délègue à Celery la gestion des tâches asynchrones (en exploitant RabbitMQ comme message broker).

Aller plus loin

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.