Modélisation du Système d'Approvisionnement 179

Modélisation du Système

d'Approvisionnement

1 Introduction

Dans ce chapitre nous nous proposons d'appliquer la démarche de modélisation des chaînes

fonctionnelles basées sur le formalisme proposée dans la partie II de ce document. Cependant,

il est nécessaire de souligner le fait que nous n'avons pas encore pu pousser l'étude au point de

demander à un ingénieur méthode, extérieur à notre équipe, d'utiliser notre démarche. Aussi, la

qualité des modèles présentés dans le cadre de ce chapitre cache, en partie, notre propre niveau

d'expertise. Comme nous le verrons dans les perspectives de ces travaux, il sera nécessaire, à

terme, d'évaluer exactement quel est le niveau minimum d'expertise requis pour prendre en

main la démarche proposée.

La première section de ce chapitre rappelle non seulement la démarche de modélisation

pro-posée et extrait, du cas d'étude considéré, l'ensemble des opérations oertes par les chaînes

fonc-tionnelles. Ensuite, les trois sections suivantes traitent dans le détail trois classes d'opérations

diérentes : opération d'action, opération d'information et enn une évolution requise.

2 Démarche générale

Cette section va s'attacher à mettre en place la démarche de modélisation proposée dans

la partie II. Rappelons-la en quelques lignes. Pour chaque module de coordination considéré

et chaînes fonctionnelles associées, il s'agit en premier lieu de lister les opérations d'actions,

d'information, les évolutions induites et enn les évolutions requises. Ensuite, pour chacune

d'entre elles, la méthode préconise de leur associer un "masque" de modélisation qu'il s'agit

ensuite d'instancier.

Appliquée au cas d'étude décrit dans le chapitre précédent, seize opérations (cd. annexe C)

sont à considérer :

douze opérations d'actions (indexer le magasin dans le sen horaire, sortir le vérin 1, etc),

deux opérations d'information (détecter la présence d'un produit dans le magasin en A, et

identier un produit),

180 Chapitre 11. Modélisation du Système d'Approvisionnement

en sortie du système d'approvisionnement).

Du point de vue de la taille d'une opération, les plus simples comme la rentrée du vérin

1 décrivent uniquement une évolution d'une chaîne fonctionnelle. Les plus complexes comme

l'indexation du magasin comportent huit évolutions associées du ux de produits.

Dans le souci de ne pas surcharger inutilement cette partie, nous nous proposons de traiter

dans le détail seulement trois de ces opérations (une opération d'action "indexer dans le sens

ho-raire le magasin", une opération d'information "détecter la présence d'un produit dans le magasin

en A", et enn une évolution requise basée sur l'opérateur "déposer une pièce dans le magasin

en E"). Le lecteur pourra cependant trouver en annexe C les modèles proposés pour les treize

autres opérations.

3 Opération d'action : Indexer dans le sens horaire le magasin

Cette opération d'action est basée sur un service oert par le module de pilotage du magasin

rotatif. Les grandeurs de commande spécient à qui demander le service (au module de pilotage

du magasin) et quel service demander (Indexer dans le sens horaire). Ce service dont la durée

est évaluée à quatre secondes fait évoluer le magasin d'une position indexée à la position indexée

suivante dans le sens horaire. Lors de cette évolution, le magasin réalise un1/8^iemede tour. Cette

évolution est spéciée dans le modèle par l'évolution du magasin.

4. Opération d'information : Détecter la présence d'un produit 181

En fonction du nombre de produits dans le magasin pouvant varier de zéro à huit, il y aura

entre zéro et huit produits dont la position évoluera lors de la rotation du magasin. Pour cette

raison, l'opération comporte huit évolutions associées du ux de produits décrivant chacune une

évolution d'un produit. La Figure 11.1 représente uniquement trois de ces évolutions associées

du ux de produits. Après cette présentation des diérentes évolutions modélisées, nous allons

nous intéresser aux pré-contraintes et aux contraintes.

L'écriture de ces dernières pour l'évolution du magasin doit être faite en ignorant toute

évolution associée du ux de produits. Cela revient alors à considérer le magasin comme vide.

Dans ce cas, le seul risque à considérer lors de sa rotation est la chute d'une pièce placée entre le

magasin et le poste d'identication. La pré-contrainte et la contrainte sont alors spéciées par la

proposition suivante : pas de produit présent entre la position A dans le magasin et la position

I sur le poste d'identication. Comme il n'y a pas d'interaction entre le magasin et une autre

chaîne fonctionnelle, cette proposition ne porte pas sur l'état d'une chaîne fonctionnelle.

Pour les pré-contraintes et les contraintes des évolutions associées du ux de produits, il est

nécessaire de rechercher les interactions d'un produit dans le magasin avec d'une part les autres

produits et d'autre part avec les chaînes fonctionnelles. La seule interaction possible est celle

avec le vérin 1 qui peut se produire lors de l'évolution d'une pièce à partir des positions H ou

A. Pour cette raison, il existe uniquement une pré-contrainte et une contrainte pour les deux

évolutions associées du ux de produits dont les conditions sur le ux de produits sont pour

l'une la présence d'un produit en A, et pour l'autre la présence d'un produit en H. Pour toutes

les autres évolutions associées du ux de produits, il n'y a ni pré-contraintes, ni contraintes.

4 Opération d'information : Détecter la présence d'un produit

Le service sur lequel est basée cette opération d'information est oert par le système de

pilotage du capteur placé en A. D'après les grandeurs de commande spéciées (Capteur en A et

détecter présence), l'exécution de cette opération nécessite de faire appel au service de détection

oert par le système de pilotage du capteur en A. Cette exécution implique toujours une évolution

de la chaîne fonctionnelle basée sur ce capteur. Initialement disponible, elle devient indisponible

durant toute la durée de l'opération avant de passer de nouveau dans l'état disponible. Quand il

y a un produit en A dont la présence est probable, les données accompagnant le compte rendu

de n du service de détection correspondent soit à la présence d'un produit soit à son absence.

Du point de vue du niveau de coordination, l'état du produit dans le magasin en A évolue

d'un état où sa présence est probable vers un état où elle devient avérée. Cette information

étant liée à la réception du compte rendu, l'état du produit n'évolue pas pendant l'exécution de

l'opération. Suite à cette description des évolutions spéciées par l'opération de détection d'un

produit dans le magasin, nous étudions maintenant les pré-contraintes et les contraintes associées

(cf. Figure11.2).

La démarche d'écriture des pré-contraintes et des contraintes consiste à écrire d'abord celles

de l'évolution de la chaîne d'acquisition puis celle de l'évolution du produit. L'écriture de la

pré-contrainte et de la pré-contrainte de l'évolution de la chaîne d'acquisition se fait en supposant que

l'exécution de l'opération n'implique pas d'évolution du produit. Ainsi, en l'absence d'un produit

sur le magasin en A, le résultat de l'opération doit correspondre à cet état, à savoir, l'absence

d'un produit dans le magasin en A. Le capteur considéré détecte une présence dans une zone et

non en un point ; il peut alors détecter la présence d'une pièce dans le magasin entre A et B ou

182 Chapitre 11. Modélisation du Système d'Approvisionnement

Fig. 11.2 Opération d'information Détecter présence d'un produit en A.

entre H et A, et de même pour une pièce entre le magasin et le poste d'identication. Le risque

est alors de confondre la présence d'une pièce dans le magasin en A avec une des trois positions

citées ci-dessus. Ainsi, la pré-contrainte et la contrainte de l'évolution de la chaîne d'acquisition

interdisent la présence d'une pièce dans ces trois positions. En supposant connue par le module

de coordination l'absence de pièce dans le magasin, il est alors possible d'exécuter un appel au

capteur en parallèle d'une rotation du plateau. Ceci eut été impossible si la contrainte et la

pré-contrainte imposaient l'indexation du magasin an d'éviter la présence de pièces entre A et

B, et entre H et A.

La pré-contrainte et la contrainte de l'évolution du produit doivent assurer la détection

cor-recte d'un produit dans le magasin en A au risque pour le module de coordination de disposer

d'une mauvaise représentation de l'état du ux de produits. Les décisions prises n'étant pas

les mêmes en présence et en l'absence d'une pièce, cette désynchronisation entre l'état réel du

ux de produits et sa représentation par le module de coordination peut conduire à violer les

contraintes de sécurité et d'écologie. Pour cette raison, et an d'assurer une détection correcte,

la pièce initialement dans le magasin en A doit rester dans cette position durant toute la durée

de l'opération.

5 Evolution requise : Déposer un produit dans le magasin en E

Cette évolution requise approvisionne le magasin en pièces. Ces dernières sont déposées par

un opérateur qui ne donne aucune information sur ses actes. Le module de coordination ne

dispose alors d'aucune information sur le début ou la n de cette évolution requise. Cette absence

d'information est liée à deux hypothèses, d'une part sur les facultés de l'opérateur à déposer

correctement les pièces dans un intervalle de temps donné, et d'autre part sur l'absence de

risque aussi bien pour l'opérateur que pour les produits déjà présents dans le magasin. Pour

ces raisons, l'évolution de l'opérateur sur laquelle est basée cette évolution requise n'est pas

spéciée. En revanche, l'eet sur l'état du ux de produits de cette évolution est modélisé. Sans

elle, aucune pièce n'entrerait dans le système d'approvisionnement de la plate-forme SAPHIR qui

ne produirait alors aucun arbre à cames. Mais le module de coordination ne disposant d'aucune

6. Conclusion 183

Fig. 11.3 Évolution requise Déposer un produit en E.

information sur le début ou la n de cette évolution requise, elle est considérée exécutée chaque

fois que le magasin est indexé au minimum pendant une durée égale à celle nécessaire à l'opérateur

pour déposer une pièce. Dans ce cas, la présence de la pièce déposée est considérée probable.

Avec cette vision, le module de coordination imposera au vérin 1 d'être rentré quand une pièce

probable évoluera dans le sens horaire de H vers A. Il est donc très important de modéliser cette

incertitude sur l'arrivée des pièces (voir la Figure 11.3). Comme nous avons déjà précisé que le

magasin devait être arrêté et indexé pour autoriser cette évolution requise, nous ne détaillerons

pas davantage la pré-contrainte et la contrainte.

6 Conclusion

Dans ce chapitre, nous avons présenté non seulement la démarche générale de modélisation

que nous proposons ainsi que le détail des modèles à réaliser de trois types d'opérations classiques

que tout expert peut être amené à prendre en compte dans un contexte manufacturier. La

démarche de modélisation, clairement située au niveau des modules coordination des chaînes

fonctionnelles, oriente rapidement l'expert à ne considérer que les opérations oertes par ces

dernières, pour ensuite l'amener à décrire leurs interactions. Le formalisme utilisé,

volontaire-ment graphique, structuré et intuitif, vise d'une part à améliorer son appropriation et d'autre

part à maîtriser la taille du modèle obtenu. En eet, et à titre d'exemple, le lecteur pourra

trouver en annexe C.17 une modélisation réseau de Petri du même cas d'étude issu du Master

de recherche de M. Eric Deschamps (Deschamps, 2004)(Deschamps et al., 2004). Au delà de la

diculté liée à la maîtrise du formalisme réseau de Petri pour un expert industriel, force est de

constater qu'il devient très dicile de "prendre du recul" sur le résultat. Enn, il est utile de

remarquer, que lors d'une éventuelle modication de la partie opérative (introduction ou retrait

d'une machine par exemple), le formalisme de "ches" que nous proposons est certainement

plus simple à réactualiser que le modèle réseau de Petri.

Le modèle du système contrôlé considéré étant désormais présenté, nous nous proposons, dans

le chapitre suivant, d'évaluer l'approche de synthèse de lois de commande que nous proposons.

Dans le document Synthèse de Lois de commande pour la configuration et la reconfiguration des systèmes industriels complexes (Page 180-186)