Mec. Ind. (2000) 1, 397–414 2000 Éditions scientifiques et médicales Elsevier SAS. Tous droits réservésS1296-2139(00)01044-7/FLA

Représentation et échange de données techniques

Guy Pierra *Laboratoire d’Informatique Scientifique et Industrielle, ENSMA, 86961 Futuroscope Chasseneuil, France

(Reçu le 27 décembre 1999 ; accepté le 7 juillet 2000)

Résumé —Avec la généralisation dans le processus de production de la notion de maquette numérique et des outils informatiques quilui sont associés, se pose le problème de l’archivage à long terme et de l’échange des données techniques qui constitue la nouvellereprésentation du savoir-faire de l’entreprise étendue. L’objet de cet article est de présenter un état de l’art sur la modélisationinformatique tant des données de produit que des catalogues de composants préexistants utilisés pour concevoir et fabriquerces produits. On introduit d’abord le langage EXPRESS, développé précisément pour permettre la représentation des données trèsstructurées propres au domaine technique. Ce langage, développé dans le cadre du projet STEP, est désormais normalisé au niveauISO. On présente ensuite les modèles développés par le projet STEP pour représenter de façon neutre les données de produit auxdifférentes phases du cycle de vie et dans les différents secteurs industriels. On présente ensuite les travaux effectués dans le cadredu projet PLIB pour permettre la modélisation et l’échange électronique de catalogues de composants industriels pour l’ingénierie etla production entre fournisseurs et utilisateurs. On discute l’état de maturité de ces deux projets, et des normes ISO qui en résultent.On présente enfin les tendances récentes vers l’intégration des approches documentaires (SGML, XML) et base de données (EXPRESS,UML) pour la représentation des bibliothèques de composants industriels, en particulier destinés à l’Internet, et les synergies existantentre STEP et PLIB pour une représentation complète des produits. 2000 Éditions scientifiques et médicales Elsevier SAS

données de produit / catalogue numérique / PLIB / STEP / ingénierie des données / SGDT

Abstract —Representation and exchange of industrial data. With the concept of digital mock up, and with all the software toolsthat generate and use technical data, the extended enterprise needs concepts, methods and tools for exchanging and for longterm archiving the digitally-represented knowledge about its products. The aim of this paper is to present an overview on industrialdata modeling and exchanging, both for representing enterprise products and for describing libraries of pre-existing componentsintended to be used in enterprise products. We first introduce the EXPRESS language, developed within the context of the STEP project(officially ISO 10303), for modeling highly structured industrial data. Then, we outline the information models developed in STEP forthe computer-interpretable representation and exchange of product data, throughout the life cycle of products and for any kind ofindustry. In a third section we present the concepts and information models developed within the PLIB project (officially ISO 13584)for representing and exchanging digital libraries of industrial components. We discuss the achievements of both projects, developedin the same ISO committee. Then we present recent developments, performed first to integrate the data-oriented view (EXPRESS) andthe document-oriented view (HTML/XML) on component libraries and/or electronic catalogues for the web, and, second, to integratethe STEP and PLIB models and capabilities. 2000 Éditions scientifiques et médicales Elsevier SAS

product data / electronic catalogue / PLIB / STEP / data engineering / digital library

1. INTRODUCTION

Avec la généralisation, dans le processus de produc-tion, c’est-à-dire le processus de conception, fabrication,maintenance et démantèlement des produits industriels,de la représentation informatique des données, et des ou-tils informatiques qui leur sont associés, se pose le pro-blème de l’intégration, de l’échange, et de l’archivage àlong terme des données techniques qui constituent le pa-trimoine informationnel de la nouvelle entreprise.

* Correspondance et tirés à part :pierra@ensma.fr

Concernant les données de produit, deux grandescatégories d’information peuvent être distinguées dansces données techniques :

• les informations qui décrivent les produits de l’entre-prise aux différentes phases de leur cycle de vie et selonles points de vue propres aux différents métiers, et

• les informations qui se réfèrent aux composants pré-existants, qui sont utilisés pour concevoir, fabriquer oumaintenir les produits de l’entreprise.

Si ces deux types de données ont de nombreux pointscommuns (par exemple le fait qu’elles décrivent, dansles deux cas, des objets techniques), plusieurs aspects lesrendent différents.

397

G. Pierra

• L’ origine de l’information. L’information sur les pro-duits de l’entreprise est créée dans l’entreprise elle-même. La description et la connaissance sur les com-posants proviennent de leurs fournisseurs. Permettreun échange purement numérique d’information entrefournisseurs et utilisateurs de composants augmente-rait la qualité et réduirait considérablement les coûtsde tous les partenaires impliqués dans l’entreprise éten-due.

• La structurede l’information. Chaque produit réalisépar l’entreprise est individuellement, explicitement et ex-haustivement représenté pour permettre sa fabrication.Au contraire, pour faciliter leur recherche et leur sélec-tion, et pour éviter l’explosion des données, les com-posants sont regroupés en familles d’objets similairesdans lesquelles chaque instance est seulement implicite-ment décrite à l’aide de tables, d’expressions ou de for-mules.

• L’ accèsà l’information. Lors d’une recherche d’in-formation sur un produit de l’entreprise, l’utilisateurconnaît normalement de quel produit il s’agit. Lorsqu’ilcherche un composant pour l’utiliser dans un produit,ce que l’utilisateur connaît est le problème d’ingénie-rie qu’il doit résoudre. Le système de gestion des don-nées composants doit alors l’aider à trouver le compo-sant adapté pour résoudre son problème. Et, pour cefaire, il doit contenir non seulement les données décri-vant les composants, mais également le savoir-faire, dontune large partie provient du fournisseur, sur le compor-tement des composants et sur les critères de sélection( figure 1).

Avec la montée en puissance progressive de la ma-quette numérique, chaque entreprise se trouve confrontée

à la nécessaire définition d’une infrastructure informa-tique lui permettant de modéliser, de gérer et d’exploiterces deux types de données techniques. Ceci nécessite, àson tour, de choisir des langages, des modèles, des outilset des systèmes adaptés à ces nouveaux besoins.

L’objet de cet article est d’éclairer ce choix en présen-tant les progrès réalisés au cours des 10 dernières annéesdans les deux domaines évoqués. Nous nous concentre-rons principalement sur les résultats obtenus dans deuxgrands projets de R&D et de normalisation internationaleconcernant la modélisation et la gestion des données deproduit. Nous présenterons à cette occasion un panoramades langages, outils, modèles et méthodes qui résultentde ces travaux et sont aujourd’hui disponibles pour per-mettre à chaque entreprise de définir sa propre infrastruc-ture.

Le contenu de cet article est le suivant. Dans la pre-mière partie, on présente les travaux effectués et les ré-sultats obtenus par le projet international STEP (Stan-dard for the Exchange of Product Data) sur la modéli-sation des données de produits. Dans la deuxième par-tie, on présente les travaux effectués sur la modélisationet l’échange de bibliothèques et catalogues de compo-sants. Ce deuxième volet de travaux, initiés en Europeà la fin des années 1980 dans un projet connu sous lenom de CAD-LIB, a ensuite été transféré au niveau in-ternational et constitue le projet PLIB (Parts Library).Enfin une troisième partie présente brièvement les sy-nergies existant entre ces deux problématiques et montrel’intérêt d’une gestion intégrée des produits et compo-sants.

Figure 1. Les deux niveaux d’échange des données techniques selon [1].

398

Représentation et échange de données techniques

2. MODÉLISATION DE DONNÉESDE PRODUIT : LA TECHNOLOGIE STEP

Dans le processus de conception, l’investissement enmatériel et logiciel devient souvent peu de choses parrapport à la valeur que représente les données généréespar l’utilisation des systèmes. Le besoin industriel est dedisposer des données au bon endroit et au bon moment,alors que tout concourt à l’hétérogénéité des systèmesd’informations et à l’incompatibilité des modèles de don-nées. La diversité des systèmes, qui recouvre la diversitédes besoins élémentaires, et leur manque de pérennité,en particulier dans le contexte de concentration indus-trielle que nous connaissons, rend à la fois la capitali-sation des données difficile (leur durée de vie ne dépasseguère celle du système ayant permis de les générer) etleur échange entre systèmes hétérogènes illusoire (beau-coup du contenu informationnel étant perdu).

C’est dans ce contexte que le projet STEP a été lancéau niveau de l’ISO (International Organization for Stan-dardization) au milieu des années 1980. L’objectif étaitde définir une représentation non ambiguë des donnéesdu produit, interprétable par tout système informatique,et couvrant tout le cycle de vie des produits. Atteindrecet objectif présentait deux difficultés essentielles :

• la définition d’un format neutre, interprétable partout système informatique indépendamment du systèmeparticulier utilisé pour générer les données,

• la couverture d’un très vaste domaine de connaissance,correspondant à l’ensemble des catégories de produits(pièces élémentaires, assemblages, mécanismes. . . ), se-lon le point de vue de tous les métiers (électronique, mé-canique, ingénierie. . . ), et à toutes les phases du cyclede vie (conception, analyse, fabrication, maintenance, dé-mantèlement). Ceci imposait de mobiliser, et de faire col-laborer, des participants représentant un spectre extrême-ment large de compétences.

La première difficulté a imposé de développer touteune nouvelle méthodologie sur la modélisation des don-nées pour assurer leur indépendance de tout système.Cette approche comporte :

• la définition d’un langage formel de spécification desdonnées, le langage EXPRESS,

• la définition de formats neutres d’échange et de sto-ckage des données décrites dans le langage EXPRESS.

Ces deux éléments font que les données sont destinées àne plus dépendre dessystèmesqui les génèrent, mais desmodèlesqui les décrivent.

La deuxième difficulté a amené à élaborer des pro-cédures permettant de faire collaborer des spécialistes

de chacun des domaines techniques — caractérisés parles produits concernés, la phase du cycle de vie priseen compte, et le point de vue disciplinaire adopté —avec des spécialistes de la modélisation des données pourconstruire les modèles propres à chaque domaine. Ellea ensuite amené au développement d’une méthodologiespécifique de modélisation visant à permettre à ces nom-breux groupes d’experts de mettre en commun les mo-dèles relevant des aspects communs.

Après plus de 15 ans de travaux, au cours desquelsplusieurs centaines d’experts appartenant à 19 pays (Aus-tralie, Belgique, Brésil, Canada, Chine, France, Alle-magne, Hongrie, Italie, Japon, Corée du Sud, Pays-Bas,Norvège, Roumanie, Russie, Suède, Suisse, Royaume-Uni, États-Unis) se sont réunis plus de trois fois par an,une véritable technologie a été développée. Cette techno-logie est décrite dans les différents fascicules de la normeSTEP, officiellement la norme ISO 10303. Cette normecomporte actuellement, publiés ou encore en travaux, en-viron 110 fascicules, soit quelques dizaines de milliers depages de spécifications.

2.1. Les différents aspectsde la technologie STEP

La figure 2 présente les différentes parties de latechnologie développée, qui correspondent égalementà la classification des différents fascicules publiés ouencore en travaux.

Nous détaillons ci-après le contenu de chacune de cesparties (on pourra visiter le site http://www.nist.gov/sc4/qui est le site de référence pour STEP).

2.2. Méthodes de description del’information : le langage EXPRESS

Le travail sur le développement des modèles STEPa commencé en 1986. Aucune notation de modélisationdes données ne s’avérant à la fois suffisamment précise etsuffisamment expressive [2] un nouveau langage dû êtredéveloppé.

2.2.1. Origine

EXPRESS [3] est le langage de modélisation des don-nées conçu dans le cadre du projet STEP. Son objectifprincipal est la description de modèles d’informationsdans le domaine technique, en vue de l’échange de don-nées représentant de façon fiable et non ambiguë ces in-

399

G. Pierra

Figure 2. Structure de la norme STEP.

Figure 3. Un exemple de hiérarchie de classes EXPRESS.

formations [2, 4, 5]. Dans le langage EXPRESS, l’ac-cent principal est mis sur la précision du modèle et toutparticulièrement sur les contraintes que doivent respecterles données pour être acceptées comme conforme au mo-dèle. Ceci assure la fiabilité de l’information représentée.EXPRESS n’est pas seulement une notation permettantla modélisationdes données, c’est-à-dire une représen-tation simplifiée, éventuellement partiellement ambiguë,des informations propres à un domaine à fins d’échangeentre concepteurs humains pour décider des éléments quisont pertinents et des détails qu’il convient de négliger.C’est également un formalisme despécification, c’est-à-dire qu’il permet une description complètement non am-biguë et traitable par machine.

En fait (ainsi que le montre l’exemple que nous trai-terons ci-dessous), le langage EXPRESS peut être uti-lisé pour la spécification des données dans de très nom-breux domaines autres que la modélisation de produits.Par contre, à la différence des formalismes de modélisa-tion objets, tel OMT ou UML [6, 7] il n’est pas destinéà modéliser des systèmes informatiques faisant interve-nir une composante dynamique [8]. En EXPRESS, lesobjets ne possèdent pas de méthodes, et la connaissanceprocédurale représentable s’exprime exclusivement soitsous forme de contraintes d’intégrité, soit sous forme de

fonctions de dérivation exprimant comment un attribut secalcule à partir d’autres attributs.

2.2.2. Le langage EXPRESS

Un modèle EXPRESS définit un ensemble d’entitésqui représentent les objets à modéliser. EXPRESS suitune approche orientée type [9] : les types d’entités sontdéfinis dans un schéma statique, et il n’y a pas de notionde métaclasse. On peut cependant, en travaillant au ni-veau méta [10, 11], modéliser le schéma lui-même (c’estla méthode développée dans le projet PLIB pour repré-senter le comportement des composants d’un catalogue).

Chaque entité est définie par un ensemble de carac-téristiques appelées attributs. Chaque attribut possède undomaine de valeurs licites (type de données, pouvant eux-mêmes être des entités). EXPRESS permet de préciserces domaines grâce à des contraintes d’intégrité. Enfin,conformément à l’approche objet [8, 12] les entités sontorganisées de façon hiérarchique par des relations de gé-néralisation/spécialisation associées à un mécanisme defactorisation/héritage.

L’exemple de la figure ci-dessus (figure 3) présenteune arborescence d’entités : deux sous-types d’entités,étudiant et enseignant, sont des spécialisations d’un

400

Représentation et échange de données techniques

Figure 4. Un modèle de données contraint.

super-type d’entités non instanciable (mot clé ABS-TRACT), personne.

Le langage EXPRESS permet de distinguer les ins-tances d’entités et les simples valeurs. Ces dernières peu-vent appartenir aux types prédéfinis usuels (entier, réel,chaîne. . . ). Il est également possible de construire desnouveaux types dit « types utilisateurs » (mot clé TYPE).Ceci permet de donner un nom différent à un type exis-tant, ou de construire, soit des types énumérés, soit destypes sélections (qui définissent une union de types).

La principale originalité d’EXPRESS est au niveaude la représentation des contraintes. EXPRESS disposeseulement de deux abstractions de haut niveau qui ex-priment lesinvariants des données, respectivement sousforme fonctionnelle et assertionnelle. Ladérivationper-met de calculer de façon fonctionnelle un attribut à par-tir des autres éléments du modèle. Lacontrainte d’in-tégrité, locale (clause WHERE) ou globale (GLOBAL),s’exprime sous forme d’un prédicat qui doit être vrai pourtoute donnée licite. Un langage de programmation, detype impératif et similaire à PASCAL, permet d’exprimerces invariants à l’aide de toute fonction programmable.

Du point de vue syntaxique, l’ensemble des construc-tions qui visent à représenter un univers est regroupé dansun SCHEMA. Du point de vue sémantique, ce schémadéfinit avec beaucoup de précision un ensemble de va-leurs licites qui en constitue le domaine possible d’inter-prétation (i.e., l’ensemble de valeurs autorisées).

Après adjonction de types de données, d’attributs etdes contraintes nécessaires pour préciser les propriétésque doivent respecter toutes les populations de donnéesconformes au modèle, le schéma de lafigure 3, devien-drait par exemple celui de lafigure 4.

Tout attribut, si cela est permis par le modèle (motclé : OPTIONAL) peut être autorisé à avoir la va-leur « indeterminate ». La clause WHERE introduit unecontrainte d’intégrité locale destinée a être vérifiée pourchaque instance d’un type ou d’une entité (les numé-ros de sécurité sociale ne commençant pas par « 1 » ou« 2 » sont interdits). La clause UNIQUE, contrainte d’in-tégrité globale au modèle mais exprimable localement,indique l’unicité des valeurs d’un ou plusieurs attributspour toutes les instances d’entités d’un type d’entités (ici,il ne peut pas exister plusieurs personnes ayant le mêmenuméro de sécurité sociale). La clause INVERSE permetd’associer à toute relation, la relation inverse. Du point

401

G. Pierra

de vue sémantique, il s’agit d’une méthode de dérivationimplicite qui évalue, pour chaque instance, l’ensembledes instances qui y font référence dans un rôle donné. Celien inverse possède deux utilisations. D’une part, il per-met d’exprimer la cardinalité d’une relation inverse (toutcours est enseigné par un enseignant et un seul ; il estsuivi par un maximum de 30 élèves. Dans un modèle géo-métrique de type B-rep, toute arête appartient à exacte-ment deux faces. D’autre part, il permet d’accéder à par-tir d’une instance, par la notation pointée, à toutes les ins-tances qui y font référence (par exemple pour savoir quelsétudiants suivent un cours donné, ou, dans un modèlegéométrique de type B-rep, à quelle face appartient unearête particulière). Enfin, des fonctions prédéfinies per-mettent d’accéder à l’ensemble des instances d’un typed’entité ou d’un agrégat (ensembles, listes. . . ), de les par-courir de façon indicée (LOBOUND. . .HIBOUND) ouglobale (clause QUERY), de calculer la taille d’un en-semble (clause SIZEOF), d’accéder au type d’une entité,

et, pratiquement, d’exprimer toute contrainte susceptiblede s’écrire sous forme d’un programme de type PASCAL(voir par exemple la fonctioncalculequi évalue l’initialed’un nom en en prenant le premier caractère).

2.2.3. La notation graphique EXPRESS-G

La représentation textuelle des schémas EXPRESS estessentielle pour le traitement automatique des modèles.C’est elle qui pourra être exploitée par machine pour vé-rifier sa correction, ou vérifier si des instances lui sontconformes (cf. 2.3). Elle est, par contre, assez diffici-lement lisible. Un formalisme graphique, EXPRESS-G[2, 3], a donc été défini pour donner une vue synthétiquedes modèles de données et faciliter leur conception dansles phases initiales d’analyse des problèmes à modéliser.Ce symbolisme de représentation n’est que partiel et nepermet pas d’exprimer les contraintes d’intégrité. La na-ture des attributs (optionnel, dérivé ou inverse), ainsi queleur type, peuvent, par contre, être représentés. La repré-

Figure 5. Représentation en EXPRESS-G d’un modèle de données [13].

402

Représentation et échange de données techniques

sentation en EXPRESS-G du modèle de données précé-dent est donnée ci-dessous (figure 5).

2.2.4. Intérêt d’EXPRESS

A la différence des nombreuses notations existantespour modéliser des données telles que NIAM [14]OMT [6] ou UML [7] qui ne sont que graphiques et doncseulement échangeables entre êtres humains, le fait, pourEXPRESS, de posséder à la fois une version graphiqueet une version textuelle rend ce langage traitable par ma-chine. Un modèle EXPRESS peut être échangé entre ma-chines différentes. Il peut également être traité par ma-chine pour en vérifier la cohérence, ou pour passer au-tomatiquement de la version graphique à la version tex-tuelle et inversement. Il peut enfin être exploité pour gé-nérer automatiquement différents programmes ou repré-sentations informatives tels que le schéma d’une base dedonnées susceptible d’en stocker les instances. Il s’agitdonc bien à la fois d’un modèle interprétable par l’uti-lisateur humain, et d’une spécification interprétable parmachine.

Comparé aux autres notations existantes, EXPRESSpossède les points forts suivants :

• il s’agit d’un standard international stable, bien docu-menté et de plus en plus utilisé ;

• il possède une syntaxe et une sémantique précisesautorisant, avec des outils appropriés, une interprétationet un traitement automatique des modèles ;

• il possède une représentation graphique qui fournit unevue synthétique du modèle pour mieux le comprendre oule concevoir ;

• il possède un système de contraintes complet (con-traintes de cardinalité, contraintes ensemblistes, con-traintes assertionnelles, contraintes fonctionnelles, con-traintes sur les classes. . .), ainsi qu’un langage procéduralpermettant d’enrichir celles-ci ;

• enfin il permet la ré-utilisation, grâce à sa modularité,des schémas de ressources existants et autorise donc undéveloppement incrémental de modèles de plus en plusvastes et complexes.

De plus, ainsi que nous allons le voir à la section sui-vante, EXPRESS est associé à des méthodes d’échangeet d’accès aux données, et à des outils de génération au-tomatique permettant de générer des programmes de trai-tement conformes à ces méthodes d’échange et d’accès.EXPRESS constitue ainsi une nouvelle approche puis-sante et rigoureuse pour la modélisation, l’échange etl’accès aux données.

2.3. Méthodes de mise en œuvre

Ce sont les méthodes, prédéfinies et normalisées,de représentation d’instances conformes à un modèleEXPRESS. Ces méthodes de mise en œuvre vont per-mettre à la fois l’échange de données entre systèmes hé-térogènes, et l’archivage de données dans un format in-dépendant du système source.

2.3.1. Représentation des instancessous forme de fichier :le fichier neutre STEP

Ce mode de représentation des instances d’un modèledéfini en EXPRESS est spécifié dans le fascicule 21 deSTEP [15]. Cette spécification définit la manière de codersous forme d’un fichier de caractères, une populationd’instances d’entités conformes à un modèle défini enEXPRESS.

Ce fascicule spécifie :

• les alphabets utilisables et le codage des différentesstructures lexicales,

• la structure des fichiers,

• le contenu des entêtes de fichiers,

• les règles de traduction de définitions en EXPRESS,

• le format physique des fichiers.

Un exemple commenté d’instances du modèle dedonnées que nous avons décrit (figure 4) est présenté ci-après (figure 6).

On peut noter que chacune des instances est identifiéepar unoid ( object identifier: # i), est caractérisée parle nom de la classe instanciée, et contient la suite devaleurs de ses attributs entre parenthèses. Les collectionsde valeur sont également présentées entre parenthèses.La valeur « indeterminate » (des attributs optionnels) estdésignée par « $ », et les valeurs des types énuméréspar une notation entourant l’identificateur par un point àchacune de ses extrémités. On peut aussi remarquer queles attributs dérivés et inverses ne sont pas représentés.En effet, lors d’un échange de ce fichier d’instances, lesystème receveur basé sur le même modèle de donnéespourra recalculer ces attributs. Un tel fichier permet àdeux systèmes informatiques d’échanger sans aucuneambiguïté des populations d’instances conformes à unmodèle EXPRESS.

403

G. Pierra

Figure 6. Un exemple de fichier physique.

2.3.2. Interface normalisée d’accès auxinstances d’un modèle EXPRESS :l’interface SDAI

En plus de la méthode d’échange de données définie àtravers la notion de fichier neutre, une méthode de partagedes instances d’un modèle EXPRESS entre systèmeshétérogènes a également été définie. Celle-ci est baséesur la définition d’une bibliothèque de fonctions d’accèsnormalisées (une interface d’accès), et est connue sous lenom de SDAI (Standard Data Access Interface) [16].

Cette interface permet en particulier :

• l’accès et la manipulation par programme d’instancesd’entités définies en EXPRESS ;

• l’accès simultané à plusieurs bases de données parplusieurs applications ;

• l’accès à la définition EXPRESS des éléments dedonnées qui peuvent être manipulés par une application ;

• la vérification des contraintes définies dans le modèlede données EXPRESS.

La spécification décrite dans le fascicule 22 définis-sant l’interface d’accès normalisée indépendamment detout langage de programmation, des syntaxes d’appeldans des langages de programmation tels C, C++ ouJAVA ont également été définies dans les fascicules 23,24 et 27. Les applications souhaitant accéder à des mo-dèles de données EXPRESS, et manipuler des instancesrelatives à ceux-ci, font appel aux services fournis par ces

interfaces. Elles peuvent alors s’exécuter sur n’importequel système supportant la même interface normalisée.

2.3.3. Génération d’applications à partird’un modèle EXPRESS

De nombreux outils existants, gratuits ou commercia-lisés sur le marché (voir : http://www.nist.gov/sc4/tools/express/), permettent de générer automatiquement à par-tir d’un modèle EXPRESS :

• une base de données susceptible de stocker les ins-tances de ce modèle,

• une interface normalisée (SDAI) d’accès à cette basede données,

• un programme de lecture d’un fichier neutre conformeà ce modèle et capable de stocker son contenu dans labase de données par appel de la SDAI,

• un programme d’écriture d’un fichier neutre conformeà ce modèle et capable de lire son contenu dans la base dedonnées par appel de la SDAI, puis de générer le fichier.

Il s’agit donc d’une véritable application générée defaçon complètement automatique. Ceci montre l’intérêtconsidérable du langage EXPRESS, en particulier lors-qu’on le compare aux notations graphiques telles queOMT ou UML.

404

Représentation et échange de données techniques

Figure 7. Structure générale des modèles STEP.

2.4. Les modèles de données

Le projet STEP n’a pas seulement défini des outils etméthodes, il a également, dans un nombre croissant dedomaines, défini des modèles.

2.4.1. Architecture générale

L’approche suivie a consisté, d’abord, à définir lastructure générale d’une modélisation de produit devantêtre respectée dans tous les domaines d’application parti-culiers. Un produit («product») peut posséder plusieursvariantes (plusieurs «product_definition_formation» ré-férencent le même «product»), chacune décrite par plu-sieurs vues, chacune associée à plusieurs propriétés,ayant plusieurs représentations éventuelles (figure 7).

Notons que, dans la plupart des domaines, ce sont sur-tout des propriétés très génériques qui ont été définies etutilisées par STEP : la forme (géométrie), l’identification,le matériau constituant, etc. Les propriétés techniquesspécifiques de chaque objet (le diamètre fileté d’une vis,la tension de rupture d’une diode. . . ) ne sont en généralpas représentées. C’est précisément un des domaines quevise à couvrir PLIB.

2.4.2. Les ressources intégrées

La deuxième étape a consisté à identifier les sujetsd’intérêts communs à plusieurs domaines, à abstraireles caractéristiques communes, et à définir des schémas« ressources » susceptibles d’être ensuite spécialisés danschaque domaine d’application. Les fascicules de la série40 de STEP décrivent les modèles à vocation très géné-rale. Les fascicules de la série 100 décrivent les modèlesmoins universels car correspondant à des grands secteursapplicatifs. Les modèles figurant dans ces différents fas-cicules sont cohérents entre eux et non redondants. Onles qualifie de « ressources intégrées » (figure 8).

Figure 8. Les ressources intégrées de STEP.

Il est intéressant de noter le caractère très génériquedes ressources ainsi construites. Par exemple, chaque en-treprise est confrontée, lorsqu’elle déploie un système degestion de données techniques (SGDT) [17], à définir sapropre structure de modélisation de produit [18]. Chaquebureau de calcul doit définir sa propre organisation desdonnées de calcul par éléments finis. Les modèles géné-riques de STEP, élaborés par des spécialistes de chacunde ces domaines, contiennent une proposition de solutionpour chacun de ces problèmes [18].

2.4.3. Les protocoles d’application STEP

Mais les approches génériques ne suffisent pas. Lacaractéristique de chaque métier est d’avoir élaboré sonpropre savoir-faire par spécialisation du savoir-faire com-mun aux différents métiers techniques. Un ingénieur decalcul n’utilise pas le même langage qu’un responsablede production, de même qu’un électricien ne s’intéressepas aux mêmes objets qu’un plombier. C’est à ce niveaude spécialisation — un type d’activité (l’électronique),une phase du cycle de vie (la conception) et un métier(la schématique)— que les données réelles doivent êtreconservées, et si possible articulées avec les niveaux voi-sins. C’est, dans STEP, le niveau des protocoles d’appli-cations (AP ouApplication Protocol).

Les spécialistes du domaine ont la charge de définirles activités propres à leurs métiers (c’est l’AAM ouAp-plication Activity Model), les grandes catégories d’objetsou de concepts mis en jeu (ce sont les unités fonction-nelles, ouUnit of Functionality, UoF) et finalement, maisde façon plus ou moins précise et formelle, les donnéesnécessaires et les contraintes qu’elles doivent respecter(c’est le modèle de référence ouApplication ReferenceModel, ARM). Cet ensemble de modèles, décrit par lesspécialistes du domaine, correspond à une spécificationde besoins.

405

G. Pierra

Figure 9. Principe d’un protocole d’application [18].

Une coordination est alors organisée avec des spécia-listes de la modélisation de données et de l’architectureSTEP, de façon à exprimer les besoins identifiés dansle modèle de référence (ARM) à l’aide des seules enti-tés figurant dans les ressources intégrées de STEP, éven-tuellement combinées par héritage. Ce processus est ap-pelé une « interprétation » des besoins à l’aide des res-sources communes. Le résultat, ou AIM (Application In-terpreted Model), est supposé traduire l’ensemble des be-soins identifiés par les spécialistes du domaine en termesdes seules ressources intégrées de STEP. Lafigure 9ci-dessous montre le principe de réalisation d’un protocoled’application.

Initialement, l’ARM pouvait être exprimé de façontextuelle et à l’aide de notations graphiques telle queNIAM [14] ou IDEF1x [4]. Une phase d’interprétationétait alors nécessaire pour réécrire ce modèle en EX-PRESS. Au fur et à mesure que la technologie EXPRESSdiffuse, les modèles de référence sont de plus en plussouvent écrits directement en EXPRESS par les expertsdu domaine. Ceci rend discutable la nécessité du proces-sus d’interprétation, d’autant que celui-ci, assez informel,n’assure pas qu’un même besoin d’information sera inter-prété de la même façon (i.e., représenté par les mêmes en-tités) dans deux protocoles d’application différents. Desévolutions sont donc en cours pour essayer de modula-riser les protocoles d’application de façon à promouvoirla réutilisabilité à un niveau plus élevé que les simplesentités EXPRESS.

Figure 10. Les protocoles d’application en cours.

La figure 10ci-après liste l’ensemble des protocolesd’applications, développés ou en cours, et montre la trèsgrande variété des domaines applicatifs couverts.

Les approches suivies dans les différents protocolesd’application sont, en général, assez largement diffé-rentes. L’intégration de domaine à domaine laisse en-core ouvert un grand nombre de questions. Néanmoins,dans chaque domaine applicatif, le modèle de référence(ARM) d’un protocole d’application représente une vé-ritable capitalisation du savoir-faire d’un grand nombred’experts du domaine sur les informations qui sont per-

406

Représentation et échange de données techniques

tinentes dans ce domaine, et sur la structuration qu’ilconvient de leur donner.

Dans le domaine mécanique, les protocoles d’appli-cations 203 et 214 sont assez représentatifs de cet ap-port. Le 203 [18] définit un modèle de données pour lamise en œuvre de Systèmes de Gestion de Données Tech-niques couplé à des systèmes de CAO dans les industriesmécaniques. Plus ambitieux encore, le 214, élaboré parl’ensemble des fabricants automobiles du monde entier,propose une définition des données nécessaires pour re-présenter des produits aussi complexes que les véhiculesautomobiles tout au long de leur cycle de vie.

2.5. Les tests de conformité

Instruite par les difficultés rencontrées dans les inter-faces de la génération précédente (telle que IGES) où ilétait très difficile, en cas d’anomalie dans un transfert dedonnées, d’identifier les responsabilités entre l’émetteur,le receveur, voire les erreurs ou imprécisions de la spé-cification elle-même, la norme STEP définit pour chaqueAP :

• Comment doivent être testées les interfaces ?

• Sur quels critères établir leur conformité?

A l’ISO, des projets de normes définissant les testsde référence sont en cours de développement pour lesAP 202, 203, 204. D’autres tests de référence devraientêtre progressivement développés pour tous les protocolesd’application.

En France, une Norme expérimentale correspondant àl’AP 203 (AFNOR Z 68 333), un Laboratoire de Testsau GOSET, et un Comité de Certification NF à l’AFNORsont déjà disponibles. Certaines interfaces sont d’ores etdéjà certifiées conforme pour ce protocole d’applicationdont le déploiement est actuellement le plus avancé.

2.6. De la modélisation de produit àla caractérisation des composants

STEP a donc développé toute une nouvelle technolo-gie pour permettre la modélisation informatique des don-nées des produits, tels que ceux-ci existent dans l’entre-prise. C’est la notion de maquette numérique pour la-quelle STEP définit une représentation neutre, c’est-à-dire indépendante des outils logiciels qui la génèrent oul’exploitent.

Dans une telle représentation, chaque produit etchaque composant seront décrits par ce qu’ils sont (une

forme, une matière, une identification) mais non par lesraisons pour lesquelles ils sont là. Pourquoi tel compo-sant a-t-il été choisi plutôt que tel autre ? Quels ont étéles critères ou les propriétés qui ont amené à le choisir ?Comment conviendrait-il de le remplacer si sa référencen’était plus fabriquée? Ceci constitue des exemples dequestions auxquelles la représentation STEP ne fournitpas de réponse. Il faudrait pour cela identifier les pro-priétés qui ont été déterminantes lors du choix de chaquecomposant. Il faudrait connaître les exigences expriméespar le concepteur sur les valeurs de ces propriétés. Ilfaudrait enfin modéliser et enregistrer ces exigences ausein de la maquette numérique. C’est le complément quePLIB va apporter à STEP lorsqu’un produit comporte, enparticulier, des composants préexistants.

3. MODÉLISATION ET ÉCHANGEDE DONNÉES DE COMPOSANTS :LE PROJET PLIB

Démarré en 1987 au niveau Européen, puis en 1990 auniveau ISO, la norme ISO 13584 (Parts Library, connueen Europe sous le nom de CAD/LIB [19], et désormaisassociée à l’abréviation PLIB) est la norme destinée àpermettre la modélisation, l’échange et le référencementà partir de STEP, de bibliothèques informatisées de com-posants préexistants. PLIB permet aussi bien la repré-sentation de composants abstraits, tels qu’ils sont parexemple utilisés lors d’une conception fonctionnelle (unsystème de pompage, une alimentation, une liaison ro-tule) que celle de composants fournisseurs ou norma-lisés (une vis CHC M 12-35 NF E 27-161, un palier-applique à billes INA KGHWT 25 PP). Cette normepermet également d’associer à un objet bibliothèque, unnombre quelconque de représentations, propres à cha-cune des disciplines qui manipule l’objet (une vue solidepour la conception mécanique, une vue symbolique pourla conception fonctionnelle, un modèle de comportementpour la simulation analogique, etc.). Elle permet enfind’intégrer dans un environnement homogène et cohérentdes bibliothèques fournies par différentes sources [20],http://www.plib.ensma.fr.

L’idée centrale de la norme PLIB est qu’un composantn’est pas seulement, comme le considèrent les systèmesCAO, une ou plusieursreprésentations. Ce n’est pasnon plus, comme le considèrent les bases articles ou,bien souvent, les fichiers STEP, une simpleidentification.C’est, en fait, un ensemble de propriétés spécifique dechaque famille d’objet, et qui représente aussi bien lanature que la fonction des composants de la famille.

407

G. Pierra

C’est autour de la définition, de la représentation, et del’exploitation de la notion de propriété qu’est construitela plus grande partie de la norme PLIB.

La structure de la norme PLIB est voisine de cellede STEP : sept parties (ISO 13584-1, 10, 20, 24, 26, 31et 42) [21–23] constituent le noyau de la spécification etsont communes à toutes les disciplines. La série 100 (ISO13584-1xx), appelée «view exchange protocols», est pré-vue pour accueillir les spécifications des représentationspropres à chaque secteur d’activité au fur et à mesure deleur développement.

PLIB couvre deux types de problèmes :

• Identifier et représenter les propriétés et les famillesd’objets qui ont « la même signification » : c’est la notionde dictionnaires de données,

• Saisir, modéliser et échanger laconnaissancesur descomposants : c’est la notion de bibliothèques de com-posants, dont la représentation sous forme de docu-ment aboutit à des catalogues informatisés « actifs » ou« intelligents ».

3.1. Définition de dictionnairesde données pour le domainedes objets techniques

Échanger ou référencer des bibliothèques nécessited’abord de pouvoir identifier, et décrire sous forme infor-matique, les catégories d’objets (vis, capacité ou pompe)et les types de propriétés (diamètre fileté, tension derupture ou température maximale supportée) concernées.C’est la notion de dictionnaire de données.

La spécification correspondante, dont le domained’application déborde largement le problème des biblio-thèques de composants puisqu’elle permet d’informati-ser tant les normes de terminologie que les attributs tech-niques propres aux produits d’une entreprise, a été déve-loppée conjointement avec la CEI (Commission Electro-technique Internationale). Ceci assure un traitement ho-mogène de tous les types de composants. Cette spécifica-tion constitue la partie 42 de l’ISO 13584, déjà publiéeen tant que norme internationale (IS :International Stan-dard). Elle est également publiée par la CEI sous la réfé-rence IEC 61630-2.

3.1.1. Principes fondamentauxde la modélisation

Cette spécification est basée sur deux principes debases :

Figure 11. Définition simultanée des classes et propriétés.

(1) les différentes catégories d’objets doivent, confor-mément à l’approche objet [8, 12], être organisées selonune hiérarchie de « familles » ou de « classes », avec fac-torisation/héritage des propriétés,

(2) hiérarchie de classes et propriétés doivent êtredéfinies simultanément :

• les propriétés applicables précisent la significationd’une classe de composants ;

• le domaine d’application précise la signification d’unepropriété.

Dans l’exemple ci-dessus (figure 11), la notion de« masse » est associée à la classe « parts » (composantmécanique). Cette propriété précise le concept de « com-posant mécanique » : ce sont des composants pour les-quels la masse est définie (à la différence, par exemple,des composants logiciels). Cette propriété est égale-ment définie implicitement pour toutes les sous-classesde composants mécaniques (c’est ce que l’on appelle« l’héritage »). Au contraire le « diamètre_intérieur_de_roulement » est seulement défini pour l’ensemble descomposants d’un catalogue SKF de roulements, mais paspour les autres sous-arbres qui pourraient contenir desvis, vérins, transistors, etc.

3.1.2. Typologie des propriétés

Lorsque l’on étudie les propriétés d’un composant, lespremières propriétés, évidentes, sont celles qui caracté-risent sa forme ou sa fonction, par exemple le diamètreintérieur, ou la vitesse de rotation maximale d’un roule-ment. Mais pour choisir un roulement, ce qui intéressesurtout l’utilisateur est sa durée de vie. Et celle-ci estelle-même fonction des conditions d’utilisation : vitesse

408

Représentation et échange de données techniques

Figure 12. Typologie des propriétés.

Figure 13. Exemple de hiérarchie classes/propriété (proposéepour le protocole d’ingénierie de STEP).

de rotation effective, force radiale subie. . . Ainsi PLIBdéfinit trois catégories de propriétés illustrées dans lafi-gure 12ci-dessus.

Les paramètres de contexte, et les valeurs requisespour les propriétés caracteristiques, permettent à l’utilisa-teur de définir le problème qu’il a à résoudre. La descrip-tion du comportement, c’est-à-dire la représentation desméthodes de calcul des propriétés dépendant du contexteen fonction des caractéristiques du composant et des pa-ramètres de contexte permettent au fournisseur de modé-liser et d’échanger la connaissance qu’il possède sur lecomportement de ces composants.

3.1.3. Méthode de description

À partir de cette typologie, PLIB fournit un modèle dedonnées (et un format de description documentaire dansla norme sœur [24]), pour la hiérarchie classe-propriété( figure 13). On remarquera que chaque classe ou chaquepropriété est associée à un code qui permettra d’identifierde façon universelle tout élément d’un dictionnaire PLIB(cf. 3.1.4).

Figure 14. Exemple de définition dictionnaire d’une pro-priété [24].

Figure 15. Identification du facteur de perméabilité d’unmatériau magnétique à une fréquence donnée (le code0112/2///61630-4 caractérise en effet la norme CEI 61360-4).

PLIB fournit également un modèle de donnée pour dé-crire avec beaucoup de précision chacune des propriétéset chacune des classes.

L’exemple ci-dessus (figure 14), tiré de la normeCEI 61360-4, montre les différentes informations quidoivent être associées à la description d’une propriétédans un dictionnaire conforme à PLIB. Outre le codede la propriété (AAF307-005), et de la classe pourlaquelle elle est définie (CCD124-002), on trouve l’unité,la dimension, le format d’échange de valeur par défaut,le nom, la définition, les références et, dans le casdes propriétés dépendant du contexte, les paramètres decontexte dont elles dépendent (ici AAE 029-005 : lafréquence du courant).

3.1.4. Méthode d’identification

PLIB offre également une identification non ambiguëpour n’importe quelle propriété définie dans un diction-naire PLIB : la concaténation du code de l’entité (normeou société) ayant défini la classe, du code de la classe(unique pour cette entité), et du code de la propriété(unique pour cette classe) définit en effet de façon univer-selle et non ambiguë chaque propriété. C’est ce simplecode, appelé un BSU (Basic Semantic Unit), qu’il serasuffisant de mémoriser dans un modèle de produit (parexemple un fichier STEP) pour caractériser une propriété( figure 15).

409

G. Pierra

Figure 16. Un exemple de dictionnaire PLIB dans un catalogue fournisseur.

3.1.5. Un exemple

L’exemple ci-après (figure 16) montre le dictionnairede données, classes et propriétés, défini par un fabricantde roulements pour informatiser son catalogue conformé-ment à la norme PLIB.

Les propriétés définies à chacun des niveaux sontimplicitement définies pour tous les niveaux inférieurset peuvent être utilisées pour des requêtes à chacun desniveaux où elles sont définies.

3.2. Des dictionnaires de données auxbibliothèques de composants

Si les dictionnaires permettent de définir les famillesde composants et les types de propriété qui leur sont as-sociés, ils ne permettent, ni de sélectionner un composantparticulier dans une famille en calculant toutes les valeursde ses propriétés (par exemple : calculer la durée de vied’un roulement en fonction de la charge dynamique quel’on va lui appliquer et de sa vitesse prévue de rotation),ni d’en générer des représentations (par exemple : créa-tion de la représentation géométrique à partir d’un pro-gramme paramétré). Ce domaine correspond à la notionde bibliothèque à proprement parler. Il est couvert parles parties 20 (publiée commeInternational Standard:IS) et 24 (en cours de publication IS) de PLIB. Les mo-

dèles de données définis dans ces spécifications permet-tent à la fois de représenter les domaines de valeurs auto-risés pour les propriétés susceptibles d’être choisies parl’utilisateur (propriétés caractéristiques et paramètres decontexte), et de définir les méthodes de calcul (« fonc-tions de dérivation ») pour les propriétés pouvant être cal-culées. Lafigure 17ci-dessous montre l’ensemble des in-formations susceptibles d’être fournies par un fabricantde roulements :

• la table de caractéristiques, dont le contenu est fournipar le fabricant de roulements, décrit tous les roulementsde la famille ;

• les paramètres de contexte qui sont définis par le fabri-cant de roulements mais dont les valeurs sont destinées àêtre fournies par l’utilisateur, enfin

• les propriétés dépendant du contexte qui sont destinéesà être automatiquement calculées par le système degestion (le « bibliothécaire ») à partir, d’une part, desvaleurs fournies par l’utilisateur pour les caractéristiqueschoisies et les paramètres de contexte, et, d’autre part, desfonctions de dérivation fournies par le fabricant.

Grâce à ces informations, l’utilisateur pourra, parexemple, chercher tous les roulements ayant des dia-mètres intérieurs et extérieurs fixés, et ayant, dans desconditions données de charge axiale, de charge radialeet de vitesse, une durée de vie supérieure à un certainseuil. Le système bibliothécaire sera alors capable, en ex-

410

Représentation et échange de données techniques

Figure 17. Connaissance modélisée sur une famille de roulements.

ploitant les seules informations fournies par le fabricant,de calculer le ou les roulements satisfaisant les exigencesénoncées.

Notons que les caractéristiques d’identification (quiapparaissent dans la figure ci-dessus) sont les seulescaractéristiques qu’il est indispensable de conserver pouridentifier le composant au sein de sa famille.

3.2.1. Représentations

L’architecture de la norme PLIB permet alors au four-nisseur d’associer autant de représentations que néces-saire aux composants de la bibliothèque. La définition ducomposant, qui correspond à ce que nous avons présentéà la section précédente, est définie dans une hiérarchie declasses dite « classes de modèles généraux ». Chaque re-présentation est définie par une autre hiérarchie de classesdite « classes de modèles fonctionnels » [19] (figure 18).

Chaque nouvelle classe de modèles fonctionnels estdéfinie par un fascicule de la série 100. Actuellementdeux tels fascicules existent. Le fascicule 101 (view ex-change protocol by parametric representation) permet defournir des représentations géométriques sous forme deprogrammes de géométrie paramétrée. Le fascicule 102(view exchange protocol by ISO 10303 conforming repre-sentation) permet d’associer à chaque composant de labibliothèque n’importe quelle représentation susceptibled’être définie par un protocole d’application de STEP.

Figure 18. Connaissance modélisée sur une famille de roule-ments.

3.3. Des bibliothèques de composantsaux catalogues informatiséesintelligents

Ainsi que nous l’avons montré précédemment, unmodèle de données EXPRESS peut permettre de saisirtoute la connaissance sur le comportement et les critèresde sélection d’un composant. Mais le fichier d’échangerésultant (cf.figure 6) est extrêmement peu lisible.

Or, il existe également une autre manière de présenterune connaissance sur un univers de composants : c’estla méthode documentaire telle qu’elle est utilisée dansles catalogues papiers, ou telle qu’elle commence à être

411

G. Pierra

TABLEAU I

EXPRESS HTML/XML+ • cohérence: contraintes d’intégrité (sémantique des données)

• connaissance modélisée de façon explicite: utilisable parmachine (sélection. . .)

• très synthétiqueet donc compréhensible par l’homme

• peut devenir «dynamique» (liens, applets Java. . .)

− • fichier d’instances pas lisible pour l’homme • pas de garantie de cohérence: pas de contraintes d’intégrité(possibilité d’erreur de contenu)

• connaissance implicite: inutilisable par machine

utilisée dans les documents électroniques de type pdf,HTML ou XML.

La confrontation EXPRESS–HTML/XML donne lacomparaison suivante (voirtableau I).

Il était donc tentant d’essayer de marier les deux uni-vers pour fournir une représentation et une interface do-cumentaire, et donc lisible (un catalogue), à la connais-sance explicite, donc traitable par machine, représentéeen PLIB (domaine de valeur, fonction de dérivation. . . ).

Ce travail a été fait récemment [13] à travers :

• une méthode permettant d’associer à un modèle dedonnées EXPRESS une structure de document XML(une « DTD ») permettant de présenter de façon lisiblela même information ;

• un environnement de développement permettant d’as-socier à un document XML la représentation explicitede l’information qu’il contient sous forme d’une popu-lation EXPRESS.

Cet environnement permet alors, à partir d’un do-cument purement statique de type HTML (susceptibled’être généré, par exemple, à partir d’AcrobatTM ou deWordTM) :

• de rajouter interactivement, au sein d’un éditeurSGML/XML, des balises représentant des conceptsPLIB,

• de vérifier, pour chaque information balisée, qu’ellerespecte les contraintes d’un modèle de données EX-PRESS,

• de générer automatiquement un fichier neutre d’échan-ge STEP tel que défini dans lafigure 6,

• de générer automatiquement un document « actif » oùles tables, par exemple, ont été remplacées automa-tiquement par des programmes (des « applets Java »)permettant à l’utilisateur d’interagir avec le document,par exemple pour sélectionner une valeur dans la table.

Figure 19. Une chaîne complète de traitement [13].

La figure 19montre la chaîne de traitement réalisée.

Cette chaîne de traitement génère, à partir d’un simplecatalogue de type HTML ou pdf, à la fois un fichierd’échange PLIB, un catalogue informatisé « actif » pourl’Internet et, par un traitement de mise en forme spé-cifique en SGML, le programme de commande d’unephotocomposeuse pour l’impression papier. La mise aupoint de cette chaîne a été réalisée dans le cadre d’unpartenariat entre EDF, TOSHIBA Corp., ITEMATIC,le LISI/ENSMA et AUBIN Imprimeur.

4. REPRÉSENTATION DE COMPOSANTSPLIB DANS UN MODÈLE STEP

Si les représentations (par exemple géométriques)générées par une bibliothèque PLIB doivent évidemmentpouvoir être échangées dans un modèle STEP, deuxautres besoins ont progressivement émergé. D’une part,un besoin de traçabilité, visant à représenter dans STEPnon seulement l’objet bibliothèque, mais également la

412

Représentation et échange de données techniques

Figure 20. Gestion intégrée des produits et composants.

référence à sa source dans une bibliothèque PLIB, et lescritères de choix qui ont abouti à sélectionner cet objet.D’autre part, un besoin d’intégration plus profonde desdeux normes visant à permettre dans un modèle STEP leseul échange des références à PLIB, le système receveurrégénérant, si besoin est, les représentations à partir de sapropre bibliothèque.

Deux ans se sont avérés nécessaires à la fois pour dé-velopper une solution technique et dégager un consensus.A l’heure actuelle, des modèles de données EXPRESSexistent pour satisfaire ces deux besoins au sein d’un pro-tocole d’application [25].

La figure suivante (figure 20) montre l’infrastructureinformatique retenue dans certaines grandes entreprisesd’ingénierie pour gérer l’ensemble de leurs données tech-niques. Le référentiel produit ne contient des composantsque les seules informations nécessaires pour les identifierou enregistrer les raisons qui ont conduit à les sélection-ner. Le référentiel composant quant à lui décrit exhaus-tivement, en format PLIB, les composants dont l’usageest, ou a été, autorisé dans l’entreprise. Il permet égale-ment la recherche de composants adaptés lors des phasesde conception.

Une telle architecture permet :

• d’éviter la redondance,

• de tracer le pourquoi des choix, enfin

• de faciliter la maintenance ultérieure des produits(usines ou installations).

5. CONCLUSION

La généralisation de l’informatique dans le domainetechnique impose à chaque entreprise de choisir leslangages, les modèles, les outils et les systèmes lui

permettant de représenter, d’exploiter et d’archiver sonpatrimoine informationnel sous forme numérique. Danscet article, nous avons montré les multiples apportsrésultant des projets STEP et PLIB pour faciliter ceschoix.

Au niveau langage, le langage EXPRESS apparaîtcomme le formalisme de spécification le plus avancé au-jourd’hui pour la représentation des données hautementstructurées telles qu’on les rencontre dans la modélisa-tion d’objets techniques, par exemple dans le domaine dela géométrie. Il permet d’exprimer n’importe quel typede contraintes. Il spécifie à la fois des formats d’échangeet d’archivage, et des interfaces d’accès. Enfin son carac-tère textuel le rend compilable : programmes de lecturede fichiers d’échanges et interface d’accès à des bases dedonnées peuvent être générées automatiquement à partirdu seul modèle de données.

Au niveau des modèles de données, STEP définit à lafois des ressources génériques pour la modélisation desproduits, et des modèles complets et finalisés pour uncertain nombre de domaines. PLIB définit des ressourcesgénériques pour la modélisation ducomportementdesproduits et composants. Il définit un modèle et une mé-thode pour fabriquer des dictionnaires de types d’objetset de propriétés associés. Il définit enfin un modèle com-plet et finalisé de catalogues de composants industrielscontenant non seulement la description des composants,mais encore la connaissance sur leur comportement etles règles devant présider à leur sélection. L’utilisationconjointe de STEP et de PLIB dans un modèle de pro-duit permet outre le fait de représenter le produit tel qu’ilest, de représenter également, pour les composants quiy figurent, les critères selon lesquels ils ont été choisiset les propriétés qu’ils doivent conserver en cas de sub-stitution ultérieure dans la phase de maintenance. Enfin,des dictionnaires de données basés sur PLIB existent dèsà présent. La norme CEI 61630-4 définit un tel diction-naire pour le domaine des composants électroniques etdes propriétés associées.

Au niveau des outils, les langages et modèles pré-cédents sont instrumentés. Un grand nombre d’outilsEXPRESS existent dès à présent, gratuits ou commercia-lisés, tant sous forme d’éditeur, que de compilateur, degénérateur de code ou de gestionnaire de données. Desinterfaces STEP apparaissent de plus en plus et commen-cent à être certifiées. Des gestionnaires de bibliothèquesPLIB, ainsi que des générateurs de catalogues actifs pourl’Internet basés sur le modèle PLIB, apparaissent en tantque produits commercialisés pour les premiers et de pro-totypes pour les seconds.

413

G. Pierra

L’ensemble de cette technologie est maintenant stable,mature et largement accepté. Certes, elle est encore enphase de déploiement. Les outils EXPRESS peuventcontenir des erreurs, et les modèles de données et inter-faces quelques anomalies. Mais c’est le propre de toutenouvelle technologie que de passer par une phase de ro-dage. Et c’est aussi dans cette phase de rodage que l’onprend un avantage compétitif significatif en maîtrisantune technologie émergente. L’objet de cet article est demettre en évidence les multiples potentialités de cettetechnologie.

Remerciements

L’auteur remercie à la fois les ingénieurs de l’Associa-tion GOSET, centre de compétences français sur le stan-dard STEP, et Eric Sardet, du LISI/ENSMA, pour certaindes exemples et figures utilisés dans ce papier et dont ilsont à l’origine.

RÉFÉRENCES

[1] Pierra G., Sardet E., Potier J.C., Battier G., Derouet J.C.,Wilman N., Mahir A., Exchange of component data : ThePLIB model, standard and tools, in : Proc. 9th InternationalConference on Entreprise Integration and CALS, CALS EU-ROPE ’98, Paris, France, 16–18 septembre 1998, pp. 160–176,http://www.plib.ensma.fr.

[2] Schenck D., Wilson P., Information Modelling the EXPRESSWay, Oxford University Press, 1994.

[3] ISO 10303-11, Industrial Automation Systems and Integra-tion — Product Data Representation and Exchange — Part 11 :Description methods : The EXPRESS language reference ma-nual, 1994.

[4] Bouazza M., La norme STEP, Hermès, Paris, 1995.[5] Bouazza M., Le langage EXPRESS, Hermès, Paris, 1995.[6] Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W.,

Object Oriented Modelling and Design, Prentice-Hall, 1991.[7] Jacobson I., Booch G., Rumbaugh J., The Unified Software

Development Process, Addison-Wesley, 1999.[8] Meyer B., Object-oriented Software Construction, Prentice-

Hall, Hemel Hempstead, UK, 1988.[9] Atkinson M., Bancilhon F., Dittrich K., Maier D., Zoo Nik S.,

The Object-oriented Database System Manifesto. Deductiveand Object-oriented Databases, Elsevier/North-Holland, Am-sterdam, 1990, pp. 223–240.

[10] Ait-Ameur Y., Besnard F., Girard P., Pierra G., Potier J.C., For-mal specification and metaprogramming in the EXPRESS lan-guage, in : International Conference on Software Engineeringand Knowledge Engineering SEKE ’95, IEEE-ACM Sigsoft,Rockville, USA, 1995, pp. 181–189.

[11] Ait-Ameur Y., Pierra G., Sardet E., Using the EXPRESSlanguage for metaprogramming, in : Proc. 3rd InternationalConference of EXPRESS User Group EUG ’95, Grenoble,France, 21–22 octobre, 1995.

[12] Coad P., Yourdon E., Object-oriented Analysis, Prentice-Hall,Englewood Cliffs, NJ, 1992.

[13] Sardet E., Intégration des approches modélisation concep-tuelle et structuration documentaire pour la saisie, la représen-tation, l’échange et l’exploitation d’informations. Applicationaux catalogues de composants industriels, Thèse de Doctoraten Informatique, Université de Poitiers, Poitiers, 1999.

[14] Habrias H., Introduction à la spécification, Masson, 1993.[15] ISO 10303-21, Industrial Automation Systems and Integra-

tion — Product Data Representation and Exchange — Part 21 :Implementation methods : Clear text encoding of the exchangestructure (Physical File), 1994.

[16] ISO 10303-22, Industrial Automation Systems and Integra-tion — Product Data Representation and Exchange — Part 22 :Implementation methods : Standard data access interface,1997.

[17] Randoing J.M., Les SGDT, Hermès, Paris, 1995.[18] Féru F., Viel Ch., Echanger avec le protocol d’application 203

de STEP, in : Echange et Partage de Données CAO et GDT,Ass. GOSET, Nanterre, 1998.

[19] Pierra G., Modelling classes of pre-existing components ina CIM perspective : the ISO13584/ENV 400014 approach,Revue Internationale de CFAO et d’Infographie 9 (3) (1994)435–454.

[20] Pierra G., Intelligent electronic component catalogues for en-gineering and manufacturing, in : Proc. International Sympo-sium on Glogal Engineering Networking, GEN ’97, Antwerp,Belgium, 2–24 avril 1997, pp. 331–352.

[21] ISO 13584-20, Industrial Automation Systems and Integra-tion — Parts Library — Part 20 : Logical resource : Logicalmodel of expressions, 1999.

[22] ISO DIS 13584-24, Industrial Automation Systems and Inte-gration — Parts Library — Part 24 : Logical resource : Logicalmodel of supplier library, 1999.

[23] ISO 13584-42, Industrial Automation Systems and Integra-tion — Parts Library — Part 42 : Description methodology :Methodology for structuring parts families, ISO, Genève,1998.

[24] IEC 61360-4, Standard Data Element Types with AssociatedClassification Scheme for Electric Components — Part 4 :IEC reference collection of standard data element types,component classes and terms, 1997.

[25] Staub G., Interpretation of PLIB services : A proposal forinterpretation of the “services” provided by PLIB usingthe STEP Integrated Resources ISO TC184/SC4/QC/N068,http://www.nist.gov/sc4/wg_qc/qc/qcn068/qcn068.pdf/.

[26] Fowler J., STEP for Data Management Exchange and Sharing,Technology Appraisals, 1995.

[27] Sardet E., Pierra G., Formal specification, modelling andexchange of classes of components according to PLIB. A casestudy, in : Proc. of the International Symposium on GlobalEngineering Networking, GEN ’97, Antwerp, Belgium, 2–24avril 1997, pp. 179–201.

414