FR2904714A1

FR2904714A1 - Procede de modelisation graphique tridimensionnelle

Info

Publication number: FR2904714A1
Application number: FR0653284A
Authority: FR
Inventors: Marc Pierre Stefano; Stephane Cadet; Jacques Luigi; David Rodriguez; Jerome Mortain; Bruno Casimir
Original assignee: Peugeot Citroen Automobiles SA
Current assignee: PSA Automobiles SA
Priority date: 2006-08-04
Filing date: 2006-08-04
Publication date: 2008-02-08
Anticipated expiration: 2026-08-04
Also published as: EP2050029A1; WO2008015359A1; FR2904714B1

Abstract

L'invention concerne le domaine des procédés de modélisation graphique tridimensionnelle. C'est un procédé de modélisation graphique tridimensionnelle d'une zone d'interface (j2, i4) entre au moins deux pièces mécaniques (1, 2, 3, 4, 5), comprenant : une étape d'envoi (cp), vers une ressource logicielle cible (10) sous le contrôle d'un utilisateur, d'une information d'alerte relative à la modification, d'une pièce dans la zone d'interface, réalisée au niveau d'une autre ressource logicielle sous le contrôle d'un autre utilisateur ; une étape d'affichage, au niveau de la ressource logicielle cible, d'une modélisation graphique tridimensionnelle de la zone d'interface intégrant ladite modification, lors de l'activation, au niveau de la ressource logicielle cible, d'un élément graphique d'alerte (11) représentant l'information d'alerte.

Description

PROCEDE DE MODELISATION GRAPHIQUE TRIDIMENSIONNELLE

L'invention concerne le domaine des procédés de modélisation graphique tridimensionnelle, et plus particulièrement les procédés de modélisation graphique tridimensionnelle d'une zone d'interface entre deux pièces mécaniques. Usuellement dans le domaine de la conception de pièces mécaniques, chaque pièce est conçue par un dessinateur. Ainsi, les zones d'interface entre pièces mécaniques sont des zones où peuvent intervenir plusieurs concepteurs.

Pour que l'ensemble mécanique formé par les pièces mécaniques puisse être conçu correctement dans un temps raisonnable, une coordination étroite entre les concepteurs des pièces est nécessaire au niveau de la zone d'interface entre les pièces. C'est pourquoi, chaque fois que le concepteur d'une pièce modifie sa pièce au niveau de l'interface avec une autre pièce, il lui faudra discuter avec le concepteur de l'autre pièce la faisabilité de la modification envisagée, le plus souvent lors de la prochaine réunion d'équipe, laquelle peut nécessiter d'attendre un temps plus ou moins long.

Pendant ce temps, le concepteur de l'autre pièce ignore tout de la modification envisagée, il ne la découvrira souvent que lors de la prochaine réunion d'équipe. Le concepteur de la pièce à modifier pourrait tenter de joindre son collègue pour lui expliquer la modification qu'il envisage, mais il peut avoir des difficultés à le joindre, voire oublier de le faire. Pour résoudre cet inconvénient, l'invention propose un procédé dans lequel, même lorsque le concepteur d'une pièce oublie de signaler au concepteur d'une autre pièce, ou à toute personne intéressée par l'évolution de la zone d'interface entre les pièces, d'une modification envisagée à sa pièce justement au niveau de la zone d'interface entre pièces, leconcepteur de l'autre pièce ou toute autre personne intéressée peut être automatiquement avertie de la modification envisagée, ce qui lui permet d'en prendre connaissance avant la prochaine réunion d'équipe. Selon l'invention, il est prévu un procédé de modélisation graphique tridimensionnelle d'une zone d'interface entre au moins deux pièces mécaniques, comprenant : une étape d'envoi, vers une ressource logicielle cible sous le contrôle d'un utilisateur, d'une information d'alerte relative à la modification, d'une pièce dans la zone d'interface, réalisée au niveau d'une autre ressource logicielle sous le contrôle d'un autre utilisateur ; une étape d'affichage, au niveau de la ressource logicielle cible, d'une modélisation graphique tridimensionnelle de la zone d'interface intégrant ladite modification, lors de l'activation, au niveau de la ressource logicielle cible, d'un élément graphique d'alerte représentant l'information d'alerte.

Cette fluidité de circulation de l'information entre les membres d'une même équipe de conception, rendue possible grâce au procédé de l'invention permettant, lorsque l'un des membres envisage une modification de sa pièce au niveau de la zone d'interface avec une ou plusieurs autres pièces, un avertissement automatique du ou des autres membres intéressés, permet pour un temps de développement projet prédéterminé d'améliorer nettement la robustesse de la zone d'interface considérée, en évitant ou à tout le moins en diminuant fortement le risque, d'une remise en cause tardive des différents paramètres de la zone d'interface, ce qui peut alors se traduire par des surcoûts importants. La possibilité de visualiser en temps réel l'état d'une interface, et notamment la ou les propositions de modification envisagées par un ou plusieurs concepteurs de pièce au niveau d'une zone d'interface et non encore admises par l'ensemble des intervenants au niveau de cette zone d'interface, permet unean imation de zone d'interface, et notamment par un an imateur d'interface, qu i est plus efficace et plus rapide. Par ail leurs, cette possibil ité s'accompagne de celle de pouvoir échanger d irectement et en temps réel des informations relatives à la zone d'interface dans la mesure où toute contre proposition à la mod ification envisagée sera signalée de la même man ière au concepteur auteur de la mod ification envisagée. L'élément graph ique d'alerte est tout élément graph ique qu i va pouvoir symbol iser pour un util isateur une alerte signalant qu'une mod ification d'une pièce au n iveau de la zone d'interface considérée est demandée par le concepteur de la pièce devant être mod ifiée. Cet élément graph ique peut être un élément ajouté à l'existant ou bien une mod ification de l'existant ou encore une combinaison des deux. Dans une réal isation préférentielle, l 'élément graph ique d'alerte est un icône s'ajoutant à l' information existante. Dans une autre réal isation , l 'élément graph ique est une mod ification de la mise en forme d'une information existante. De préférence, l'affichage de l'élément graphique d'alerte est représentatif de la pièce modifiée. En effet, il est intéressant non seulement d'être alerté d'une proposition de modification, mais de pouvoir visualiser immédiatement au niveau de la situation de l'élément graphique d'alerte, quelle pièce de la zone d'interface est concernée par la modification proposée. Avantageusement, l'affichage de l'élément graphique d'alerte est représentatif de la ressource logicielle au niveau de laquelle la modification a été réalisée ou de l'utilisateur contrôlant ladite ressource logicielle. En effet, dans les projets assez vastes ou complexes, où plus d'un concepteur peut travailler sur une pièce, il est également intéressant de savoir lequel des concepteurs travaillant sur la pièce concernée propose la modification de ladite pièce.

Le procédé de modélisation peut prévoir que seules certaines modifications, jugées suffisamment importantes pour présenter un impact vis-à-vis d'autres intervenants au niveau de la zone d'interface, seront publiées, c'est-à-dire envoyées vers la ressource logicielle d'un autreutilisateur. Toutefois, pour éviter les dérives, il est préférable de signaler toute modification de pièce au niveau de la zone d'interface, de quelque ordre qu'elle soit. Ainsi, de préférence, toute modification d'une pièce dans la zone d'interface entraîne l'envoi d'au moins une information d'alerte vers une ressource logicielle cible.

De préférence, au moins une modification de pièce dans la zone d'interface, voire toute modification de pièce dans la zone d'interface, entraîne l'envoi d'une information d'alerte vers plusieurs ressources logicielles cibles. En effet, dans un projet concret, de nombreux intervenants au niveau de la zone d'interface peuvent être intéressés par une mise en connaissance de cause le plus tôt possible d'une proposition de modification d'une pièce au niveau de la zone d'interface. Ce sont par exemple les concepteurs des autres pièces dont une partie au moins est située au niveau de la zone d'interface. Ce sera aussi par exemple un animateur d'interface chargé de surveiller et d'harmoniser l'évolution d'une zone d'interface. De préférence, les éléments graphiques d'alerte correspondant à plusieurs zones d'interface peuvent être affichés simultanément. Cette fonctionnalité est intéressante surtout pour l'animateur d'interface, elle peut toutefois l'être aussi pour un concepteur dont la pièce présente plusieurs zones d'interface avec la pièce d'un autre concepteur.

Pour éviter d'alerter les autres intervenants au niveau d'une zone d'interface de manière intempestive, c'est-à-dire éviter d'envoyer une information d'alerte pour proposer une modification puis d'envoyer une autre information d'alerte proposant une contre modification ayant pour but soit de revenir à l'état initial soit de faire encore évoluer la modification proposée depuis la dernière version stabilisée, de préférence, une proposition de modification ne sera signalée aux autres intervenants que si elle semble suffisamment mature et avancée au moins à son propre auteur. Ainsi, de préférence, l'information d'alerte est envoyée dès que la modification est validée par son auteur. De préférence, un ou plusieurs éléments graphiques références correspondant respectivement à une ou plusieurs versions stabilisées de la zone d'interface associée à l'élément graphique d'alerte peuvent êtreaffichés simultanément à l'élément graphique d'alerte, l'activation d'un élément graphique référence affichant la modélisation graphique tridimensionnelle de la version stabilisée correspondante de la zone d'interface. Ainsi la comparaison directe possible entre la version stabilisée la plus récente et la proposition de modification permet une estimation plus aisée de l'impact de ladite modification. Cette fonctionnalité avantageuse gardant l'historique de l'évolution d'une zone d'interface permet aussi une vision plus claire de l'évolution de la zone d'interface ainsi qu'un retour en arrière plus aisé si l'on a abouti à une impasse. Elle permet de retrouver à tout moment l'état des zones d'interface au niveau de tous les jalons du processus de conception. De préférence, la modélisation graphique tridimensionnelle est accompagnée d'un commentaire textuel. Cette fonctionnalité est particulièrement intéressante pour les modifications qui ne se voient pas immédiatement de manière graphique ou qui ne se voient qu'imparfaitement de manière graphique, le commentaire textuel pouvant avoir un rôle de précision et / ou d'explication, voire de justification en véhiculant le pourquoi de la proposition de modification. De préférence, l'affichage d'un élément graphique d'alerte est accompagné de l'affichage d'un élément graphique de mise en garde lorsque la modification de pièce à l'origine de l'élément graphique d'alerte transgresse une ou plusieurs règles programmables dans le procédé de modélisation graphique tridimensionnelle. Ceci permet immédiatement de se rendre compte du caractère plus ou moins difficile et / ou dangereux de la mise en œuvre effective de la modification proposée. Ainsi, par exemple l'animateur de zone d'interface pourra rejeter rapidement comme irrecevable une proposition de modification transgressant de manière significative une règle impérative, évitant ainsi à un autre concepteur de perdre du temps sur un essai d'adaptation à une modification qui n'a aucune chance d'être retenue au final. Ce garde fou imposant le respect d'un minimum de règles métier à tous les stades de la conception ou à tout le moins signalant les dérives permet d'améliorer ou à tout le moins d'évaluer la robustesse de la zone d'interface. Ces règles métier, avantageusement programmables au gré de l'utilisateur, peuvent être parexemple des règles de conception ou bien des règles de fabrication, ou encore un panachage des deux.

De préférence, la zone d'interface correspond à une liaison entre pièces mécaniques. En effet, ce type de zone d'interface demande une coordination particulièrement poussée entre les concepteurs des différentes pièces intervenant au niveau de ladite zone d'interface. Avantageusement, la liaison est un point de fixation. Là encore, pour une meilleure solidité du point de fixation, et donc au total de la structure globale, une bonne coordination entre concepteurs est nécessaire. De préférence, les pièces mécaniques sont des pièces mécaniques automobiles. En effet, un projet véhicule nécessite le traitement de plusieurs centaines d'interface. C'est pourquoi un outil comme le procédé de modélisation selon l'invention est particulièrement bénéfique et intéressant dans le domaine automobile. De préférence, un élément graphique d'alerte est affiché au niveau d'un fichier catpart ou catproduct d'un logiciel de la famille catia. Ce logiciel est avantageusement catia v 5 ou une version postérieure.

L'invention va maintenant être décrite plus en détail à l 'aide des figures ci-après, données à titre d'exemples illustratifs et non l imitatifs, où :

- la figure 1 représente schématiquement un exemple de plusieurs vues de zones d' interface entre pl usieurs pièces mécan iques relevant de plusieurs concepteurs ; - la figure 2 représente schématiquement un exemple d'envoi automatique selon l'invention de mod ifications envisagées pour certaines pièces dans les zones d'interface associées vers un espace d'an imation de zone d'interface ainsi q ue l'affichage au n iveau dud it espace d'an imation .

La figure 1 représente schématiquement un exemple de plusieurs vues de zones d' interface entre pl usieurs pièces mécan iques relevant de plusieurs concepteurs. Plusieurs vues partielles d'un même ensemble mécan ique sont util isées afinde ne pas trop surcharger une vue complète unique qui serait devenue trop peu lisible. Au niveau de la carrosserie d'une automobile, une doublure d'arc pavillon 1 est solidaire d'une doublure d'aile arrière 4 ainsi que d'une doublure de montant de baie 5. Sur l'ensemble de ces doublures va être fixé un faisceau électrique 3 qui va lui-même être recouvert par un garnissage 2. Dans cet exemple, le faisceau électrique 3 présente cinq zones d'interface il à i5 avec l'ensemble des doublures, tandis que le garnissage présente deux zones d'interface j1 et j2 avec l'ensemble des doublures. On va s'intéresser plus particulièrement d'une part à la zone d'interface j2 entre la pièce 1 qui est conçue sous la responsabilité d'un concepteur C1 et la pièce 2 qui est conçue sous la responsabilité d'un concepteur C2 et d'autre part à la zone d'interface i4 entre la pièce 1 et la pièce 3 qui est conçue sous la responsabilité d'un concepteur C3. La figure 2 représente schématiquement un exemple d'envoi automatique selon l'invention de modifications envisagées pour certaines pièces dans les zones d'interface associées vers un espace d'animation de zone d'interface ainsi que l'affichage au niveau dudit espace d'animation. Les parties de la figure 2 déjà décrites au niveau de la figure 1 ne seront pas décrites à nouveau. Un fichier 10 zones d'interface est manipulé par un animateur de zones d'interfaces qui est responsable d'un certain nombre de zones d'interface au niveau d'un ensemble de pièces mécaniques automobiles. L'animateur d'interfaces peut être un intervenant extérieur aux bureaux d'études impliqués dans les zones d'interface, ou un des concepteurs travaillant directement sur les zones d'interface. Par mesure de simplicité, dans ce fichier 10, seules deux zones d'interface, j2 et i4, ont été représentées mais le fichier 10 peut en contenir beaucoup plus. La ressource logicielle de l'animateur de zones d'interface abritant et affichant le fichier 10 est une ressource logiciellecible . Ce type de fich ier, dans une version contenant généralement moins de zones interface, voire une seule, peut aussi se trouver sur la ressource log icielle d'un concepteur de pièce dont la pièce présente une ou pl usieurs zones d'interface avec une autre pièce ou avec plusieurs autres pièces. Le fich ier 1 0 est avantageusement structuré de la man ière su ivante lorsq u'il est affiché. La zone d'interface j2 comprend deux sous répertoires, VS et P. Le sous répertoire VS, comprend des versions stabil isées de la zone d'interface, c'est-à-d ire des versions qui à un moment donné, ont été acceptées par tous les membres de l 'équ ipe intervenant au n iveau de cette zone d'interface ou ont été imposées par l'an imateur d'interface ou de man ière plus générale ont été stabil isées par un responsable parce que toutes les objections avaient été surmontées ou toutes les mod ifications prises en compte. Sur la figure 2, sont représentées deux versions antérieures, une version VN plus ancienne et une version VN + 1 plus récente. Cet h istorique des versions stabil isées de la zone d' interface permet de su ivre évolution de la zone d'interface au cours du temps.

Le sous répertoire P, comprend des propositions de mod ification éventuelles en provenance de d ifférents concepteurs. La zone d'interface j2 est une zone d' interface entre les pièces 1 et 2. Par conséquent, ce sont les concepteurs des pièces 1 et 2, à savoir respectivement les concepteurs C1 et C2, qu i vont pouvoir proposer des mod ifications, respectivement aux pièces 1 et 2. Sur la figure 2, seul le concepteur C 1 a proposé une mod ification laquelle est signalée par l'élément graph ique d'alerte 11 qu i est ici un icône triangulaire s'ajoutant à la mention C 1 en étant affiché au voisinage de la mention C 1 ; ce pourrait être la mention C 1 el le-même affichée dans une autre couleur. Aucun élément graph ique d'alerte n'est affiché au n iveau de la mention C2, le concepteur C2 n'a donc pas proposé de mod ification . Parailleurs, la modification proposée par le concepteur C1 viole une règle programmable, par exemple une règle de conception ou de fabrication associée à la pièce 1, ce qui est automatiquement signalé par l'affichage d'un élément graphique de mise en garde 12, ici sous forme d'un feu rouge. Une activation de l'élément graphique d'alerte 11 permet l'affichage, au niveau de la ressource logicielle affichant le fichier 10, d'une modélisation tridimensionnelle de la zone d'interface j2 qui intègre la modification proposée par le concepteur C1 au niveau de la pièce 1. Ainsi par simple activation de l'élément graphique 11, par exemple par simple clic ou double clic dessus, l'animateur de la zone d'interface j2 et / ou le concepteur C2 de la pièce 2 peuvent se rendre immédiatement compte de manière visuelle de la modification proposée par le concepteur C1 au niveau de la pièce 1, laquelle modification peut bien sûr entraîner une nécessité de modification au niveau de la pièce 2.

Une activation de l'élément graphique de mise en garde 12 permet l'affichage, au niveau de la ressource logicielle cible affichant le fichier 10, de la règle programmable qui serait violée par la modification proposée, voire même d'une information expliquant pourquoi cette modification est constitutive d'une violation et / ou en quoi consiste cette violation. La zone d'interface i4 comprend les deux mêmes sous répertoires, VS et P. Le sous répertoire VS est identique à celui de la zone d'interface j2. Selon l'état d'avancement du projet de conception, il peut toutefois comprendre moins ou plus de versions stabilisées. Le sous répertoire P, de manière similaire, comprend des propositions de modification éventuelles en provenance de différents concepteurs. La zone d'interface i4 est une zone d'interface entre les pièces 1 et 3. Par conséquent, ce sont les concepteurs des pièces 1 et 3, à savoir respectivement lesconcepteurs C1 et C3, qui vont pouvoir proposer des modifications, respectivement aux pièces 1 et 3. Sur la figure 2, seul le concepteur C3 a proposé une modification laquelle est signalée par l'élément graphique d'alerte 11. Aucun élément graphique d'alerte n'est affiché au niveau de la mention C1, le concepteur C1 n'a donc pas proposé de modification. Par ailleurs, la modification proposée par le concepteur C3 ne viole aucune règle programmable, que ce soit de conception ou de fabrication associée à la pièce 3, cela peut se remarquer par l'absence d'affichage d'un élément graphique de mise en garde 12.

Une activation de l'élément graphique d'alerte 11 permet l'affichage, au niveau de la ressource logicielle affichant le fichier 10, d'une modélisation tridimensionnelle de la zone d'interface i4 qui intègre la modification proposée par le concepteur C3 au niveau de la pièce 3. Ainsi par simple activation, l'animateur de la zone d'interface i4 et / ou le concepteur C1 de la pièce 1 peuvent se rendre immédiatement compte de manière visuelle de la modification proposée par le concepteur C3 au niveau de la pièce 3, laquelle modification peut bien sûr entraîner une nécessité de modification au niveau de la pièce 1.

De manière symbolique, des flèches cp signalent l'envoi d'une information d'alerte relative à une proposition de modification des différents concepteurs vers le fichier de zones d'interface. Ces flux d'envoi d'information sont établis en début de projet et sont conservés, même s'il n'est pas impossible de les modifier en cours de projet. C'est parce qu'il a été prévu qu'une modification de la pièce 1 au niveau de la zone d'interface j2 de la part du concepteur C1 générerait l'envoi d'une information d'alerte vers le fichier 10, qu'un élément graphique d'alerte 11 est affiché dans le sous répertoire P de la zone d'interface j2 au voisinage de la mention C1 , au niveau de l'affichage du fichier 10.De la même manière, c'est parce qu'il a été prévu que toute modification de la pièce 3 au niveau de la zone d'interface i4 de la part du concepteur C3 générerait l'envoi d'une information d'alerte vers le fichier 10, qu'un élément graphique d'alerte 11 est affiché dans le sous répertoire P de la zone d'interface i4 au voisinage de la mention C3. De la même manière également, en cas de proposition de modification émanant du concepteur C1 pour l'interface i4 ou du concepteur C2 pour l'interface j2, des éléments graphiques 11 seraient affichés soit dans le sous répertoire P de la zone d'interface i4 au voisinage de la mention C1, soit dans le sous répertoire P de la zone d'interface j2 au voisinage de la mention C2. Ainsi, la mise en connaissance de cause anticipée d'une modification de pièce au niveau d'une zone d'interface permet une visualisation en temps réel de l'évolution d'une zone d'interface et améliore l'efficacité de la prochaine réunion dédiée à l'évolution de cette zone d'interface, chaque intervenant ayant pu prendre connaissance automatiquement des modifications proposées par les autres en avance de ladite réunion.

Le fichier 10 est de préférence un fichier catproduct (marque déposée) du logiciel catia v5 (marque déposée), mais l'information peut aussi être supportée par un fichier catpart (marque déposée).

Claims

.

REVENDICATIONS

1) Procédé de modélisation graphique tridimensionnelle d'une zone d'interface (j2, i4) entre au moins deux pièces mécaniques (1 , 2, 3, 4, 5), comprenant :

- une étape d'envoi (cp), vers une ressource logicielle cible (10) sous le contrôle d'un utilisateur, d'une information d'alerte relative à la modification, d'une pièce dans la zone d'interface, réalisée au niveau d'une autre ressource logicielle sous le contrôle d'un autre utilisateur ;

- une étape d'affichage, au niveau de la ressource logicielle cible, d'une modélisation graphique tridimensionnelle de la zone d'interface intégrant ladite modification, lors de l'activation, au niveau de la ressource logicielle cible, d'un élément graphique d'alerte (11) représentant l'information d'alerte.
2) Procédé selon la revendication 1 , caractérisé en ce que l'élément graphique d'alerte est un icône s'ajoutant à l'information existante.
3) Procédé selon la revendication 1 , caractérisé en ce que l'élément graphique est une modification de la mise en forme d'une information existante.
4) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'affichage de l'élément graphique d'alerte est représentatif de la pièce modifiée.
5) Procédé selon la revendication 4, caractérisé en ce que l'affichage d'alerte est représentatif de la ressource logicielle au niveau de laquelle la modification a été réalisée ou de l'utilisateur contrôlant ladite ressource logicielle.
6) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que toute modification d'une pièce dans la zone d'interface entraîne l'envoi d'au moins une information d'alerte vers une ressource logicielle cible.7) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une modification de pièce dans la zone d'interface entraîne l'envoi d'une information d'alerte vers plusieurs ressources logicielles cibles.

8) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'information d'alerte est envoyée dès que la modification est validée par son auteur.

9) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les éléments graphiques d'alerte correspondant à plusieurs zones d'interface peuvent être affichés simultanément.

10) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'un ou plusieurs éléments graphiques références (VN, VN+1) correspondant respectivement à une ou plusieurs versions stabilisées de la zone d'interface associée à l'élément graphique d'alerte peuvent être affichés simultanément à l'élément graphique d'alerte, l'activation d'un élément graphique référence affichant la modélisation graphique tridimensionnelle de la version stabilisée correspondante de la zone d'interface.

11) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la modélisation graphique tridimensionnelle est accompagnée d'un commentaire textuel.

12) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'affichage d'un élément graphique d'alerte est accompagné de l'affichage d'un élément graphique de mise en garde (12) lorsque la modification de pièce à l'origine de l'élément graphique d'alerte transgresse une ou plusieurs règles programmables dans le procédé de modélisation graphique tridimensionnelle.

13) Procédé selon la revendication 12, caractérisé en ce que les règles programmables sont des règles de conception.14) Procédé selon la revendication 12, caractérisé en ce que les règles programmables sont des règles de fabrication.

15) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la zone d'interface correspond à une liaison entre pièces mécaniques.

16) Procédé selon la revendication 15, caractérisé en ce que la liaison est un point de fixation.

17) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les pièces mécaniques sont des pièces mécaniques automobiles.

18) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'un élément graphique d'alerte est affiché au niveau d'un fichier catproduct d'un logiciel de la famille catia.

19) Procédé selon la revendication 18, caractérisé en ce que ledit logiciel est une version de catia.