Données produit autonomes pour une

traçabilité réelle

Camille Planat, sous la direction de Thierry Roux, CIMPA PLM services

Mémoire de master en management des systèmes d’information et d’infrastructure, Institut

d'ingénierie informatique de Limoges (3IL), octobre 2017

Résumé
La réutilisation de données de conception d’un produit dans le cadre de la conception d’un
autre produit implique de rendre autonomes les données réutilisées dans le but d’une
traçabilité complète (1). La définition de quelques concepts permet de clarifier le propos (2).
Cependant, la problématique de l’instance relative est un frein à l’autonomie de la donnée (3).
Des solutions existent mais elles ne répondent pas complètement au besoin (4). La solution
développée sera spécifiée (5), puis implémentée dans Aras Innovator (6).

Mots-clés
Produit étendu, PLM, CAO, données autonomes, contexte, produit dérivé, instance,
occurrence, instance relative, occurrence relative, instance absolue, occurrence absolue,
système d’axes absolu, système d’axes local, référentiel absolu, référentiel relatif

1. Introduction
1.1. Qu’est-ce-que l’effet tunnel ?
Dans un contexte multi produits, tel que l’entreprise étendue,
la multiplication des référentiels complexifie la traçabilité des
informations. L’optimisation du cycle de vie du produit
consiste notamment à faciliter l’ingénierie simultanée au
moyen de mécanismes de collaboration plus agiles.
Cependant notre agilité est bridée par des représentations des
données qui ne permettent pas toujours une traçabilité
complète des objets métier. De plus les représentations des
données sont souvent hétérogènes entre des produits pourtant
liés.
Le besoin d’une vue holistique de l’entreprise étendue a
conduit à de nombreux travaux de recherche [1], [2], [3], [4].
Cependant, des thèmes tels que la sécurité et la confidentialité
font que les cloisonnements subsistent.
Lorsque le donneur d’ordre spécifie son besoin il y a déjà
désynchronisation entre son environnement et celui du sous-
traitant. Cela signifie qu’au moment où le sous-traitant accède
à l’information, celle-ci est déjà périmée.
Même en tenant à jour la spécification en temps réel, il y aura
toujours un décalage entre le besoin et son expression, c’est
l’effet tunnel. Le problème est le même au sein d’une seule
organisation, les métiers collaborent, chaque livrable provoque

1
une désynchronisation. On peut tracer ces désynchronisations
mais ça n’est pas suffisant, on veut aller plus vite.
Dans le contexte du donneur d’ordre, l’agilité va dans le sens
d’une collaboration au sein d’un système d’information unique
ou bien de systèmes unifiés. Dans le contexte du sous-traitant,
qui doit pouvoir travailler avec plusieurs donneurs d’ordre,
l’agilité des donneurs d’ordre conduit au fractionnement de
son savoir entre différents systèmes d’information. Dans son
propre contexte, l’agilité du sous-traitant est sa capacité à
constituer son propre savoir tout en étant capable de tracer
l’utilisation qu’il en fait chez ses clients.
On souhaite pouvoir utiliser des données d’un produit, défini
dans son contexte, dans d’autres produits, chacun défini dans
son contexte. L’objectif est de faciliter la conception et la
configuration du produit, du moyen de production et des
services, qui sont autant de contextes différents avec chacun
ses propres contraintes. Cependant ces différents contextes se
réconcilient dans un contexte commun : la satisfaction du
client.
Il est possible de mettre fin à l’effet tunnel entre ces différents
contextes en rendant la donnée autonome. C’est-à-dire que la
donnée sera toujours la même quel que soit le contexte où elle
est utilisée.
1.2 Pourquoi réutiliser des données d’un produit dans un
autre produit ?
Plus tôt on commence la conception du moyen de production,
plus tôt on peut mettre le produit sur le marché. Il est courant
que des informations relatives au produit commercial soient
transmises aux personnes qui conçoivent le moyen de
production dès le début du cycle de vie du produit
commercial.
On pourrait économiser un temps précieux si on pouvait
utiliser le modèle 3D ou une partie du modèle 3D du produit
commercial directement dans le modèle 3D du moyen de
production et que le modèle 3D ou la partie du modèle 3D du
produit commercial qu’on utilise soit enrichi(e) en temps réel
des changements apportés par ses concepteurs.
De même, lors de la conception d’un produit B, il est courant
de réutiliser des données issues d’un produit A. Admettons
qu’un assemblage du produit A ait causé beaucoup de tracas à
ses concepteurs en termes de conformité, certifications,
industrialisation, etc. La nouvelle version de cet assemblage
dans le produit B diffère quelque peu, on voudrait être capable
de dériver de la première version sans avoir à répéter le
difficile processus qu’ont connu les concepteurs du produit A.
Bien évidemment si la primitive évolue, la dérivée aussi.
Autre exemple, pendant la rédaction de la documentation de
maintenance il est probable qu’on ne communique pas toute la
structure produit à chaque rédacteur pour des raisons de
confidentialité et de praticité. De plus chaque rédacteur a
besoin d’une vue spécifique qui ne correspond pas forcément à
la structuration décidée en conception. La possibilité de définir
des vues qui soient mises à jour automatiquement au fur et à
mesure de la conception du produit serait salutaire.
L’exemple le plus parlant pour les industriels est celui de la
nomenclature. Tel qu’évoqué dans la définition d’une
structure produit, on trouve souvent une nomenclature par
métier. La réconciliation des différentes nomenclatures est une
activité chronophage. Si on regarde les nomenclatures comme
étant chacune un produit différent, toutes les nomenclatures
pourraient être mises à jour automatiquement des changements
effectués en conception.
De telles fonctionnalités nécessitent une grande agilité avec
les données produit, il faut notamment être capable de tracer
chaque utilisation d’une pièce ou d’un assemblage quel que
soit le référentiel.
Table des matières :
1. Introduction ........................................................................................1
1.1. Qu’est-ce-que l’effet tunnel ? .......................................................1
1.2 Pourquoi réutiliser des données d’un produit dans un autre
produit ? ..............................................................................................2
3. La problématique de l’instance relative ...............................................4
4. Quels éditeurs offrent des solutions à la problématique de l’instance
relative ? .................................................................................................7
4.1. Dassault .......................................................................................7
4.2. PTC ..............................................................................................7
4.3. Siemens ........................................................................................8
5. Solution développée ............................................................................9
5.1. Nouveauté ....................................................................................9
5.2. On ne peut pas réutiliser un cas d’usage .......................................9
5.3. Réutilisation d’un assemblage dans un autre produit ....................9
5.4. Réutilisation de données trans-assemblages dans un autre produit9
5.5. Dérivation d’un assemblage .......................................................10
5.6. Modélisation de la solution ........................................................10
6. Implémentation dans Aras Innovator.................................................13
6.1. Intégration du modèle dans la solution standard .........................13
6.3. Les relations ...............................................................................15
Conclusion ............................................................................................18
Références ............................................................................................19
2
2. Définitions
Assemblage
Un assemblage est un ensemble de produits. Les produits qui
composent un assemblage sont réunis en suivant une certaine
logique, cette logique peut être différente suivant le besoin
métier (cf. structure produit).
Produit
Un produit peut être un produit tangible, un produit
commercial, un assemblage, une pièce, un composant, une
usine, un atelier ou un outil. Un produit père est le contexte
d’utilisation d’un produit enfant (cf. instance). Un sous-
produit est un produit enfant. Le produit tangible ou produit
matériel est ce qui est livré au client. Le produit commercial
est le produit tangible accompagné des services.
Produit étendu
Le produit étendu est tout ce qui concourt à la valeur perçue
du produit. Le produit étendu inclut ainsi potentiellement le
produit tangible, le moyen de production, les services et les
add-ons [5]. Le moyen de production est l’usine ou les
installations où l’on va fabriquer le produit. Les services sont
par exemple la maintenance, la surveillance, la transmission
d’informations personnalisées en fonction de l’état ou de la
localisation du produit, etc. Les add-ons sont les évolutions,
améliorations, ajouts, remplacements de pièces obsolètes
contractés après la vente.
Structure produit
La structure produit, aussi appelée nomenclature ou BOM (bill
of materials), est une décomposition hiérarchique d’un
produit. Elle énumère la quantité de matières premières,
assemblages, pièces et composants nécessaires pour fabriquer
un produit. On peut organiser la structure produit selon le
besoin métier. C’est pourquoi il est courant d’en avoir
différentes représentations au cours du cycle de vie d’un
produit: la nomenclature de conception (engineering bill of
materials ou eBOM) est généralement différente de la
nomenclature de fabrication (manufacturing bill of materials
ou mBOM) et de la nomenclature de service (service bill of
materials ou sBOM). On peut créer autant de nomenclatures
que nécessaire.
Dans le présent document les mots « contexte » et
« référentiel » ont la même signification. Dans les diagrammes
du présent document le référentiel absolu est représenté par un
objet « root ».
Instance
L’instance est le cas d’utilisation d’un composant dans une
structure produit. Au niveau des données, les composants sont
représentés par des objets qui contiennent ou pointent vers les
informations qui les définissent (BOM, modèle 3D, version,
etc.). Une instance est le lien de structure hiérarchique entre
deux produits parent et enfant, par exemple entre une pièce et
son assemblage. La position d’un produit est portée par le lien
d’instance. Le lien d’instance peut aussi porter des
informations telles que la quantité, des propriétés graphiques,
des notes ou toute autre information utile au métier. Une
instance est relative quand elle est définie dans un référentiel
relatif, absolue quand elle est définie dans référentiel absolu.
Dans le présent document les expressions « instance »,
« agrégation », « usage », « cas d’usage », « utilisation » et
« cas d’utilisation » ont la même signification. Les expressions
« agréger dans », « utiliser dans », « instancier dans » et
« définir une instance dans » ont la même signification.
Occurrence
L’occurrence, dans le présent document, est l’équivalent de
l’instance absolue (cf. instance). Une instance peut avoir
plusieurs occurrences (3). Le terme occurrence n’a en
revanche pas la même signification d’un éditeur PLM/CAO à
l’autre. La signification du terme chez chaque éditeur sera
expliquée lors de la description des solutions techniques du
marché (4).

Référentiel
Un référentiel est un ensemble de points par rapport auquel on
repère une position ou un mouvement au moyen d’un système
de coordonnées. On distingue entre les référentiels relatif et
absolu. Le référentiel absolu est fixe, c’est le référentiel
principal. Dans CATIA on l’appelle le système d'axes absolu.
Le référentiel absolu contient idéalement le modèle 3D
complet du produit tangible (cf. produit), dans le cas d’un
avion le point d’origine est généralement situé devant le nez
de l’avion. Un référentiel relatif est défini par rapport au
référentiel absolu. Dans CATIA on l’appelle le système d’axes
local. Quand on créé un assemblage il est courant de créer un
référentiel relatif propre à cet assemblage afin de positionner
les pièces plus facilement.

3
3. La problématique de l’instance relative

Les illustrations qui suivent s’inspirent de la norme UML [6].

Les carrés et les rectangles représentent les objets. La ligne se
terminant par un losange est une relation d’agrégation. Cette
relation représente l’instance, le produit père est toujours du
côté du losange. La ligne en pointillés sert à relier la relation
d’agrégation à une classe d’association pour fournir des
informations supplémentaires sur la relation.

Une limitation fondamentale liée à la représentation des

données limite notre agilité avec les données produit. C’est la
notion d’instance relative. Figure 3

Une pièce P est représentée par un objet auquel sont attachées Cette façon de représenter les données ne permet pas de tracer
les données qui la définissent : nom, numéro, version, modèle chaque occurrence de l’utilisation d’une pièce ou d’un
3D, etc. (figure 1). assemblage sauf si l’utilisateur identifie ou définit chaque
occurrence de P.

1. Définir : on peut créer autant de cas d’usage de P

qu’il n’y a d’occurrences de P, dans ce cas le contexte de
définition de l’usage de P ne peut plus être A sinon on
aurait un assemblage A avec 3 instances de P et donc 9
occurrences de P (figure 4).

Figure 1

Pour utiliser la pièce P dans un assemblage A on ne duplique

pas l’objet et toutes ses données. On créé un objet de type lien
entre l’objet représentant la pièce P et l’objet représentant
l’assemblage A (figure 2). Ce lien, appelé instance, exprime
une relation hiérarchique d’usage entre l’assemblage A
(parent) et la pièce P (enfant). On dit que P est utilisé dans le
contexte de A. C’est à cet objet que l’on va attacher les
informations de positionnement de la pièce P dans
l’assemblage A (figure 2).

Figure 4

Une première solution serait de définir les cas d’usage

de P directement dans le référentiel absolu (figure 5a).

Figure 2

Notez que le cas d’usage de P dans A est unique même si A

est utilisé plusieurs fois. Autrement dit l’usage de P est défini
dans A. Si A est un référentiel relatif, l’usage de P est une
instance relative. Quand on utilise A dans 3 autres
assemblages M, N et O, 3 liens sont créés (figure 3). Si l’on
modifie la position de P dans A, tous les assemblages utilisant
Figure 5a
A sont impactés (figure 3).

4
 L’autre solution consiste à définir un cas d’usage de P
dans chaque contexte où A est utilisé (figure 5b). Par
conséquent l’assemblage A est inutile puisqu’il ne
contient pas de pièce.
Figure 5b
2. Identifier : ou alors on peut préciser le chemin de
chaque occurrence de P dans A (figure 3) :
P dans A dans M
P dans A dans N
P dans A dans O
Pour différencier chaque occurrence de l’usage de P il faut
donc : soit les définir chacune dans un contexte qui permette
cette identification unique, soit préciser le chemin de chaque
occurrence depuis un contexte qui permet cette identification
unique. Par exemple, si M est utilisé plusieurs fois, le contexte
de M ne permettra plus l’identification unique de chaque
occurrence de P (figure 6).
Figure 6
On pourra alors préciser le chemin de chaque occurrence de P
dans M :
P dans M dans X
P dans M dans Y
On peut aussi préciser le chemin de chaque occurrence de P :
P dans M dans X
P dans M dans Y
P dans N dans Y
P dans O dans Y
Revenons à l’exemple de la figure 5, si chaque usage de P est
différent cela signifie que P n’est pas défini dans A mais plus
haut dans la structure, donc on ne peut plus modifier la
définition de P dans A ni par conséquent déployer
automatiquement un changement de P dans A à tous les cas
d’usage de A comme on pouvait le faire dans l’exemple de la
figure 3. On paye ainsi le prix de la traçabilité.
Si l’on n’est pas capable de tracer chaque utilisation d’une
pièce au sein d’un seul produit sans perdre la fonctionnalité la
plus évidente apportée par la notion d’instance, quid d’un
environnement multi-produit ?
Le dilemme est donc le suivant : soit on différencie chaque
occurrence du cas d’usage de P dans A et donc la traçabilité
est complète dans le sens où on identifie chaque occurrence de
façon unique (figure 5), soit on conserve la possibilité de
modifier chaque occurrence du cas d’usage de P dans A en
une seule opération (figure 3).
Admettons qu’on veuille sélectionner un ensemble
d’occurrences de cas d’usages de pièces P et Q définis dans
différents assemblages M, N et O dont certains sont utilisés
plusieurs fois : on a besoin d’identifier chaque occurrence de
façon unique car certaines occurrences pourraient
correspondre à la même instance (figure 7).
Figure 7
Occurrences qui correspondent à l’instance de P dans M :
P dans M dans X
P dans M dans Y
Occurrences qui correspondent à l’instance de P dans N :
P dans N dans Y
P dans N dans Z
5
Occurrences qui correspondent à l’instance de Q dans N :
Q dans N dans Y
Q dans N dans Z

L’instance de Q dans O n’a qu’une occurrence :

Q dans O dans Z

Les occurrences de la sélection sont les suivantes :

P dans M dans X
P dans N dans Y
Q dans N dans Z

Pour positionner cette sélection dans le modèle 3D du moyen

de production il existe deux solutions : positionner chaque
occurrence séparément ou positionner la sélection en tant
qu’ensemble constituant son propre référentiel.

Dans le premier cas chaque occurrence sera redéfinie dans le

contexte C du moyen de production et donc le déplacement
d’une occurrence dans le produit n’aura pas d’impact sur
l’occurrence correspondante dans le moyen de production :

P dans M dans X devient P dans C

P dans N dans Y devient P dans C
Q dans N dans Z devient Q dans C

Dans le deuxième cas chaque occurrence sera redéfinie dans le

contexte de l’ensemble E et donc le déplacement d’une
occurrence dans le produit n’aura pas d’impact sur
l’occurrence correspondante dans l’ensemble, que l’ensemble
soit ou non positionné dans le moyen de production :

P dans M dans X devient P dans E

P dans N dans Y devient P dans E
Q dans N dans Z devient Q dans E

La structuration des données au seul moyen d’instances

relatives ne permet donc pas d’offrir les fonctionnalités
décrites en introduction (1.2).

6
4. Quels éditeurs offrent des solutions à la problématique
de l’instance relative ?

Les éditeurs de solutions PLM et CAO utilisent souvent

l’exemple de la nomenclature d’une voiture pour valoriser les
fonctionnalités de leurs solutions. Cette nomenclature utilise
quatre roues et deux axes. La roue et l’essieu sont définis
chacun une fois en tant que pièce. Il y a deux possibilités de
structuration des données :

i) création d’un assemblage essieu qui utilise un axe et deux

roues puis création de deux instances de l’assemblage essieu.
Avec les produits Dassault Systèmes il est possible de
positionner les roues différemment dans chaque instance de
l’assemblage essieu alors que les instances droite et gauche de
la roue n’ont été définies qu’une fois dans l’assemblage essieu
(4.1).
ii) création de deux instances de l’axe et de quatre instances de
la roue. Chez PTC il est possible de donner des positions et
des noms différents à chaque instance (4.2).
Figure 9
Chez Dassault, l’occurrence est donc le lien entre une
référence et l’instance de sa référence parent. Une instance
peut avoir plusieurs occurrences. L’occurrence permet de
remplacer les propriétés graphiques et de position de
l’instance.
Le modèle occurrence de Dassault permet ainsi de répondre à
la problématique de l’instance relative lorsque la structure
produit n’a pas plus de deux degrés.

4.1. Dassault
Par exemple, chez Dassault systèmes, on a le modèle
instance/référence : un composant est représenté par une
référence, le cas d’usage d’un composant est représenté par
une instance (figure 8). Une instance est donc un lien de
structure hiérarchique entre deux références parent et enfant.
4.2. PTC
Dans la solution Windchill de chez PTC la relation d’usage est
le lien de structure hiérarchique entre deux pièces parent et
enfant tandis que l’occurrence porte l’information à propos
d’un usage nommé d’une pièce dans un assemblage. La
quantité est portée par la relation d’usage. La position est
portée par l’occurrence (figure 10).

Figure 8

Tel qu’il est expliqué plus haut (3), avec le modèle Figure 10

instance/référence, on ne peut pas garantir l’identification

On ne peut pas définir des occurrences dans le contexte de son
unique de chaque occurrence de l’usage d’une référence sauf
choix, on est restreint à l’assemblage parent immédiat. Par
en précisant le chemin de chaque occurrence depuis un
conséquent la fonctionnalité Windchill de création
contexte qui permet cette identification.
d’occurrences n’apporte pas de solution à la problématique de
l’instance relative.
Le modèle occurrence est en quelque sorte une vue repliée du
modèle instance/référence. Une occurrence représente le
Une particularité intéressante de Windchill est qu’il y a deux
chemin d’une instance, sans afficher la référence intermédiaire
types de relations d’usage : uses et used by, cela permet de
(figure 9). Cette fonctionnalité a fait l’objet d’une demande de
parcourir la relation parent-enfant dans les deux sens, selon le
brevet européen [7].
besoin. Par exemple, suivre la relation used by d’une pièce
enfant à une pièce parent permet de facilement analyser
l’impact d’un changement de design.

7
 L’occurrence absolue est utile lorsque l’on souhaite
différencier un usage en fonction d’un contexte particulier
4.3. Siemens (position différente des roues sur l’essieu avant, cf. 4.1).

Chez Siemens une occurrence ou occurrence relative est un L’instance est utile pour l’identification unique, le chemin
lien de structure hiérarchique entre un assemblage parent complet vers le référentiel absolu est associé à l’instance.
immédiat et son composant enfant (figure 11). Une occurrence
absolue est une relation entre un assemblage parent et un
composant situé un ou plusieurs niveaux plus bas dans la
structure (figure 11). L’assemblage parent est le contexte dans
lequel existe l’occurrence absolue.

Figure 11

Les données de l’occurrence relative peuvent être remplacées

par des données de l’occurrence absolue. Chaque occurrence
absolue peut avoir un ou plusieurs attributs uniques qui la
distinguent des autres occurrences absolues dérivées de la
même occurrence relative [8].

On voit bien que seule Siemens apporte une réponse à la

problématique de l’instance relative. L’utilisateur peut définir
des cas d’usage dans le contexte de son choix et ainsi
différencier les occurrences du cas d’usage de P dans A sans
avoir à en préciser le chemin jusqu’à un contexte qui permette
cette identification.

La société Siemens a très tôt adressé les questions de

traçabilité entre les différentes représentations de la structure
produit, certains travaux ont fait l’objet de brevets US [9][10].

En réalité Siemens utilise trois concepts : l’occurrence

(correspond à mon instance relative), l’occurrence absolue
(correspond à mon instance absolue à condition qu’elle soit
définie dans le référentiel absolu) et l’instance (correspond à
mon instance absolue).

L’occurrence est utile lorsqu’on ne souhaite pas différencier

chaque usage en fonction d’un contexte particulier (donc un
changement de P dans A est déployé automatiquement à tous
les cas d’usage de A).

8
5. Solution développée
La solution développée s’appuie sur la notion d’instance
absolue. Pour chaque instance relative, une ou plusieurs
instances absolues correspondantes sont créées
automatiquement. De cette façon, on est capable d’identifier
de façon unique chaque occurrence d’un cas d’usage à tout
moment et sans calcul supplémentaire. La création
automatique des instances absolues permet ainsi la
réutilisation de données d’un produit dans un autre produit de
deux manières :
i) la création de contextes, donnée autonome qui s’appuie sur
des instances absolues (5.4) ;
ii) la création de produit dérivés, donnée autonome qui
s’appuie sur des instances relatives (5.5).
5.1. Nouveauté
En ce qui concerne les instances absolues, l’apport de la
solution développée concerne notamment le fait que les
instances absolues correspondantes sont systématiquement
créées pour chaque cas d’usage. Ainsi, premièrement on n’a
pas besoin de chercher le chemin d’une instance lorsqu’on
souhaite le connaître, deuxièmement on n’a pas besoin de
calculer la position absolue d’une instance lorsqu’on souhaite
la connaître.
Ce deuxième aspect est de nature à économiser beaucoup de
ressources de calcul. En effet pour connaître la position
absolue d’une instance dans une structure produit il faut passer
par autant de changements de repères qu’il n’y a de degrés
dans la structure au-dessus de ladite instance.
La nouveauté se trouve dans les deux points suivants :
D’une part, la création systématique des instances absolues
permet la sélection de données produit, peu importe si les
données sélectionnées font partie d’un ou plusieurs
assemblages distincts.
D’autre part les données sélectionnées sont rendues
autonomes. C’est-à-dire qu’elles resteront les mêmes quel que
soit le contexte où elles sont réutilisées.
5.2. On ne peut pas réutiliser un cas d’usage
Pour pouvoir utiliser des données d’un produit dans un autre
produit sans en perdre la traçabilité, chaque cas d’usage d’un
composant doit pouvoir être « réutilisé » dans un référentiel
R2 sans perdre les informations qui définissent sa position
dans le référentiel R1.
Cependant on ne peut pas réutiliser un cas d’usage car c’est
sur cet objet que sont portées les informations de
positionnement dans le référentiel R1. Les informations de
positionnement seraient donc écrasées en cas de
positionnement dans R2 (voir exemple sous la figure 7).
Réutiliser un cas d’usage revient donc à créer un nouveau cas
d’usage correspondant. Cependant pour des raisons pratiques
l’expression « réutiliser un cas d’usage » est parfois employée
dans le présent document. Pour être rigoureux il faudrait dire :
« définir dans un référentiel R2 un cas d’usage correspondant
à un cas d’usage défini dans un référentiel R1 ». On peut
réutiliser un assemblage A ou une pièce P mais on ne peut pas
réutiliser un cas d’usage de A ou de P.
5.3. Réutilisation d’un assemblage dans un autre produit
La réutilisation d’un assemblage ne pose pas de problème
particulier dans les outils actuels, cependant la question de la
conservation du lien avec l’usage original a déjà fait l’objet de
travaux [11].
Pour pouvoir réutiliser dans un référentiel R2 un assemblage
A utilisé dans un référentiel R1 il suffit de définir un cas
d’usage de A dans R2. Le concepteur peut déplacer les pièces
utilisées dans A, les deux cas d’usage de A seront impactés.
5.4. Réutilisation de données trans-assemblages dans un
autre produit
Avant de réutiliser des données relatives à plusieurs
assemblages il faut d’abord les sélectionner. Pour pouvoir
réaliser des sélections on utilise les instances absolues, seul
moyen direct d’identification unique (3).
De cette façon on connaît d’une part la position de l’instance
relative, c’est-à-dire la position de la pièce dans son référentiel
local ou relatif. D’autre part on connaît la position de
l’instance absolue, c’est-à-dire la position de la pièce dans le
référentiel absolu.
Par exemple, je cherche toutes les instances situées dans une
sphère de rayon 1 mètre autour d’un certain point défini dans
un référentiel absolu R1.
Pour que ma recherche donne un résultat correct il faut que les
instances soient définies dans R1. Les sélections spatiales sont
alors très faciles à réaliser puisqu’il suffit d’une requête qui va
rechercher dans la base de données les positions absolues
situées dans la sphère.
Une fois la sélection réalisée on la transforme en une donnée
autonome qu’on peut réutiliser dans n’importe quel référentiel.
Comment transformer la sélection en donnée autonome ? En
créant, dans un contexte C de matrice nulle, les instances qui
correspondent aux instances absolues situées dans la sphère.
9
Mais ce n’est pas suffisant, il faut que la position des instances
définies dans le contexte C dépende de la position des
instances qui ont été en tout premier lieu définies dans leurs
assemblages respectifs.
Récapitulons :
i) Création manuelle d’instances dans des assemblages
ii) Un programme se charge de la création automatique des
instances absolues correspondantes
iii) Sélection d’instances absolues
iv) Création manuelle, dans un contexte C de matrice nulle, de
nouvelles instances correspondant aux instances absolues de la
sélection
v) Un programme se charge du repositionnement automatique
des instances du contexte C quand la position des instances
absolues correspondantes est modifiée
Notez que les instances définies dans C ont la même position
absolue que celles définies R1 et que celles définies dans leurs
assemblages respectifs.
Il suffit alors d’utiliser C dans un autre contexte. Toute
modification des instances définies dans leurs assemblages
respectifs sera répercutée sur les instances définies dans C, où
qu’il soit utilisé.
Le contexte C est une donnée autonome car sa définition
dépend des contextes dans lesquels les éléments regroupés
dans C ont été préalablement définis. Même raisonnement
pour les instances absolues définies dans R1, leur position
dépend de celle des instances relatives correspondantes.
5.5. Dérivation d’un assemblage
Tel qu’introduit plus haut, lors de la conception d’un produit
B, il est courant de réutiliser des données issues d’un produit
A. Admettons qu’un assemblage X du produit A ait causé
beaucoup de tracas à ses concepteurs en termes de conformité,
certifications, industrialisation, etc. La nouvelle version de X
dans le produit B diffère quelque peu, on voudrait être capable
de dériver de la première version sans avoir à répéter le
difficile processus qu’ont connu ses concepteurs.
L’idée est de conserver tout ce dont on a besoin de
l’assemblage X afin de se concentrer sur ce qui diffère avec la
nouvelle version. Par exemple la première version de X
contient P1, P2 et P3, la nouvelle version contient P1, P2 et
P4. On veut une dérivée de X qui ne contient que P1 et P2 afin
de ne travailler que sur P4.
La solution est simple : on créé une dérivée de X en créant de
nouveaux liens de P1 et P2 à un produit dérivé dX dont la
définition dépend de celle de X. C’est-à-dire qu’on instancie
P1 et P2 dans dX mais la position de P1 et P2 dans dX dépend
la position de P1 et P2 dans X. Si P1 est déplacé dans X, P1 se
déplace de la même manière dans dX.
Le produit dérivé dX est une donnée autonome car sa
définition dépend de la définition de X, peu importe le
contexte où dX est utilisé. Ce comportement nécessite
évidemment quelques lignes de code (6.2).
5.6. Modélisation de la solution
Pour pouvoir répondre aux fonctionnalités définies plus haut
(5.4, 5.5), on a besoin d’un modèle conceptuel de données
avec lequel on puisse gérer à la fois les données d’un produit
tangible, d’un moyen de production, des services et des add-
ons (figure 12).
Les classes :
La classe item est une classe abstraite qui peut se spécialiser
en leaf_item et items_aggregation.
La classe items_aggregation est une classe abstraite qui peut
se spécialiser en context, Assembly, derived_product et
root_product.
La classe context sert à la création de contextes (5.4).
La classe Assembly sert à la création d’assemblages, un
assemblage peut être un ensemble de pièces, un produit
commercial, une usine, un atelier voire un outil.
La classe derived_product sert à la création de produits
dérivés (5.5).
La classe leaf_item sert à la création de pièces, composants
voire outils qu’on ne peut pas ou qu’on ne veut pas
décomposer davantage.
La classe root_product sert à la création de référentiels
absolus (cf. référentiel), cette classe ne sera pas implémentée
(6), elle représente un assemblage constituant un référentiel
absolu. Toute référence, dans le présent document, à un objet
de type root_product doit être vue comme une référence à
un assemblage dans le contexte duquel ont été définies des
instances absolues. Dans l’exemple de la figure 16 (6), N et
Root sont des référentiels absolus, Root étant le plus haut de la
structure.
La classe d’association absolute_instance décrit le lien
d’agrégation entre un item et un root_product.
La classe d’association relative_instance décrit le lien
d’agrégation entre un item et un items_aggregation.
Les héritages et agrégations :
Toutes les classes qui héritent d’item peuvent êtres agrégées
dans un root_product. Toutes les classes qui héritent
d’items_aggregation peuvent êtres agrégées dans un
root_product puisque items_aggregation hérite d’item.
10
 Figure 12
Le lien d’agrégation entre item et root_product signifie
que tout cas d’usage, dans le référentiel absolu, d’une classe
qui hérite directement ou non d’item, est une instance
absolue.
Toutes les classes qui héritent d’item peuvent s’agréger dans
les classes qui héritent d’items_aggregation. Comme
items_aggregation hérite d’item alors toutes les classes qui
héritent d’items_aggregation peuvent s’agréger elles-
mêmes.
Le lien d’agrégation entre item et items_aggregation
signifie que tout cas d’usage, dans une classe qui hérite
d’items_aggregation, d’une classe qui hérite directement
ou non d’item, est une instance relative.
L’agrégation d’un context dans un assemblage ou produit
dérivé n’est pas nécessaire, l’objet context sert à grouper des
instances absolues afin de les « réutiliser » dans un autre
référentiel.
Les cardinalités sont permissives puisqu’il n’y a pas lieu ni
d’imposer un minimum ni de limiter le nombre d’objets
agrégés.
Les méthodes :
CreateDerivedProduct() est la méthode qui permet de
créer un produit dérivé à partir d’un assemblage. On veut
pouvoir sélectionner les composants de l’assemblage à
enlever, ce qui donnera la fonction de dérivation (cf.
derivation_function).
CreateAbsoluteInstance() créé la ou les instance(s)
absolue(s) correspondant à une instance relative lors de la
création de cette instance relative.
DeleteAbsoluteInstance() supprime la ou les instance(s)
absolue(s) correspondant à une instance relative lors de la
suppression de cette instance relative.
UpdateDerivedProduct() est la méthode qui met à jour le
produit dérivé lorsque les instances relatives de l’assemblage
primitif sont modifiées.
UpdateInContext() est la méthode qui met à jour le
contexte lorsque les instances relatives correspondantes sont
modifiées.
Les attributs :
is_derived_from pointe vers l’assemblage primitif.
derivation_function est la fonction de dérivation de
l’assemblage primitif, c’est-à-dire l’opération par laquelle on
obtient la dérivée d’un assemblage. Il s’agit d’une chaîne de
caractères énumérant les numéros d’instances
(rel_inst_num) de premier niveau à exclure de la dérivée, le
caractère servant de séparateur sera déterminé lors de
l’implémentation.
11
absolute_instance_type est le type d’instance absolue,
cet attribut indique la classe du produit parent et la classe du
produit enfant. Cet attribut ne sera pas implémenté car il y
aura une classe par type de lien (6).
abs_inst_num est le numéro de l’instance absolue, il est
composé du numéro de l’instance relative correspondante
auquel est ajouté un compteur incrémenté à chaque occurrence
de l’instance relative (une instance relative peut avoir une ou
plusieurs instances absolues correspondantes).
corresponds_to pointe vers l’instance relative
correspondante.
corresponding_abs permet de tracer quelles instances
absolues sont créées lors de l’instanciation d’un assemblage.
En effet chaque assemblage constitue son propre référentiel
absolu. Lors de l’instanciation de cet assemblage, la méthode
CreateAbsoluteInstance()créé au moins une instance
absolue pour chaque instance absolue dont l’assemblage est le
père. L’attribut corresponding_abs pointe vers la ou les
instances absolues correspondantes. Cela permet de savoir, en
combinaison avec l’attribut definition_context, quelles
instances absolues ont été créées lors de l’instanciation d’un
assemblage. La méthode DeleteAbsoluteInstance() peut
alors trouver quelles instances absolues elle doit supprimer en
cas de suppression d’une instance d’un assemblage. Une
instance absolue dont l’attribut corresponding_abs n’est
pas renseigné est soit une instance absolue créée lors de
l’instanciation d’un leaf_item, soit une instance absolue
d’un assemblage.
5.7. Limitations
La présente solution implique de partir de zéro en l’absence
d’un algorithme récursif capable de créer toutes les instances
absolues correspondant aux instances relatives d’une structure
produit.
Plus simplement, dès qu’un produit parent n’a pas de parent
on considère que c’est le référentiel absolu. De cette manière
les sous-produits instanciés dans un produit sont toujours
définis dans le référentiel du produit avec des instances
absolues (figure 16).
Pour instancier un produit qui contient des sous-produits il
suffit alors de chercher toutes les instances absolues dont ce
produit est le père puis de créer les instances absolues
correspondantes dans le nouveau référentiel.
Si plusieurs référentiels absolus existent dans la structure
produit, les instances absolues sont créées dans tous ces
référentiels.
En ce qui concerne la reprise de données, pour pouvoir
importer automatiquement et rendre conformes à la présente
solution des structures produit construites dans d’autres
systèmes, l’algorithme récursif évoqué plus haut est
indispensable.

definition_context pointe sur une instance absolue

correspondant à l’instance relative dont la création a déclenché
la création de l’instance absolue qui contient cet attribut. Cet
attribut permet de tracer les instances absolues. Une instance
absolue dont l’attribut definition_context n’est pas
renseigné a forcément été définie dans un assemblage qui
n’était pas encore instancié.

abs_position_matrix est la matrice de positionnement de

l’instance absolue, il est possible de l’implémenter soit en tant
que chaîne de caractères regroupant toutes les coordonnées
soit avec un attribut de type entier par coordonnée.

relative_instance_type est le type d’instance relative,

cet attribut indique la classe du produit parent et la classe du
produit enfant. Cet attribut ne sera pas implémenté car il y
aura une classe par type de lien (6).

rel_inst_num est le numéro de l’instance relative, il est

composé du numéro de la pièce instanciée auquel est ajouté un
compteur incrémenté à chaque instanciation de la pièce.

rel_position_matrix est la matrice de positionnement de

l’instance relative, il est possible de l’implémenter soit en tant
que chaîne de caractères regroupant toutes les coordonnées
soit avec une coordonnée par attribut de type entier.

12
6. Implémentation dans Aras Innovator
Le modèle de données décrit ci-dessus ne peut
malheureusement pas être implémenté tel quel dans Aras
Innovator. En effet, ce modèle contient plusieurs héritages.
Aras Innovator offre une fonctionnalité proche de l’héritage :
les poly Items. Un poly Item est un objet qui peut prendre
plusieurs formes, comme c’est le cas pour l’objet item du
modèle conceptuel (figure 12). Cependant dans Aras les
différentes formes (poly sources) que peut prendre un objet
n’héritent ni des propriétés, ni des liens que peut avoir le poly
Item.
Par conséquent pour pouvoir implémenter le modèle de la
figure 12 il faut créer un type de lien différent entre chaque
type d’objets. On a ainsi 5 types d’instances relatives, 3 types
d’instances dans le contexte et 3 types d’instances absolues
(figure 14). Les classes item et items_aggregation ont été
exclues du modèle d’implémentation pour la même raison.
6.1. Intégration du modèle dans la solution standard
Aras Innovator contient déjà un modèle de données permettant
de manipuler les objets métier auxquels nous nous intéressons
dans le présent document. La figure 15 donne un aperçu de la
solution standard.
Figure 15
Dans Aras, tout est un Item. Un Item est une instance d’un
ItemType. Un ItemType est un Item. Les Items peuvent avoir
des relations vers d’autres Items. Les relations sont aussi des
Items avec des propriétés indiquant le parent et l’enfant.
Toutes les classes de la figure 15 sont des ItemTypes sauf
Assembly, Component et Material qui sont des sous-types
de Part. L’ennui avec la fonctionnalité de classification
d’Aras est qu’il n’est pas possible de de créer des relations
spécifiques à des sous-types. Ainsi, avec la solution standard,
on ne peut pas créer de lien entre Assembly et un autre objet.
L’objet Part de la solution standard est l’équivalent à la fois
des objets LeafProduct et Assembly du modèle
d’implémentation.
Les objets Part BOM et BOM Instance sont l’équivalent des
objets AssyInst et LPinstInAssy du modèle
d’implémentation. Part BOM indique la quantité, BOM
Instance porte la position, comme dans Windchill (4.2).
La question est comment faire pour implémenter notre modèle
sans perdre les fonctionnalités standard d’Aras ? Tous les
objets qui sont reliés à Part dans la solution standard devront
être reliés aux objets de notre modèle.
Par exemple la relation entre Part et Document deviendra une
relation entre LeafProduct et Document et une relation entre
Assembly et Document.
Pour d’autres objets tels que DerivedProduct la question de
l’intégration n’est pas toujours évidente. Cela dépendra du
besoin de celui qui implémentera le modèle.
La politique d’Aras en matière de customisations est très
permissive puisque la compagnie s’engage à supporter les
mises à jour peu importe le degré de customisation, sauf
modification des fichiers source. Le remplacement de l’objet
Part de la solution standard n’est pas un hack mais bien une
customisation qui ne dispensera pas Aras d’exécuter ses
obligations dans le cadre du contrat de support
6.2. Les classes
Les algorithmes décrits dans cette section peuvent être
directement implémentés dans Aras Innovator au moyen des
méthodes des classes Innovator et Item.
Assembly :
La classe Assembly sert à la création d’assemblages, un
assemblage peut être un ensemble de pièces, un produit
tangible, une usine, un atelier ou encore un outil.
Notez que la classe Assembly est décrite deux fois dans la
figure 14. Cela permet de représenter les instances absolues et
les instances relatives. La classe Assembly située en haut du
modèle d’implémentation (figure 14) est l’équivalent de la
classe root_product dans le modèle conceptuel (figure 12).
La méthode CreateDerivedProduct()permet de créer un
produit dérivé à partir d’un assemblage. Cette méthode doit
pouvoir être appelée d’un clic droit sur un Assembly. Pour
cela il faut insérer le code de la méthode depuis l’onglet
Actions de l’ItemType Assembly. La méthode doit déclencher
l’ouverture d’une fenêtre depuis laquelle l’utilisateur choisit
les instances de premier niveau à exclure de la dérivée.
13
 Figure 14
Algorithme : La méthode CreateDerivedProduct()créé un
objet de type derived_product dans lequel elle créé, pour
chaque instance de premier niveau définie dans la primitive et
qui n’a pas été sélectionnée comme étant à enlever, l’instance
correspondante dans le produit dérivé créé et renseigne
l’attribut corresponds_to. La position des instances dans le
produit dérivé sera la même que la position des instances dans
l’assemblage primitif.
DerivedProduct :
La classe DerivedProduct sert à la création de produits
dérivés.
L’attribut is_derived_from doit pointer vers l’assemblage
primitif, cet attribut est renseigné par la méthode
CreateDerivedProduct() lors de la création d’un
DerivedProduct.
L’attribut derivation_function est la fonction de
dérivation de l’assemblage primitif, cet attribut est renseigné
par la méthode CreateDerivedProduct() lors de la
création d’un DerivedProduct, c’est la liste des instances de
premier niveau qui ont été sélectionnées comme étant à
exclure.
L’attribut corresponds_to pointe sur l’instance
correspondante dans l’assemblage primitif.
LeafProduct :
La classe LeafProduct sert à la création de pièces,
composants voire outils qu’on ne peut pas ou qu’on ne veut
pas décomposer davantage.
Context :
La classe Context sert à la création de contextes (5.4). Un
contexte a toujours une matrice de transformation nulle avant
d’être réutilisé, les relations avec DerivedProduct,
Assembly et LeafProduct s’apparentent ainsi à des
instances absolues.
Dans le cadre des recherches précédant la rédaction du présent
document, aucun logiciel de CAO n’a été connecté à Aras
14
Innovator. Par conséquent l’intégration de la fonctionnalité de DPinstInCtxt est l’instance d’un DerivedProduct dans un
création de contexte est limitée. C’est pourquoi on autorise Context.
l’utilisateur à créer un contexte depuis la TOC (Table Of
Contents). Juste avant la création (onBeforeAdd), la méthode AssyInstInCtxt est l’instance d’un Assembly dans un
CreateContext() déclenche l’ouverture d’une fenêtre qui Context.
permet de choisir des instances absolues en fonction
d’attributs tels que la position (abs_position_matrix) ou le LPinstInCtxt est l’instance d’un LeafProduct dans un
numéro (abs_inst_num). D’autres critères de sélection Context.
comme le produit parent ou enfant sont également possibles.

Pour chaque instance absolue sélectionnée la méthode crée
une instance dans le contexte. C’est-à-dire qu’une relation est
créée entre le contexte et le produit fils de l’instance absolue,
et ce pour chaque instance absolue. Aucune transformation
n’est effectuée puisque la matrice de l’objet Context est
nulle : les positions des instances dans le contexte sont les
mêmes que les positions des instances absolues.
6.3.3. Les instances dans un DerivedProduct
AssyInstInDP est l’instance d’un Assembly dans un
DerivedProduct.
LPinstInDP est l’instance d’un LeafProduct dans un
DerivedProduct.

Les attributs :
6.3. Les relations
L’attribut position_matrix indique la position de l’instance
Les algorithmes décrits dans cette section peuvent être (voir 5.6, rel_position_matrix).
directement implémentés dans Aras Innovator au moyen des
méthodes des classes Innovator et Item. L’attribut corresponds_to pointe sur l’instance relative
correspondante (voir 6.2 classe Assembly, méthode
CreateDerivedProduct()).
6.3.1. Les instances absolues :
Les méthodes :
Les trois types d’instances absolues décrits ci-dessous héritent
(au sens UML1) des attributs de la classe AbsoluteInstance
CreateAbsInstOfAssy() créé la ou les instance(s)
qui est un poly Item (6). L’utilité du poly Item ici est qu’une
absolue(s) correspondant à l’instance d’un produit dans un
recherche d’Items de type AbsoluteInstance permet de
DerivedProduct lors de la création de cette instance. Le
rechercher simultanément parmi les trois types d’instances
fonctionnement est similaire à celui de la méthode du même
absolues décrits ci-dessous, notamment dans le but d’effectuer
nom dans la classe AssyInst (voir 6.3.4 B).
des sélections. Les attributs ont déjà été décrits plus haut (5.6).

DeleteAbsInstOfAssy() supprime la ou les instance(s)

AbsInstOfDP est l’instance absolue d’un DerivedProduct.
absolue(s) correspondant à l’instance d’un produit dans un
DerivedProduct lors de la suppression de cette instance. Le
AbsInstOfAssy est l’instance absolue d’un Assembly.
fonctionnement est similaire à celui de la méthode du même
nom dans la classe AssyInst (voir 6.3.4 B).
AbsInstOfLP est l’instance absolue d’un LeafProduct.

UpdateAbsInstOfAssy() met à jour la ou les instance(s)

absolue(s) correspondant à l’instance d’un produit dans un
6.3.2. Les instances dans un Context
DerivedProduct lors de la modification de la valeur d’un
attribut de cette instance. Cette méthode a l’effet d’une
Les trois types d’instances absolues décrits ci-dessous héritent
suppression puis d’une recréation de la même instance.
des attributs de la classe InstanceInCtxt qui est un poly
Item (6). L’utilité du poly Item ici est qu’une recherche
d’Items de type InstanceInCtxt permet de rechercher
6.3.4. Les instances dans un Assembly
simultanément parmi les trois types d’instances dans un
Context. L’attribut position_matrix indique la position de
A. DPinstInAssy est l’instance d’un DerivedProduct
l’instance (voir 5.6, rel_position_matrix). L’attribut
dans un Assembly.
corresponds_to pointe sur l’instance absolue
correspondante.
La méthode CreateAbsInstOfDP() créé la ou les
instance(s) absolue(s) correspondant à l’instance relative d’un
1
Pour rester fidèle au fonctionnement d’Aras tel que décrit (6), DerivedProduct dans un Assembly lors de la création de
il aurait fallu recopier les attributs dans chaque type d’instance cette instance relative. Le fonctionnement est similaire à celui
absolue.

15
de la méthode CreateAbsInstOfAssy() dans la classe
AssyInst (voir 6.3.4 B).
La méthode DeleteAbsInstOfDP() supprime la ou les
instance(s) absolue(s) correspondant à l’instance relative d’un
DerivedProduct dans un Assembly lors de la suppression
de cette instance relative. Le fonctionnement est similaire à
celui de la méthode DeleteAbsInstOfAssy() dans la classe
AssyInst (voir 6.3.4 B).
La méthode UpdateAbsInstOfDP() met à jour la ou les
instance(s) absolue(s) correspondant à l’instance relative d’un
DerivedProduct dans un Assembly lors de la modification
de la valeur d’un attribut de cette instance relative. Cette
méthode a l’effet d’une suppression puis d’une recréation de la
même instance.
B. AssyInst est l’instance d’un Assembly dans un
Assembly.
Pour chaque instance absolue de O la méthode va créer
l’instance absolue de N et renseigner les attributs
corresponds_to (instance de N) et definition_context
(instance absolue de O). On connait la position de N dans O et
la position de O dans Root. La position de N dans Root est
calculée au moyen d’un changement de repère, du repère O au
repère Root.
Toujours pour chaque instance absolue de O, la méthode va
créer une instance absolue dans Root pour chaque instance
absolue dont N est le parent en renseignant les attributs
corresponding_abs (l’instance de J dans Root correspond à
l’instance de J dans N) et definition_context (instance
absolue de O). On connait la position de N dans Root et la
position de J dans N. La position de J dans Root est calculée
au moyen d’un changement de repère, du repère N au repère
Root, même chose pour chaque instance absolue dont N est le
père.

La méthode CreateAbsInstOfAssy() créé la ou les

instance(s) absolue(s) correspondant à l’instance relative d’un
Assembly dans un Assembly lors de la création de cette
instance relative.

Algorithme :

Si le produit père est le fils d’au moins une instance absolue :

{
Pour chaque instance absolue du produit père :
{
Créer l’instance absolue du produit fils
}
Pour chaque instance absolue du produit fils :
{
Pour chaque instance absolue dont le produit fils est le
parent (tout produit dans lequel des sous-produits ont
été instanciés avant l’instanciation de celui-ci est un
référentiel absolu) :
{
Créer une instance absolue
} Figure 16

}
}
DeleteAbsInstOfAssy() supprime la ou les instance(s)
Si le produit père n’est le fils d’aucune instance absolue (c’est-
à-dire qu’il n’a pas de parent) : absolue(s) correspondant à l’instance relative d’un Assembly
{ dans un Assembly lors de la suppression de cette instance
la méthode va donc créer l’instance absolue du produit relative.
fils, identique à l’instance relative, puis créer une instance
absolue pour chaque instance absolue dont le produit fils Algorithme :
est le parent.
} Si le produit fils a des sous-produits :
{
Pour illustrer (figure 16), créons une instance de N dans O (en Si le produit fils est le parent d’instances relatives qui
bleu). La méthode va d’abord rechercher les instances correspondent à des instances absolues dont il est le père
absolues de O (il pourrait y avoir une instance de O dans X ou (c’est-à-dire si le produit fils est root) :
dans K). {

16
 Si oui, pour chaque instance absolue du produit fils,
la méthode va supprimer les instances absolues dont
l’attribut definition_context pointe sur une
instance absolue du produit père ou sur une instance
absolue d’un parent d’une instance absolue du
produit père (il peut y avoir d’autres référentiels
absolus avant celui le plus haut) et dont l’attribut
corresponding_abs pointe sur les instances
absolues dont le produit fils est le parent
Puis supprimer la ou les instances absolues du
produit fils
Si non alors il faut avertir l’utilisateur qu’il ne peut
pas supprimer cette instance. En effet, on ne peut pas
supprimer un assemblage ou sous-assemblage qui
n’est pas root.
} UpdateAbsInstOfAssy() met à jour la ou les instance(s)
} absolue(s) correspondant à l’instance relative d’un Assembly
Si le produit fils n’a pas de sous-produits :
{ attribut de cette instance relative. Cette méthode a l’effet
La méthode va supprimer les instances absolues
correspondantes.
} UpdateAssyInDP() met à jour l’instance d’un Assembly
Pour illustrer (figure 16), supprimons l’instance de N dans O.
La méthode va d’abord supprimer chaque instance absolue
dont l’attribut definition_context pointe sur une instance
absolue de N ou sur une instance absolue d’un parent d’une
instance absolue de N et dont l’attribut corresponding_abs
pointe sur une instance absolue dont N est le père.
La méthode va ensuite supprimer les instances absolues dont
l’attribut corresponds_to pointe sur l’instance de N dans O
(instances absolues de N créées lors de l’instanciation de N
dans O).
Sans l’attribut definition_context la méthode
supprimerait aussi les instances absolues dans Root dont
l’attribut corresponding_abs pointe sur les instances
absolues dont N est le père mais qui ont été créées à l’occasion
de l’instanciation de N dans un autre produit (il pourrait y
avoir une instance de N dans X ou dans K).
On ne doit pas supprimer un assemblage auquel des pièces ont
été rajoutées alors qu’il était déjà instancié dans la structure
produit. La raison à cela est qu’on ne peut pas savoir quelles
instances absolues ont été créées à l’occasion du rajout des
dites pièces car leur contexte de création n’est pas le même
que le contexte de création des instances absolues de
l’assemblage. Donc si on supprime l’assemblage parent il va
rester des instances absolues orphelines. Pour les retrouver il
faut développer un algorithme récursif qui va rechercher les
instances absolues dont les enfants ne sont pas reliés à la
racine produit par un chemin d’instances relatives.
Pour autoriser cette fonctionnalité il faudrait que la méthode
de création des instances absolues récupère le contexte de
création des instances absolues du produit père et le recopie
dans les nouvelles instances créées en renseignant l’attribut
corresponding_abs. Cette fonctionnalité n’est pas
disponible pour le moment car elle pose des problèmes non
encore résolus faute de temps :
Pour reprendre l’exemple de la figure 16, instancions un
produit Z sous le produit J. Il faut aller chercher parmi les
instances absolues de J, laquelle est référencée par l’attribut
corresponding_abs des autres instances absolues de J et
recopier cette référence dans l’attribut corresponding_abs des
instances absolues de Z qui sont créées. Il faut aussi renseigner
l'attribut definition_context pour chaque instance absolue
de Z de façon à pouvoir supprimer l’instance de N sans laisser
d’instances absolues de Z orphelines.
dans un Assembly lors de la modification de la valeur d’un
d’une suppression puis d’une recréation de la même instance.
dans un DerivedProduct lors de la modification de la valeur
d’un attribut de l’instance relative correspondante dans
l’assemblage primitif. Cette méthode a l’effet d’une
suppression puis d’une recréation de la même instance.
C - LPinstInAssy est l’instance d’un LeafProduct dans
un Assembly.
La méthode CreateAbsInstOfLP() créé la ou les
instance(s) absolue(s) correspondant à l’instance relative d’un
LeafProduct dans un Assembly lors de la création de cette
instance relative. Le fonctionnement est similaire à celui de la
méthode CreateAbsInstOfAssy() dans la classe AssyInst
(voir 6.3.4 B).
La méthode DeleteAbsInstOfLP() supprime la ou les
instance(s) absolue(s) correspondant à l’instance relative d’un
LeafProduct dans un Assembly lors de la suppression de
cette instance relative. Le fonctionnement est similaire à celui
de la méthode DeleteAbsInstOfAssy() dans la classe
AssyInst (voir 6.3.4 B).
La méthode UpdateAbsInstOfLP() met à jour la ou les
instance(s) absolue(s) correspondant à l’instance relative d’un
LeafProduct dans un Assembly lors de la modification de la
valeur d’un attribut de cette instance relative. Cette méthode a
l’effet d’une suppression puis d’une recréation de la même
instance.
UpdateLPinDP() met à jour l’instance d’un LeafProduct
dans un DerivedProduct lors de la modification de la valeur
d’un attribut de l’instance relative correspondante dans
l’assemblage primitif. Cette méthode a l’effet d’une
suppression puis d’une recréation de la même instance.
17
Conclusion

On sait réutiliser des données d’un produit dans un autre

produit. On est capable de rendre ces données autonomes quel
que soit le référentiel de leur réutilisation. La création
systématique des instances absolues permet donc d’apporter
les fonctionnalités décrites (5). Cependant la gestion des
instances absolues n’est pas chose facile, des contraintes
supplémentaires s’imposent selon la manière de procéder (5.7
et 6.3.4). L’intégration du modèle dans la solution standard est
possible. Cependant une campagne de tests est recommandée
pour vérifier qu’aucune fonctionnalité standard n’est
endommagée (6.1).

18
Références

[1] John T. Boardman, Ben T. Clegg, (2001) "Structured engagement in the extended enterprise", International Journal of Operations &
Production Management, Vol. 21 Issue: 5/6, pp.795-811,
[2] Mihaela Ulieru, Robert W. Brennan, Scott S. Walker, (2002) "The holonic enterprise: a model for Internet‐enabled global
manufacturing supply chain and workflow management", Integrated Manufacturing Systems, Vol. 13 Issue: 8, pp.538-550,
[3] Developments in Holonic Production Planning and Control. Int - McFarlane, Bussmann ; 2000
[4] Mihaela Ulieru, Scott S. Walker, Robert W. Brennan Holonic enterprise as a collaborative information ecosystem ; In Proceedings of
the Workshop on Holons: Autonomous and Cooperating Agents for Industry (2001)
[5] Cassina, Jacopo & Cannata, A & Taisch, Marco. (2009). Development of an Extended Product Lifecycle Management through
Service Oriented Architecture
[6] Benoît Eynard, Thomas Gallet, Pierre Nowaka, Lionel Roucoules – “UML based specifications of PDM product structure and
workflow” - Computers in Industry Volume 55, Issue 3, December 2004, Pages 301-316
[7] Design of an assembly modeled by a graph - Rameau, J.F. and Alt, L. - EP Patent Application EP20,090,306,355 - 2011
[8] Teamcenter 10.1 - Getting Started with Product Structure - Publication Number PLM00006 J - 2013
[9] System and method for visualization and comparison of physical assets using engineering design data - Evans, F.E. and Ross, P - US
Patent 8,290,830 - 2012
[10] Allocation of multiple product structures - Pascarella, N. and Nadimetla - US Patent 8,224,471 – 2012
[11] El Hani M.A., Rivest L., Maranzana R. (2012) Product Data Reuse in Product Development: A Practitioner’s Perspective. In: Rivest
L., Bouras A., Louhichi B. (eds) Product Lifecycle Management. Towards Knowledge-Rich Enterprises. PLM 2012. IFIP Advances in
Information and Communication Technology, vol 388. Springer, Berlin, Heidelberg

19