III. Classe de problème : Définition d'une bibliothèque d'opérateurs élémentaires génériques
III.3. Conception des modules réalisant les leviers d'action
III.3.1. Conception de l'architecture des modules
Chacun des leviers d'ac;on est représenté par un module de haut niveau qui est une composi;on de plusieurs modules élémentaires, lesquels, sont de trois types :
• V est l'ensemble des modules de vériGca;on. Chacun d'eux est dédié à la vériGca;on d'une contrainte par;culière ;
• A est l'ensemble des modules d'ac;on élémentaires. Chacun d'eux permet de réaliser une ac;on élémentaire modiGant l'équilibrage de la ligne ;
• M est l'ensemble des modules maîtres. Chacun d'eux est dédié à un levier d'ac;on et permet de coordonner le travail des autres modules comme décrit ci-dessous.
La composi;on des modules pour réaliser les leviers consiste à sélec;onner (Figure 20) : • 1 à n modules de vériGca;on issu(s) de V ;
• 1 à n modules d'ac;on issu(s) de A ; • un et un seul module maître issu de M.
De plus, les leviers élémentaires de vériGca;on et d'ac;on peuvent être communs à plusieurs leviers. Ils seront alors appelés successivement par diEérents modules maîtres.
Figure 20: Composion de modules formant les leviers d'acon.
L'interac;on entre ces modules est réalisée par un mécanisme d'appels/réponses ini;é par chaque module maître. La Figure 21 illustre l'interac;on entre les modules pour réaliser un levier d'ac;on ne nécessitant qu'un seul module d'ac;on et un seul module de vériGca;on.
Figure 21: Interacon entre les di4érents types de modules.
Tout d'abord une sélec;on des éléments d'ac;on des leviers est réalisée à l'intérieur du champ d'applica;on du levier (dernière colonne du Tableau 11). Puis les modules d'ac;on et de vériGca;on sont appelés.
En fonc;on du résultat de la vériGca;on, l'ac;on est validée si la réponse est un accord (la nouvelle alloca;on est enregistrée et elle respecte les contraintes. Par contre le respect de l'objec;f n'est pas évalué à ce niveau), sinon le système retourne à son état ini;al, pour essayer d'appliquer le levier sur d'autres éléments, ou bien appliquer d'autres leviers
Si la première ac;on a été validée, une deuxième ac;on peut être lancée (pour des leviers plus élaborés) La vériGca;on est appelée par le module maître et non pas par l'ac;on : cela permet d'appeler la vériGca;on seule : pour vériGer une alloca;on complète par exemple (plutôt que de juste vériGer l'ac;on) III.3.2. Conception technique des modules
À l'aide du formalisme des automates communicants déGni précédemment (chapitre 2, IV.3), le comportement de chaque module peut être détaillé. Les appels et les retours entre les modules u;lisent le mécanisme des transi;ons synchronisées
L=( L
e, L
r)
. L'ensemble des leviers u;lisés pour la résolu;on est alors représenté par le réseau d'automates composés de ces diEérents modules.Pour chacun des trois types de modules déGnis précédemment, on peut déGnir un modèle générique comme présenté ci-dessous (Figure 22, Figure 23, Figure 23).
a. Le modèle générique d'un module maître
Figure 22: Modèle générique d'un module maître.
Le module maître a pour rôle de coordonner les diEérentes sous-fonc;ons réalisant un levier d'ac;on (fonc;on principale).
Comme illustré par la Figure 22, la première transi;on
t
select∈T
de ce module permet de sélec;onner les éléments sur lesquels le levier va agir (en fonc;on de la déGni;on du levier et de son champ d'applica;on. Ces valeurs sont enregistrées dans les variables de X par la mise à joursélection()∈M
)Le module maître fait ensuite appel de manière séquen;elle à plusieurs modules d'ac;ons élémentaires et de vériGca;on. Ces appels sont séquen;els et ils sont conçus avec un label d'émission
action_i !∈L
eou
vérif_i !∈L
e . La réponse du module de vériGca;on est reçue par le biais des labels de récep;onSi les contraintes ne sont pas vériGées, la transi;on franchie déclenche la mise à jour
RejetAction()∈M
et ac;ve de nouveau la localité ini;ale pour que le levier d'ac;on puisse être u;lisé une nouvelle fois (nnous retrouvons l'état ini;al, le levier ne pouvant pas être appliqué sur les éléments sélec;onnés).Si les contraintes sont vériGées, on appelle l'ac;on suivante, sauf si on était dans la dernière localité : dans ce cas, on applique la mise à jour
ValiderToutesLesActions()∈M
aGn d'enregistrer la nouvelle alloca;on et la localité ini;ale est de nouveau ac;vée (Nous retrouvons l'état ini;al, cependant l'état a été modiGé, car des tâches ont été réallouées).b. Le mof d'un module d'acon
Figure 23: Modèle générique d'un module d'acon.
Comme illustré sur la Figure 23, l'état d’ini;al d'un module d'ac;on permet d'a@endre un appel provenant d'un autre module. Cet appel est réalisé lorsque la transi;on portant le label de récep;on
action_i ?∈L
r est franchie. Lors du franchissement de celle-ci, la mise à jourActions()∈M
permet de réaliser l'ac;on et de modiGer l'équilibrage. La localité ini;ale est alors réac;vée, le module étant alors prêt pour un nouvel appel.c. c. Le mof d'un module de véri,caon
Figure 24: Modèle générique d'un module de véri9caon.
Comme illustré sur la Figure 24, l'état d’ini;al d'un module de vériGca;on permet d'a@endre un appel provenant d'un autre module. Cet appel est réalisé lorsque la transi;on portant le label de récep;on
Vérif_i ?∈L
r est franchie. La localité alors a@einte est la source de deux transi;ons dont le franchissement renverra le résultat de la vériGca;on grâce aux labels d'émissionVérifNonOk_i !∈L
eou
VérifOk_i !∈L
e . Les é;que@es des deux transi;ons con;ennent une garde s'excluant mutuellementtransi;ons est franchissable). Cela permet de vériGer que les valeurs des variables de X vériGent les contraintes spéciGées.