AVERTISSEMENT
Ce document est le fruit d'un long travail approuvé par le jury de soutenance et mis à disposition de l'ensemble de la communauté universitaire élargie. Il est soumis à la propriété intellectuelle de l'auteur. Ceci implique une obligation de citation et de référencement lors de l’utilisation de ce document. D'autre part, toute contrefaçon, plagiat, reproduction illicite encourt une poursuite pénale. Contact : [email protected]
LIENS Code de la Propriété Intellectuelle. articles L 122. 4 Code de la Propriété Intellectuelle. articles L 335.2- L 335.10 http://www.cfcopies.com/V2/leg/leg_droi.php http://www.culture.gouv.fr/culture/infos-pratiques/droits/protection.htm
THESEPrésentée à
L'U. F.R. MATHEMATIQUE, INFORMATIQUE,MECANIQU E, AUTOMATIQUE
en vue de I'obtention du
DOCTORAT DE L'UNIVERSITE DE METZSpécialité : Automatique / Productique
par
Daniel ROY
a a a a o a a a a a
UruT ANCHITECTURE H RARCHISEEMuLTI-ACTNTS POUR LE PII-OTAGE RCNCTIF
D'ATELIERS DE PNODUCTION.
a o o a a a a a o a o a a a o o a a a a a a a a a a a a a a o o
Soutenue le 15 janvier 1998, devant la commission d'Examen :
Rapporteurs : MM. Jean Claude BERTRANDHenri PIERREVAL
Examinateurs : MM. Didier ANCIAUXJean-Pierre BOUREYBernard ESPINASSEPiene PADILLAFrançois VERNADAT
a mes parents,
à Marianne,
à tous mes amis
sans eux rienn'aurait été possible!
Cette thèse a été réalisée au Laboratoire de Génie lndustriel et de Production Mécanique
(LGIPM) au sein de l'équipe d'Automatique et Génie Industriel pour la productique.
Ce travail a été effectué sous la direction scientifique de Messieurs François VERNADAT,
Professeur et Didier ANCIAUX, Maître de conférence, de I'Université de Metz. Qu'ils
trouvent ici I'expression de toute ma reconnaissance pour la confiance qu'ils m'ont témoignée
et I'aide qu'ils m'ont apPortée.
J'adresse mes plus vifs remerciements à Messieurs les Professeurs Jean-Claude BERTRAND
et Henri PIERREVAL pour m'avoir fait I'honneur d'accepter de juger mon travail en qualité de
rapporteur et pour les nombreux conseils qu'ils m'ont prodigués'
Je tiens également à remercier Messieurs les Professeurs Jean-Pierre BOUREY, Bernard
ESPINASSE et Pierre PADILLA, directeur du LGIPM, pour avoir accepté de juger ce travail
en participant au jury.
Enfin, je tiens à remercier tous mes collègues chercheurs et techniciens du LGIPM pour leur
aide et leurs soutiens amicaux.
BIBLIOGRAPHIE.. . . . . . . XVI
INTRODUCTION GÉNÉRALE ET PROBLÉMATIOUE. . . . . . . . . . . . . . . . . .2
2, APPROCHE
I. LES SYSTÈMES MULTI.AGENTS ET LEURS APPLICATIONS AU PTLOTAGE : ETAT DE
1.2. DÉFNnroN ErcARAcrÉRsrleuES DEs AcENrs.. . . . . . . . . . . . . . . . . . . . . l0
1.2.2. Caractér ist iques d'un a9ent. . . . . . . . . . . . . . . . . . . . . . . 121.2.3. Agents cognit i fs. . . . . . . . . . . . . . . . . . . . . 12
1.2 .3 ,1 . S t ruc ture in te rne d 'un agent cogn i t i f . . . . . . . . . . . . . 13L2.3 .2 . Fonc t ionnement d 'un agent cogn i t i f . . . . , . . . . . . . . . 13
1 .2 .4 . Agents réac t i f s . . . . . . . . . . . . . . . . . . . . . l1
L2 .4 .1 . S t ruc ture in teme d 'un agent réac t i f . . . . . . . . . . . . . . 14
L 2 . 4 . 2 . F o n c t i o n n e m e n t d ' u n a g e n t r é a c t i f . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . 1 5
1 .2 .5 . Tab leau récap i tu la t i f . . . . . . . . . . . . 15
I.3. L'rNreu-rcrNcE ARTIFICIELLE DlsrRtsuÉE (IAD)... . . . . . . . . . . . . . . . . . 16
I .4 . Les svsrÈnrs MULrt -AcENrs (SMA). . . . . . . . . . . . . . .11
1 .4 .1 . Les sy , s tèmes à t ab leau no i r (TN) . . . . . . . . . . . . . . . . . . . . . . . . : . . . . . . . . . . 18
1.4.2. Les s l 's tèmes d 'acteL.rs ( ,SA). . . . . . . . . . . . . . ' . . . . . . . 19
1.4.3. Les systèmes ph1's iquement d is t r ibués (SPD) ' ' . . . . . . . . " '20
1.4.4. Les sy 's tèmes à règles de product ion (SRP). . . . . . . . . . . . . . . . . 20
t .4.5. Les svstèmes holoniques. . . .22
1.1.6. Les systèmes neuronaux (SN). . . . . . . . . . . . . . ' . . . . 23
I .5. LE CoNTRÔLE DES SYSTÈMES MULTI-AGENTS.. . . . . . . . . . . . . . . . . . . . . . . . '24
L5. t. Le contrôle décentralisé ou distribué. .. . ' 25
1.5.2. Le contrôle centralisé. . ' ....... 25
1.5.J. Contrô le des systèmes à tableau noi r . . . . ' . . . . ' . . . . . . ' . ' . . . . . . . .26
L6. La, cotuuut [cATIoN DANS LEs SYSTÈMES MULTI-AGENTS.. . . . . . . . . . . . . . . . . . ' . . . - " .29
1.6.1. Les df f i rents rypes de communicat ion. . . . . . . . . . . . . . . . . . - . . . . . 30
L6.2. Les d i f férents modes de communicat ion. . . . . . . . . . . . . - . . . . . . . . . . 30
I . 7 . TneLEeu RÉcAPmJLATt r . . . . . . . . . . . . . . . . . . ' . ' . . ' . . ' . " . . . . 3 t
I .8 . SvsrÈues DE PILoTACE ET sYsrÈMES MULTI-AGENTS, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
1.8.1. Architecture des s1'stèmes de pilotage. .. ... 32I .8. L l . Pr ise en compte de l 'ordonnancement prév is ionnel . . ' . . . . . . . . . . . . ' ' . . . . . . . . . . . . . . . " ' .32
I .9.
rr. MODÉLISATIONDEL'ARCHITECTUREDEPILOTAGERÉICTIF................. .......39
l :^z. SrRUcruRE coNcEPruELLE... . . . . . . . . . . . . . . . . . . ' . . . . . " . ' 39ll.2.l. T1'pe du système multi 'agents retenu- """" 391L2.2. Une nouvelle approche. """" 42
11.2.3. Architecture conceptuelle ......46
11.2.3.4. Les échanges
11.2.3.4.2.3. Les comptes-rendus. . . . . . . . . . . . . . . . . . . . . . . 54
11.2.3.4.2.5. Tableau récapi tu lat i f . . . . . . . . . . . . . . . . . . . . .56
II.3. SpÉcmcnrroN THÉoRreuE DE L'ARcHmcruRE pAR LEs SrertcunRts. ................. ........ 5gIL3.l. Les Statecha
I l 3 I 3 Concept de synchronisat ion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
I I .3 .1.6. Les foncr ions de condi t ion er de sélecr ion . . . . . . . . . . . , . . . . . . . . . 6 l1L3.2. Modélisation du système. ......61
IL-l. LEs ourm DÉvELoppEs 69
11 .1 .2 . l e géné ra teu r d ' agen ts . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 j
l l .+ . : .3 . Remaroue. . .II.5, CoNcLUsIoN 11
III. NIPLÉÙIENTATION DU SYSTÈME SYROCO ..................EI
V. DescRpttow rNFoRMATteuE DES tvtoDULEs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . g lVI,
iII.
XVl. Agents réacr i fs. . . . . . . . . . . . . . . . . . . . . . 92
XX.XXL Les Outils nécessaires..
XXIL StratégiesXXr.
xxvn.
XXIX. LncovrrvruNrcATroN. .............. I I IXXX. Le réseau., . , . . . . . . . , . ' . . . . . . . . . . . . ' . . l I IXXru. Protocole Tcpi lp. . . . . . . . . . . . . . . I Iz
XXXII. Les fenêtresxxxM' Les sockets. . . . . . . . . . . . . . . . . . . . . . I r4XXXV. Partage d'informations................... ..... I 16XXXVI. L'exécurion
XXXVI. La mémoireXXXVIII. Rêcapitulatif des messages. ............. I Ig
XXXX. SyrvcsnoursME/ AsyNcHRoNrsME... . . . . . . . . . . . . . . . . . . . . . . . . . . . I 19
xL[. EXEMPLE ACADÉMIQUE............... ..........12sXLI[ . PnÉserurnnoN DE L'EXEMPLE. . . . . . . . . . . . . . . . . . . . . .125XLIV. CHRor.rocRnMME DE L'AppLrcATroN... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . l2gXLV. RÉsulrnrs pRoDurrs...... ........ t34XLVI.
XLVII. Réactivité aux aléas d'atelier. .................. IJ6XLWil . Réact iv i té aux aléas de product ion . . . . . . . . . . . . . . . . . . . . . . . . . . . t4 t
XLIX. Roausressg ou sysrÈvs rNFoRMArreuE. . . . . . . . . . . . . . . . . . . . . . . 143
CONCLUSION.
ANNEXE I EXEMPLE DE SYSTEMES MULTI.AGENTS.
ANNEXE 2 LES ILOTS VIRTUELS.
ANNEXE 3 L'OUTTL OPTIGAM.
ANNEXE4 LE TRI RAPIDE.
v l
Frcune I- t0 ; ARcHrrEcruRE HÉRnncHrsÉr ..................... 34
FIGURE I- TFIGURE I.2Frcune I-3FIGURE I.4FIGURE I-5Frcune I-6Frcune I-7Fraune I-8Frcune I-9
Froune I- t IFrcune I- l2Frcune I- t 3Frcune II- lFrcune [I-2Frcune tI-3Frcune II-4Frcune II-5Frcune II-6FIGURE TI-7FTGURE TI.8Frcuae II-9
ARCHMCTUREcÉNÉnAED'UN AGENT.. ....... IISvsrÈue À rnaLEnu NorR.. . . . . . . . . . . . . . . . . . . . . . . . . . . . t9SvsrÈue D'AcrEURs.. . . . . . . . . . . . . . . 20AcENT À ense DE RÈcLEs DE pRoDUc1oN... . . . . . . . . . . . . . . . . . . . . .2 tRÉsenu DE NEURoNES À rRots coucHEs. . . . . . . . . . . . . . . . . . . . . . . . . . .24MÉcnNrsue oe cournôue DANs LEs sysrÈMEs À rnsLERu NorR. ........... ...................27CoNTRôI-E pnocÉounnl . . . . . . . . . . .28Coxrnôue À snse DE TABLEAU NorR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29ARcHmcruRE CENTRALTSÉE... . . . . . . . . . . . . . . . . . . . . .34
ARCHmCTURE COORDONNÉE. . . . . . . . . . . . . . . . . . . . . 35ARCHmCTURE DTSTRtsUÉE . . . . . . . . . . . . . . . . . . . . . . . . , 15ARcHmcruRe orsrRnuÉe supenvtsÉe. .. . . . . . . . . . . . . . . . . . . . . . . . 36STRUSTURE cÉNÉnnle oe SYROCO ..........45ScHÉun DE PRINCtrE DE L'ARCHMCTURE SYROCO.MAcHB.rEs À Érnrs ETSTATECHARTS... . . . . . . . . . . . . . . . . . . . . . . . . . . . .59AFFTNAcE oe r-e RepRÉSENTATIoN o'Érer. . . . . . . . . . . . . . . . . . . . . . . .60SyNcuRorqrsATIoN ET swtulrnxÉnÉ .......... 60DFTÉRENTES FONCTIONS. .. . . . . .6I
MooÉlrsnnow ou SupeRvtsEUR PAR æs StrrrecHARTs.. . . . . . . . . . . . . . . . . . . . .63MooÉr-rsnnox ou MÉTA-OBJET PAR I-es Sr.rtecHARTs............. ....... .. 64MoDÉLlsATIoN DEs AoENTS RÉlcrrs PAR LEs SrnrecHnRts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
CoNFrcuRATtox npRÈs LEs PANNEs. """ 138
TEMPS CLOBAL DETRAMMENT DES PANNES..'.... ' .. ' . ... I4O
ANALYSE DES TEMPS DE PANNE. ........"." I4O
CHnONOCnnUME DE LA PRODUCTION AvANT INJECTION D'UN NOUvEAU PRODUIT..'..... ' ........... ' l4l
CHnoNOcnevME DE tA PRoDUCTION npRÈs u{recÏoN DU PRODUITI4 ........---..142
ANALYSE DES TEMPS DE CALCUIJ POUR UNE NOUVELLE GAMME. "......... ..... '"...... I43
F IGURE I I . IOFIGURE I I . I IFICURE I I . I2FToURE I I . I3Frcune II- t4FIGURE I I - I5FICURE III- IFrcune III-2Frcune III-3FIGURE III.4FTGURE III-5FIcURE III.6FtcURE IV- IFrcune IV-2Frcune IV-3FIaURE IV.4Frcune lV-5Frcune IV-6
MooÉlrsl t toN DE LA Ceu-urc.. . . . . ' . . . . . . .66IV{oDÉLISATION DE L,ÂCENT PROOUTT. .,67
ivloDÉLrsATIoN DE L'ÀcENT REssouRcE. .-..... . . .. 63
MooÉulsertoN D'uN L'ATELIER. . ..... 69
SoLUTtoN ou pRoe t -È r tE . . . . . . . . . . . . . . . . . . . . . 71
S o L U T T O N S L O C À L E S . , . . . . . . . . . . . . . 7 3
OnceNtcR, l lu t r r le ou Del iv toN. . . . . . . . . . . . . . . . . ' . . . . . . . . 8+
ORc lNrcRLprMEDEL 'AGENTMÉTÀ-OBJET. . . . . . . . . . . . . . . ' . . . . . . . . . . . . . . . . . . . t 06
ORcINTcRTnME DE L 'ÀcENT CELLULE.. . . ' . . . . . . . t 07
ORGrNtcnRvME DE L 'ÀcENT PRoDUn.. . . . . . . . ' . . . . " . . . . 108
ORcertcnnuME DE L 'AcENT REssouRcE " . . . ' . . . ' . . . . . " " . 109
ORGANTcRAMpte ou cÉNÉnATEUR D'AGENTs ' . . . . . . . . . . . . . . . t l0
PRÉSENTATIoNDEL 'ATEL IER. . . . . . . . . . . . . . . . . . . . " . . . " . ' . . . " . . . . . 125
RÉpnRrmoN DEs PRoDUns PAR REssouRcEs. ' . . . . . . . . . . . . . . . ' . . . . ' . ' . . . " " " ' t28
CHRorqocnnMME D'urILIsATloN DEs REssouRcEs' "..." l3 I
AGENDAoe I 'AL8SEUSE15 . . . . . . . . . . . . . . " . " 132
GnuuerEcHNIQUE ou PRODUIT 13 . . . . . . . . . . . . . . . . . . . . " ' . . " 132
CHnouocRnM!,IE DU PRoDUnt3 : PAs D'ATTENTE... . . . . . . . . ' . . ' . . """"" 133
Frcune IV-7: cHnoxocRAMME DU PRODUn 12 : ATTENTE OUe À t'UtusATloN DE LA RESSOUnCe 5' " '. ' . .. ' . . ' . . 134
FrcuRE lV-8 : TeuPsFrcuRE IV-9 : ANALYSE DU TEMPS DE "FIN DE PHASE". """""""" """' 136
FrcuRE IV- l0 : CoNRcuRnnoN AVANT I.Es PANNES. "" t 37
FIGURE IV- I IFtcURE IV.I2FIGURE [V.I3FIGURE IV-I4Frcune IV- 15FIGURE IV- I6
v l l
Tnnt -enuI -1 :TAeLEeu I-2 :TnsLeeu II- [TnsLsnu II-2TneLenu II-3TnsLeeu III-l
TABLE DES TABLEAUX
LES AcENTS cocNmtrs er RÉncrns.. . . . . . . . . . . : . . . . . . . . . . . . . . . . . . . 16Les sysrÈuus MULTT-AcENTS... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 lRÉcnpnuurtr DEs ARcHmcruREs oes sysrÈurs DE prI-orAcg................... .......44
: Msssnces ou SupenvsEuR .. . . . . . . . . . . . . c0: SyrurRxe ne LA, nÉpoxsn p'Optlcn u q I: CnrrÈRgs DE cHox oe le srReÉcrE DE REPLACEMENT. ............... 104
: RÉpnRrrnoN DEs RESSoURcES pAR TypE.. . . . . . . . . . . . . . . . . .126GnN.rNaes ETTEMeS DE eHASES DEs pRoDUns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
: STRUCTURE DES oBJEcrrFs DE pRoDucf loN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lZ9: RÉpnRrnrou oes RessouRcEs pAR oRDTNATEUR. ..... 130EXEMPLEDEDrs rR tsu r roNDEsCALCULS. . . . . . . . . . . . . . . . . . . 13 lMODIFICATTONS DEs cAMMEs.. . . . . . . . . . . . . . . 138Gnnrur GÉuenrque ou PRODUITI4. . . . . . . . . . . . . . . . . . . . . . . . 14 tRÉcnprruurrF DEs rEMps pe nÉncrroN . . . . . . . . . . . . . . . . . . 145
Tnsr-eA,u III-2TesLEeu III-3TesLenu III-4Tnslrnu IV-lTABr^EAU IV-2TÆI-enu IV-3TABLEAU IV-4TABLEAU IV-5TneLEnu IV-6Tenmnu IV-7Teer-eA.u IV-8
v l t t
REFERENCES BIBLIOGRAPHIQUES
t l#jcE'
"An open system Architecture .for CIM",2nd édition, Springer-verlag, Berlin,
2. Anciaux D., Roy D., "Reactive production System: A New Approach,,, proc. workshopon Production planning and control, organisé par ra FUcAiù, Mons, pp. 277 à 2g l,I I septembre 1996.
3' Anciaux D', Roy D. and vernadat-F. "Reactive Shop-Floor control with Multi-AgentSystem", IFAC/IFIP Int. Conf. on Management and càntrol of production and Logistics,Campinas - SP - Brazil, September l-3, lgg7.
4' Archimède B., "Conception d'une architecture réactive distribuée et hiérarchisée pour lepilotage des systèmes de production", Thèse de doctorat, Université de Bordeaux I,France, 1991.
5. Attoui A,"Les ststèmes rnult i-agents et le temps-rée:", Eyrol les, n" g935. pans,l997.
6' Attoui A., Hasbani A., Maouche A., "specif ication Environment fbr l lult i-agentSystems Based on Anonymous Communications in the CIM Context,,. Laboraroired"lnformariqueilsMA. Aubière, France, I 994.
7' Attoui Ammar, "LIne Approche pour la Spécif ication er la Vatidation des SysrèmesTemps RéeI", université Blaise pascal, clermont-Ferrand, mars 1997.
8' Bakker H., "DFMS : A new control structure for FMS", Contptûer in lrtclustr ies. Vol.10 , pp . l - 9 , 1988 .
9' Barbuceanu M', Fox M. s., "The information agent : An infrastructure agent support ingcollaborative enterprise architecture' ' , 3'd Workshop on Enabling lechnàiogi.s ,Infrastucture for Collaborative Enterprises, Morganto*n, West Virgini i tgq+.
10. Bauer A., Browne J., Bowden R., Duggan J., "shop FIoor control sj,stems,',Chapman & Hall, Londres, 1994.
l l . Benchimol Gry, Lévine pierre, pomerol Jean-charles, , ,systèmes Experts Dans
I'Entreprise", .collection "Traité des nouvelles technologies, série décision assistée parordinateur", 3é'" édition revue et augmentée, Editions Hermes, paris. 1990.
12. Bertrand J. C., Brun-Picard D., Kieffer J. P., "Gestion et pilotage des systèmesindustriels de production dans un contexte d'architecture décentraliséé", 2è'" ôongrèsInternational de Génie Industriel : "Le Génie Industriel facteur de compétitivité desentreprises", CEFI-CGI - Nancy, dec. l9gg.
13. Bil laut J. C., Roubellat F., "A decision support system for real-t ime productionscheduling", [nternational Conference on [ndustrial Engineering and productionManagement (IEPM'93), Mons, Belgique, pp,449-462, Juin 1993.
I X
14. Bongaerts, L, Wyns, J. Detand, J., Van Brussel, H., Valckenaers, p., "Identification ofmanufacturing holons", ln Pre-Proceedings of European Workshop on Agent-OrientedSystems in Manufacturing, Berlin, Allemagne , pp. 13-29,26-27 septemurJtelo.
15. Brun-Picard D., Bertrand J. C., "Commande décentralisée des systèmes automatisés deproduction", J.I.I.A.89 - USINICA 89, Journée de I'informatisation et de I'automatisationdes usines, Paris, France, pp.297-304, Juin 1989.
16. Brun-Picard D., Bouvet H., Baboli H., Binder 2., "The product as an active element ofdistributed production control", Conference on Control of Industrial Systems . C1,97.IFAC-IFIP-MACS, Belfort, mai 1997 .
17. Corby Olivier, "NMS: 'Un module multi-spécialistes pour le générateur de systèmesexperts smeci", unité de recherche INRIA-SOPHIA ANTIPOLIS, 1992.
18. Coriat Michel, "I2AM: une Méthode Orientée Agent pour la Construction de SystèmesDistribués", Thèse de doctorat, Université Pierre et Marie Curie - Paris VI, novembret996 .
19. Craig Iain D., "Formal Specification of AI Systems: Four Case Studies", Department ofComputer Science, University of Warwick, Coventry CV47AL, UK EC, 19g7.
20. Davalo Eric, Naïm Patrick, "Des Réseauxde Neurones",Edit ions Eyrol les, Paris, 1989.
21. Davies winton H E, Edwards Peter, "Agent K: Integration of Aop and KeML",Department of Computing Sciences, University of Aberdeen, Angleterre, 1994.
22. Davtes Winton H E, Edwards Peter, "Agent-Based Knowledge Discovery", Departmentof Computing Sciences, University of Aberdeen, Angletene, 1995.
23. De Smet O., Abou-Kandil H., "Ordonnancement temps-réel pour des systèmesflexibles de production sujets à pannes", Revue d'Automatique et de ProductiqueAppliquées, Vol. 8, No 2-3, pp.29I-296, 1995.
24. Demazeau Yves, Mûller Jean-Pierre (eds.), "Decentralized Artificial Intelligence",Proc. of the First European Workshop on Modelling Autonomous Agents in a Multi-Agent World, North- Holland, Amsterdam, 1990.
25. Dil ts, D.M., Boyd, N.P., Whorms, H.H., "The evolution of control architectures forautomated manufacturing systems", Journal. of Manufacturing Systems, Vol. 10, No. l,pp.79-92, 1991.
26. Dindeleux E., "Proposition d'un modèle et d'un système interactif d'aide à la décisionpour la conduite d'atelier", Thèse de doctorat, Université de Valenciennes, France, 1992.
27. Drolet, J., Moodie C. L. and Montreuil B. "scheduling Factories of The Future". CIRPProceedings: CIRP Conference 89 in Tennessee, June l-2,1989.
28' Duffie N' A', Piper R. s., "Fault tolerant heterarchical control of heterogeneousmanufacturing system entities", Journal of Manufacturing systems, vot.'i, N: ;, ;;.3t5-327, tgg8.
29. Duffie N. A., prabhu V. V.,manufacturing system s", Journal1994.
"Real-time distributed scheduring on heterarchicalof Manufacturing Systems, Vol. 13, No 2, pp.94_107,
30' Espinasse Bernard, Marcio Luiz, spinoza, chouraqui Eugène, ,,D-cM et [AD: une
approche orientée connaissance pour la modélisaiion de systèmes de productiondistribués", Congrès International de Génie Industriel de MontràI, ,'la productivité dansun monde sans frontières", Montréal, euébec, canada, lg-20 octobre tôgs.
3l ' Ferber J., Ghallab M., "Problématique des univers mult i-agents intel l igents,,, ActesJournées Nationales du pRC/LA cepadues-Edition, Toulouse, France, l9gg.
32. Ferber Jacques, " Les Systèmes Multi-Agents. Vers une Intelligence Collective,, ,InterEditions, septembre, I 995.
33. Finin Tim, Fritzson Richard, Mc Kay Don, Mc Entire Robin, ' ,KeML as an Agenr
Communication Language", Proceedings of the Third International Conference onInformation and Knowledge Management, novembre 1994.
34' Fuchs F., "Mult i-agent col laboration in competit ive scenarios", In Re-enguteerirtg Jorsuitable Industrial Production, chapman & Hall, Londres, pp. 275-2g3, [tô1 .
35. Genesereth M. R., Ketchpel s. p., "Software Agenrs", CACM 37(7):4g-53, l4l, Igg4.
36. Gleizes Marie-Pierre, Glize Pierre, "Les Systèmes Multi-Experrs", Edirions Hermes,Paris. 1990.
37. Gounthier A., "De I 'optimisation des coûts de changementdécentralisé d'ordonnancement", Thèse de doctorat, InstitutGrenoble, France. 1990.
de fabrication vers l 'atel ierNational Polytechnique de
38. Grunmback Alain, "Cognition Artificielle - du réflexe... à la réflexion", Addison-Wesley Reading, MA, 1994.
39. Harel David, 'Statecharts: a visual formalism for complex systems', Department ofApplied Mathematics, The Weizmann Institute of Science, Rehovot, lsrael, 19g6.
40. Haton J.P.,"Le Raisonnement en Intelligence Artificielle", lnter Editions, paris, 1991.
4l . Hayes-Roth Barbarâ, "An Architecture for Adaptative Intelligent Systems", KnowledgeSystems Laboratory, Stanford, CA, 1993.
42. Hochuli Shmeil M. 4., Oliveira E., "The establishment of partnerships to creare virtualorganization : a multiagent approach", In Re-engineering for Suitable IndustrialProduction, Chapman & Hall, Londres, pp.284-294, lgg7 .
X I
43. Huguet P., "Conception de systèmes de pilotage d'atelier : Modèles de référence etadaptation d'une qnéthodologie objet", Thèse de Doctorat, Université P. Sabatier.Toulouse. février 1996.
44. Huguet P., Grabot 8., "A conceptual framework for shop-floor production activitycontrol", Int. J. Computer Integrated Manufacturing, Yol.8, No 5, pp. 357 -369, 1995.
45. Hunag, H.P., Chang, P.C., "Specification, Modeling and Control of a FlexibleManufacturing Cell.", International Journal of Production Research, Yol. 30, No. 1[,pp.2115-2543, 1992.
46. Huhns Michael (ed.), "Distributed Artificial Intelligence", Morgan Kaufman, LosAltos, CA, 1987.
47. Jones, A.T., Mclean, C.R., "A proposed Hierarchical Control Model for AutomatedManufacturing Systems.", Journal of Manufacturing Systems, Vol. 5, No. l, pp. l5-25,1986 .
48. Kallel G., "Proposition d'une conduite décentralisée coordonnée pour un atelier defabrication", Thèse de doctorat, lnsfitut National Polytechnique de Grenoble, France,1985 .
49. Keilmann Klaus-Peter, "Multi-Agent-Systems - a Natural Trend in CIM", in
Information Management in Computer Integrated Manufacturing, Springer-verlag,
Berl in, 1995, pp.548-562, 1995.
50. Kouiss K., Pierreval H., Merbaki N., "Toward the use of a multi-agent approach to the
dynamic scheduling of flexible manufacturing systems", Ijnternational Conference on
Industrial Engineering and Production Management (IEPM'95), Marrakech, Maroc, pp.
I l8-125, avr i l 1995.
51. Kowk A., Norrie D., "A development system for intelligent agent manufacturing
sofware", Computer Integrated Manufacturing Systems, Vol. 5, No 4/5, pp.64-76,1994.
52. Kusiak Andrew, Wang Juite, "Negotiation in Engineering Design", Group Decision
and Negotiation, Kluwer Academic Publishers, 1994.
53. Laasri H., Maitre B, "Flexibility and efficiency in blackboard systems : studies and
achievements in ATOME.", in Blackboard Architectures and Application, Y.
Jagannathan, Rjendra Dodhiawala, and Lawrence Baum, editors, Academic Press, pp.
309-322. 1989.
54. Labidi S., Lejouad W., "De I'Intelligence Artificielle Distribuée aux Systèmes Multi-
Agents", INRIA, Rapport de recherche no 2004, août 1993.
55. Legall A., "LJn système interactif d'aide à la décision pour I'ordonnancei'nent et le
pilotage temps-réel d'atelier", Thèse de doctorat, Université de Toulouse, France, 1989.
x i i
56. Loria G., Mazon I., Rojas F., Afsarmanesh H., Wiedijk M., Hertzberger L.O.,"Supporting the Information Management of Control Activities in a CM Shop FloorEnvironment", research supported by CMIS, project ECLA, 1995.
57. Mathews, J., "Holonic organisational architectures.", Human Systems Management,Vol . l5, . pp. l -29, 1996.
58. Merbaki N., "Une approche d'ordonnancement temps-réel basée sur la sélectiondynamique de règles de priorité", Thèse de doctorat, Université Claude Bernard Lyon I,Lyon, France, 1995.
59. Mercé C., "Cohérence des décisions en planification hiérarchisée", Thèse de doctoratd'état-sciences, Université Paul Sabatier, Toulouse, France, 1987.
60. Messaoud D., "Problèmes de décision dans une cellule de production f lexible uti l isantla coopération entre robots", Thèse de doctorat, Université de Lille Flandre Artois, Lille,France. 1986.
61. Mûller Jean-Pierre, Quinqueton Joël, "lA Distribuée et Systèmes Mulri-Agents",JFIADSMA"96, Edit ions HERMES, Paris, 1996.
62. O'Grady, P. and Lee, K.H., "An intel l igence cell control system for automatedmanufacturing.", International Jottrnal of Production Research,Yol.26, No. 5, pp. 85a-
861 , 1988 .
63. Ouzrout Y., Kabachi N., Vincent L., "Une société d'agents pour la prise de décisiondans les organisations productives", IA distribuée et svstèmes multi-agenrs, Editions
Hermes, pp. 35-46, 1996.
64. Parunak V. D. H., "Characterizing the manufacturing scheduling problem", Journal of
Manufacturing System.s, Vol. 10, N" 3, pp 241-252, 1991.
65. Patri t i V., Schâfer K., Ramos M., Charpentier P., Martin P., Veron M., "Mult i-agent
and manufacturing a multilevel point of view.", Computer Application in Production
Eengineering Detroit, Michigan, 5-7 novembte 1997.
66. Pellet X., "Sur la hiérarchisation des décisions. Application à la conduite d'atel ier",
Thèse de doctorat, lnstitut National Polytechnique de Grenoble, France, 1985.
67 . Perez Jean-Claude, " De Nouvelles Voie vers l'Intelligence Artificielle, Pluri'
Disciplinarité, Auto-Organisation, Réseaux Neuronaux",2' " édition, Editions Masson,
Paris, 1989.
68. Perez Jean-Claude, "La Révolnion des Ordinateurs Neuronaux", Collection"Technologies de pointe", Editions Hermes, Paris, 1990.
69. Pujol le G.,"Les réseaux", Eyrol les, no8840, Paris, l995.
70. Rabelo Ricardo J., Camarinha-Matos L.M., "From a Generic Architecture To aParticular Dynamic Scheduling System: The HOLOS Methodology", InternationalConference on Architectures and Design Methods for Balanced Automation Svstems.Victoria - ES - Brazrl,24-26 July 1995.
71. Ramos M., Charpentier P., Martin P., "Reactive distributed and self-organizedscheduling of flexible manufacturing systems", 7'è" Mini-Euro Conférence, Bruges, 24-27 mars 97.
72. Rifflet J. M., "La communication sous UNIX", McGraw-Hill, Englewood Cliffs, NJ,1990.
73. Sahraoui, 'Statecharts based approach for CIM control system specification and design',Laboratoire d'Automatique et d'Analyse des Systèmes du Centre National de laRecherche Scientif ique L.A.A.S-C.N.R.S., 199 L
74. Schâfer K., Patriti V., Charpentier P., Martin P., Spath D., "The multi-agent approachin scheduling and control of manufacturing systems", PAAM'96, Londres, GB, pp. 497-521,22-24avr i l 1996.
75. Shoham Yoav, "Agent oriented programming", Robotics Laboratory, ComputerScience Department, Stanford University, CA, février 1992.
76. Smith, E.E., Osherson, D.N., Rips, L.J., Keane, "Combining Prototypes: a SelectiveModel", Cognit ive Science, Vol.12, pp.485-527, 1988.
77. Sun D., Lin L., "A dynamic job-shop scheduling framework: a backward approach",International Journal of Production Research,Yol.32, No 4, pp. 961-985, 1994.
78. Suraj A., Ramaswamy S., Barber K. S., "Extended statecharts for the modell ing andspecification of manufacturing control software systems", Int. J. Cornpttter IntegratedManufactur ing,Yol . 10, No l -4 ,pp. 160-171, 1997.
79. Tchako J. F. N., "Contribution à la conception d'un système de pilotage distribué pourles systèmes automatisés de production", Thèse de doctorat, Université de Valencienne,France, 1994.
80. Thomas V., "Aide à la décision pour l'ordonnancement en temps-réel d'atelier", Thèsede doctorat, Université de Toulouse, France, 1980.
81. Torrance Mark C., "The AGENT 0 Manual", Artificial Intelligence LaboratoryMassachusetts lnstitute of Technology, MA,30 juin 1994.
82. Trentesaux Damien, "Conception d'un système de pilotage distribué, supervisé etmulticritère pour les systèmes automatisés de production", thèse de doctorat, InstitutNational Polytechnique de Grenoble, spécialité: automatique/productique, janvier 1996.
83. Vernadat F,, "Reconnaissance de situation et commande situationnelle pour la conduitedes ateliers de production", Rapport de recherche RR696-I-MAG 69 LIFIA, Institut
Ëri:i:Ti[î,;i#athématiques Appriquées de Grenobre, saint-Martin d,Héres,
84' Youssef, A., thèse de doctorat, université de Metz, France, juin 199g.
BIBLIOGRAPHIE'
l. Barbuceanu M', "Description and-Specification of Co-ooeration Protocols in COOL"'
Enterprise tntegraion iuto'u'ory' u;*t';it of To'on'o' ^Lnternal
report' 1996'
2. Barbuceanu M', Fox M'' "Capturing and Modelling Co-ordination Knowledge for
Multi-Agent systems,,, Internatioroî lor*al of co-operative lnformation systems'
V"i. S N-os. 2-3 PP' 213-314' 1996'
3. Boulet, B., Chhabra' B' Harhalakis'.G'' Yin:'' t:-tj"-'l;i M'"'Cell controllers: Analysis
and comparision of three major projects'',, Computers in Industry, Vol. 16, pp. 239.254,
199 l .
4. Bussman S', "An agent-oriented, architecture for holonic manufacturing control"' In
proc. of the riïri-rnr"rnarional^wàrtrttop on lntelligent Manufacturing system'
L*runn", PP' l-12' 15-17 avril 1998'
5. Cantamessa, M', "Agent-bas:g -:d:ling and
Computers in Indusirv' Vol' 34' pp' 173-186'
6. Ferber J', "Modèle de systèmes multi-agents - Du
du traitement réparti aui systèmes multi-agents et
18-19 février, 1993'
management of manufacturing systems'"'
1997.
réactif au cognitif", INFAUTOM'93'
à l'autonomie àes systèmes' Toulouse'
7 'F i n i nT ' , e ta l , , , spec i f i ca t i ono f t heKQMLagen tCommun ica i i onLanguage . . , t heDAR'A Knowtedgà Sharing lnitiati;; Ê*i.tnuf Iiterface Working Group' 1992
8. Gauvin D., "Un environnement--de programmation orienté agent" Dans Troisièmes
iournées francophones sur f intelli;.;;;ïiiiti11"- distribuée -et
les systèmes multi-
aeents, St-Baldoph' Savoie' France' 15-l'7 mars 1995'
n. t .O Y ' ," Gestion de Production" 'Economica' Paris' 1988'
10.GOTHA,"LÆsProblèmesd'Ordonnancement ' " 'RechercheOpérat ionnel le 'Vol '27 'N ' l ,PP. 77-150'1993'
ll. Lawler E. L. et coll, ,,sequencing and Scheduling:.Algorithms and complexity'"' in
Logistics "r Tr"à".,ion and tf";il n""4u"95'-"in opetations Research and
Managernen'Stùnt"' Vol' 4' Nortn-Uotland' pp' 445-522' 1993'
12. Parunak V' D' H'' "lndustrial applications of multi-agent system"' INFAUTOM'93' du
raitemenr réparri aux système, ;;];i-;;;nts et a'uu"tono*ie des systèmes' Toulouse'
l8-19 février' 1993'
13. Parunak V' D' H" "Applications of distributed artificial intelligence in industry"' in
o'Hare, G' M' P' and l"nning'' i' n'' toittt' rounJu'ions oiDistributed AI' John
Wiley g so;t' Chichester' England' 1996'
14.
15 .
16 .
Roy D., Anciaux D., "A Hierarchical Multi-Agents Approach Applied ro The shopFloor Control", l3th ISPE/IEE International Confe..n.ïon CAD/CAM Robotics andFactories of the Furure (cARs & FoF), pereira, colombie, 15-17 Décembre 1997.
wooldridge M., Jennings N., "Inteiligent Agents: Theory and practice,', KnowredgeEngineering Review, Vol. 10, No 2, June 1995.
Wyns J., Langer G., "Holonic manufacturing systems described in plain text, IDEF6,and object-oriented methods", In proc. of the First International Workshop onIntelligent Manufacturing system, Lausanne, pp. l3-2g, l5-17 avril 199g.
xv l l
Introduction Générale et problématique.
Introduction Générale et problématique,
1. Problématique.
Le monde industriel est en constante évolution en raison des besoins de l,industrie liés à
I'augmentation de la compétitivité. L'automatisation à outrance des ateliers de production
(remplacement des ressources humaines par des postes de travail automatisés) n,ayant pas
donné les résultats escomptés, une nouvelle approche de conduite/commande doit être définie.
Dans les systèmes manufacturiers multi-gammes, on dispose de diverses ressources
matérielles et humaines pour réaliser une variété de produits. Une gestion rationnelle et
concurrentielle de ces systèmes implique d'une part, un agencement des ateliers (organisation
spatiale) pour optimiser les flux de produits et d'autre part, une affectation des commandes
aux ressources disponibles (organisation temporelle) qui minimise les coûts et les délais de
fabrication et de l ivraison. Cette organisation temporelle pourra, par exemple, se iaire à
travers un système d'ordonnancement dynamique.
Cette organisation doit gérer au mieux toutes les ressources disponibles (c'est-à-dire
matériel les et humaines). De plus, i l lui faut aussi pouvoir accepter un processus de
fabrication flexible. Cette flexibilité se traduit par une facilité de réadaptation er de ré-
affectation des fabrications dans le temps, à l'échelle de la journée de travail dans certain cas,
à court ou moyen terme le plus souvent. De plus, il faut pouvoir faire face instantanément à un
aléa, comme une panne de ressource, en s'orientant vers un mode de production consistant à
continuer de produire avec les ressources restantes (interchangeabilité des ressources). Ainsi.
I'industrie demande des systèmes de pilotage facilement adaptables par rapport à leurs besoins
fluctuants, c'est-à-dire qui soient évolutifs (achat d'une ressource, ajout d'un système
informatique...), et capables de supporter une re-configuration.
Introduction Générale et Problématique.
En d'autres termes, il faut un système de pilotage l25l 162l qui puisse être adapté lorsque,
par exemple, les méthodes de production ou les procédures de contrôle de I'ordonnancement,
changent, mais qui reste capable de gérer la production en réagissant dans des temps du même
ordre que les temps de la production (temps de phases). Un tel système pourra donc être
considéré comme "temPs-réel".
Certaines méthodes tentent de répondre à ce problème t56l t701. Cependant, celles-ci ne
donnent pas entière satisfaction face à des problèmes tels que :
o La gestion des accidents ou aléas de production, en particulier, I'introduction d'un
nouveau produit dans I'atelier etlou la résolution de conflits en cas de panne.
o La nécessité de re-configurer I'installation, même de manière simple,
I'organisation de I'entreprise vient à changer'
o Laconcurrence totale entre les acteurs du système qui, iemble-t-il, induit une perte
de temps en discussion entre acteurs et peut conduire à de sérieux problèmes de
contrôle du sYstème.
Le but de ce travail est de proposer une nouvelle approche, visant, en particulier, à résoudre
Ies problèmes de gestion dynamique en temps-réel de la production (postes de travail en
panne, commandes urgentes...), à automatiser autant que possible le processus visant à adapter
le système aux modifications de I'entreprise et à rationaliser la prise de décision par une
hiérarchisation accrue de I'architecture.
2. Approche ProPosée.
Le problème que nous nous posons est donc d'élaborer un système de pilotage d'atelier
modulaire er (re) configurable qui doit pouvoir s'adapter aux besoins spécifiques des PME-
pMI ayant une production discrète et une demande variable. En d'autres termes, il s'agit de
pouvoir assurer la commande et la conduite d'un atelier manufacturier dans lequel les objectifs
de production (ou, plus précisément, les lots à réaliser et leur date de livraison) ne sont pas
connus a priori. Nous avons décidé d'appeler ce système SYROCO (SYstème Réactif par
Introduction (]énérale et Problématique.
Objectifs de COnduite) car celui-ci ne doit avoir besoin que des objectifs de production
(fournis par la planification) pour élaborer ses ordres de fabrication et doit pouvoir réagir (le
plus rapidement possible) aux aléas intervenant en cours de production.
Pour atteindre cet objectif, SYROCO sera donc basé sur une architecture multi-agents afin
de pouvoir décomposer le problème global en un ensemble de sous-problèmes plus facilement
gérables. Ceux-ci seront traités individuellement par les agents du système. De plus, pour
pouvoir réaliser les organisations spatiale et temporelle, nous utiliserons un ouril
d'ordonnancement préalable total mais dont les résultats pourront être remis en cause en cours
de fonctionnement en cas d'aléas.
Enfin, un système de communication complet sera mis en place afin de permettre aux
différents acteurs du système, répartis sur l'ensemble du parc informatique, de communiquer
entre eux. Ce système de communication sera basé d'une part, sur le protocole réseau TCP/IP
et sur les sockets Berkeley et d'autre part, sur le partage d'informations (ou boîtes aux lettres).
Ainsi, chaque agent pourra avoir accès aux informations dont il aura besoin, dès que
nécessaire.
Pour simplifier le contrôle du système et tenter d'accélérer le processus de réflexion et de
prise de décision, nous utiliserons une architecture multi-agents hiérarchisée/centralisée et
nous nous affranchirons de la coopération entre agents.
SYROCO étant un système assez volumineux en terrnes de modules utilisés, nous
distribuerons nos agents de manière à gérer au mieux le temps CPU de chaque ordinateur afin
de ne pas surcharger le parc informatique sur lequel nous nous implanterons. Ainsi, Ies
ordinateurs du réseau pourront toujours être utilisés à leur(s) fonction(s) première(s).
Introduction Générale et Problématique.
3. Plan de thèse.
Le plan de ce mémoire est composé comme suit :
Nous verrons dans le premier chapitre, les différents types de systèmes multi-agents
existants et leurs systèmes de contrôle. Puis, nous nous attacherons plus particulièrement aux
systèmes multi-agents dédiés au pilotage d'atelier. Nous les classerons par type d'architecture
(centralisée, hiérarchisée, coordonnée, distribuée et distribuée supervisée) avec présence, ou
non, d'un ordonnancement préalable.
Dans Ie deuxième chapitre, nous expliciterons les raisons qui nous ont conduit à choisir
une architecture hybride et non coopérative basée sur des agents hybrides et réactifs, puis nous
modéliserons cette architecture. Chaque agent du système sera analysé et modélisé. Les
communications et les messages échangés dans le système seront caractérisés et expliqués.
Nous spécifierons notre approche de manière théorique à I'aide du formalisme des Statecharts
de Harel. Enfin, nous nous attacherons à présenter les différents outils utilisés par le système
(outil d'ordonnancement, outil de génération d'agents).
Le troisième chapitre sera consacré à la partie informatique du système. Nous préciserons
les contraintes informatiques et nos choix d'implémentation. Les algorithmes des agents seront
explicités et commentés. Nous nous attacherons aussi particulièrement aux problèmes de la
communication en général et au partage d'informations en particulier. En d'autres termes, nous
verrons comment les différents modules de I'application parviennent à échanger des
informations, quels sont les outils et les protocoles réseaux utilisés et comment sont
implémentés les messages modélisés précédemment.
Enfin, dans le dernier chapitre, nous vérifierons que notre approche répond bien à nos
attentes (effectuer un pilotage réactif dans des temps acceptables par rapport à la dynamique
Introduction Générale et Problématique.
du système commandé) en I'appliquant à un exemple académique. Cet exemple présentera des
points critiques tels que la présence de ressources goulots et une nécessité de réaction très
rapide.
La conclusion résume les avantages de notre approche, en énonce les limites et présente
quelques perspectives d'amélioration et de poursuite de ce travail.
CHAPITRE I
LES SYSTEMES MULTI.AGENTSET LEURS APPLICATIONS AU PILOTAGE:
ETAT DE L'ART
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'arL
l. Les systèmes multi-agents et leurs applications au pilotage : Etatde l'art
L|. lntroduction.
L'augmentation et la globalisation de la concurrence et de la compétitivité font partie des
principales raisons qui obligent les entreprises à se remettre en cause. Elles se doivent
d'adapter au mieux I'ensemble de leur organisation et de leur gestion et en particulier celles de
leur système de production. Il convient donc de définir une organisation qui gérerait en temps
réel la prise de décision afin d'aboutir à plus de souplesse, de flexibilité et de réactivité [4]
t l2 l t l5 l t26l t43l t82l t831.
Dans un premier temps, les entreprises qui disposent d'un nombre important de ressources,
doivent organiser au mieux l 'agencement de leur atel ier A. proiu., ion. Ceci af in doptimiser
le plus possible les flux de matières et donc de gagner temps et argent. Dans un deuxrème
temps, il leur faut mettre en place une gestion sachant contrôler au mieux le partage des
ressources et les flux de produits, ce qui permettrait de minimiser les coûts et les délais de
livraison.
L'objectif est donc de mettre en place un système de pilotage dynamique et réactif sachant
traiter en quasi-temps-réel les informations concernant les ressources de I'atelier (le système
devant pouvoir réagir aux aléas de production tels que les pannes ou les commandes
urgentes). L'utilisation de systèmes multi-agents nous paraît perrnettre Ia résolution de cet
objectif. En effet, nous pouvons, ainsi, allouer un agent par tâche à effectuer et gagner ainsi en
rapidité et réactivité.
Les systèmes multi-agents de pilotage des systèmes de production devront donc être
modulaires et configurables afin de répondre aux besoins des entreprises, toutes différentes
tant au niveau de leurs productions que de leurs stratégies de production.
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
Plusieurs systèmes de distribution des connaissances applicables aux systèmes de
production ont déjà été développés. Parmi ceux-ci, nous pouvons citer ATOME [53] (créé par
H. Laasri, F. Charpillet et D. Chevrier de I'INRIA-CRIN de Nancy), inspiré des architecrures
hiérarchiques basées sur Ie modèle du tableau noir, et dont les principaux éléments sonr les
sources de connaissances, le tableau noir et le mécanisme de contrôle. ATOME est implanté
sur station de travail SUN sous environnement UNX. Il a été utilisé pour I'aide à la
maintenance de voirie urbaine, la planification des tâches, I'aide au commandement avec
contraintes en temps réel, etc. ATOME est en cours d'expérimentation dans notre laboratoire
pour le pilotage d'un système de production utilisant une architecture complètement
décentralisée et composée d'experts concourants à la résolution du problème de pilotage. ce
travail fait I'objet de la thèse de A. Youssef [84].
Le système HEARSAY-tr [ l ] [al] a été développé à I 'université Carnegie-Mellon par B.
Hayes-Roth, dans le cadre d'un projet de recherche sur la compréhension de Ia parole. Il est
composé lui aussi de sources de connaissances, d'un tableau noir et d'un mécanisme de
contrôle.
DECIDEX tl l l t36l est un modèle hiérarchisé à deux niveaux, constitué d'un module
maître, ou superviseur, au niveau supérieur et de plusieurs modules de connaissances relatifs à
des expertises au niveau inférieur. DECIDEX est le premier système multi-experts
commercialisé en France; il est implanté sur micro-ordinateurs tsM-PC et compatibles et sur
VAX/VMS. C'est un système interactif d'aide à la décision stratégique pour la planification
dans les entreprises et les administrations.
ASYMEX tlll t36l est un modèle hiérarchisé où le plus haut niveau est constitué du
module de savoir-faire et du module de connaissances interdisciplinaires et où les modules de
connaissances expertes forment le niveau le plus bas. ASYMEX est implanté sous UND( sur
des stations de travail SUN.
chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art
Holos [70J est une méthodologie particulière et adaptée aux systèmes de production,
perrnettant la construction d'un système dynamique qui réagit en temps réel. Le système
obtenu est ouvert, multi-agents, orienté objet, extensible, modulable et peut être facilement
reconfigurable' Sa structure de conduite est construite automatiquement à partir de la
description CMOSA du sysrème de production Il].
Ce chapitre présente donc un état de I'art sur les techniques de l'intelligence artificielle
distribuée et en particulier sur les systèmes multi-agents et multi-experts en vue de leur
application à la conduite des systèmes de production. Nous verrons, dans la première partie, la
définition d'un agent, ce qui le caractérise dans sa globalité, sa structure et son mode de
fonctionnement. Nous aborderons les deux types d'agents: les agents cognitifs et les agents
réactifs' Dans la seconde partie, nous étudierons les différents types de structures existantes
(le type d'agents qui les composent, leur nombre, leur mode de communication er de
collaboration). La troisième partie nous amènera à voir les différents modes de contrôle, tels
que le contrôle centralisé, le contrôle décentralisé, le contrôle procédural et le contrôle à base
de tableau noir. Dans la quatrième partie, nous verrons les modes de communication (par
envoi de message et par partage d'information). La cinquième partie sera consacrée à l,étude
des systèmes de pilotage. Un certain nombre de systèmes multi-agents existants, tels que
ATOME, HOPES, HECODES et ARCHON sont présentés plus en dérails dans I'annexe l.
1.2. Définition et caractéristiques des agents.
1.2.1. Introduction.
Les agents sont des entités physiques ou abstraites, douées d'autonomie et capables d'agir
sur leur environnement et sur elles-mêmes [32] I35l t75l [81], c'est-à-dire de modifier leur
propre comportement t5l t lSl t22l t4ll (Figure I-l). I ls disposent pour cela d'une
t 0
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
représentation partielle de cet environnement (et éventuellement aucune) ainsi que de moyens
de perception et de communication. Le comportement d'un agent résulte donc de ses
observations, de ses connaissances et des interactions avec les autres agenrs lg|tzll t30l t33l
t8 l l .
La distribution des connaissances parmi les agents du groupe peut être réelle ou virtuelle,
redondante ou non, conduire ou non à des modalités de partage [22].Les agents peuvenr donc,
soit disposer de la même connaissance, soit avoir leur propre connaissance sans interaction
avec celles des autres, ou encore disposer de connaissances qu'ils sont prêt à partager selon
certaines modalités définies au préalable t5al t6ll.
Liaison système
Figure I- I : Architecture générale d'un agent.
Les agents sont définis par un ensemble de caractéristiques structurelles (ensemble de
composants), environnementales (représentation que se fait chaque agent de son
environnement et de lui-même) et comportementales (permettant d'expliquer leurs actions et
que I'on appelle déterminants) [32]1751.
Les agents ont deux tendances :
il
Communication
Contrôleur detransactlons
Histonquedes erreurs
RepriseSUT CTTCUTS
Exécut ion
BASE DE DONNEES / CONNAISSANCES
Chapitre [ : Les systèmes multi-agents et leurs applications au pilotage : E11t de l,art
Une tendance sociale tournée vers la collectivité, c'est à dire que les mécanismes erconnaissances associés concernent les activités du groupe.
Une tendance individuelle avec des mécanismes et des connaissances contenant lesrègles de fonctionnement internes de I'agent.
De plus, il existe deux types d'agents, les agents cognitifs et les agents réactifs, et selon
I'agent choisi, on parlera soit de système cognitif, soit de système réactif.
1.2.2. Caractéristiques d'un agent
Tous les agents présentent des caractéristiques communes qui sonr tlSl t2ll lZ2l t30l t32l
t33l ts4l t6 l l [7s] [81] [82] :
lntentionnalité : un agent est guidé par ses buts ; l'intention est Ia déclararron
explicite des buts et des moyens d'y parvenir.
Rationali té : un agent dispose de critères d'évaluation de ses actions et sélectionne
selon ceux-ci les meil leures actions qui lui permettront d'atteindre son but.
Engagement : un agent coopératif planif ie ses actions par coordination et
négociation avec les autres agents ; i l construit un plan pour atteindre son but.
Adaptabilité : agent de haut niveau de flexibilité capable de contrôler ses aptitudes
selon I 'agent avec qui i l interagit.
o Intel l igence : un agent intel l igent est un agent cognit i f , rat ionnel, intentionnel et
adaptatif.
1.2.3. Agents cognitifs.
Un système cognit i f est composé d'un nombre d'agents "intel l igents" disposant d'une
base de connaissances comprenant I'ensemble des informations et des savoir-faire nécessaires
à Ia réalisation de sa tâche et à la gestion des interactions avec les autres agents et son
environnement [8] 1321 1631. On dit aussi que les agents sont "intentionnels", c'est-à-dire
qu'ils possèdent des buts et des plans explicites leur perrnettant d'accomplir leurs objectifs
t38l t4ll t54l t6ll.Leurs capacités d'anticipation et de planification leur perrnettent
d'optimiser leur comportement et de n'effectuer ainsi que les actions véritablement
pet l t
t2
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
nécessaires. Ce système est basé sur la coopération d'agents capables d'effectuer des
opérations complexes.
Chaque agent est assimilable à un système expert, ou système doué de faculté de
raisonnement, plus ou moins sophistiqué selon ses capacités ; on parle alors d'agents à forte
granularité (degré de détail des connaissances de I'agent, exprime la complexité des
fonctionnalités d'un agent).
1.2.3.1. Structure interne d'un agent cognit i f .
Un agent cognitif peut être caractérisé par les éléments suivants [32] :
o Savoir-faire : c'est la déclaration des connaissances et compétences d'un agent, ce
qui permet par Ia suite de sélectionner un agent à solliciter.
o Croyances : connaissances qu'un agent a de lui-même et"des autres.
o Contrôle : correspond aux buts, intentions, plans, et tâches qu'un agent possède
. Expert ise : i l s 'agit des connaissances sur la résolution d'un problème (base de
règles ou autre forme de connaissance).
o Communication: protocole de communication permettant aux agents d' interagir
entre eux.
a.2.3.2. Fonctionnement d'un agent cognit i f .
Les agents sont immergés dans un environnement avec lequel ils interagissent t38l t41l
t54] [61]. De ce fait, ils se trouvent structurés autour de trois fonctions principales :
o Perception : la perception permet de classer les connaissances de I'agent dans deux
catégories : les connaissances certaines et les connaissances incertaines. On parle de
connaissances certaines lorsque celles-ci ne subissent aucune remise en cause. Elles
correspondent aux informations issues de la perception que I'agent a de lui-même et
du monde ainsi que de son savoir initial. Les connaissances incertaines sont les
informations provenant d'autres agents ou de capteurs et qui peuvent évoluer sans
que I'agent en soit informé. En classant ainsi les connaissances, il est possible d'en
évaluer la crédibilité et de les vérifier si nécessaire.
I J
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art
o Prise de décision : un des problèmes de I'agent est de sélectionner les buts àsatisfaire et les actions qui perrnettraient de les atteindre. L'agent analyse alors lesdifférentes solutions en termes d'utilité (avantage) et d'incertitude (réussite). Lanotion de "carte cognitive" (réseau qualitatif exprimé en terme d'influencespositives ou négatives et reliant les buts et leur utilité) perrnet de retenir le but avantle plus d'influence positive.
o Planification : dans le cas des agents coopératifs, la planificarion est distribuée,
c'est-à-dire qu'il n'existe pas de plan global et que chaque agent construit sonpropre plan en coordination avec les autres. I-es agents alternent donc planification
et exécution afin de réviser des parties de leur plan. Notons qu'il existe aussi des
systèmes utilisant une planification centralisée, c'est-à-dire qu'un organe central se
charge de la gestion des conflits et de l'élaboration d'un plan global.
1.2.4. Agents réactifs.
Un système réactif comprend un grand nombre d'agents de faible granularité (ou grain fin)
(de plus bas niveau) qui disposent d'un protocole et d'un langage de communication réduit ;
leurs capacités répondent à la loi stimulus/action [32]. Les agents réactifs n'onr aucune
représentation symbolique explicite du monde. Dans un tel système, il n'est donc pas
nécessaire que les agents soient intelligents individuellement pour que le système ait un
comportement intelligent, c'est-à-dire que chaque agent a sa propre base de connaissances ou
doit élaborer un plan d'action [61] [67], Des mécanismes de réaction aux événements, ne
prenant en compte ni une explication des buts, ni des mécanismes de planification, peuvent
alors résoudre des problèmes qualifiés de complexes. Ainsi, ce n'est pas au niveau de
I'individu que les agents réactifs sont intéressants, mais au niveau de la population et des
capacités d'adaptation et d'évolution qui émergent des interactions entre ses membres.
1.2.4.1. Structure interne d'un agent réactif.
Un agent réactif est en fait un programme (procédural ou déclaratif) décrivant de manière
l 4
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
précise un comportement donné spécifique d'une situation connue. Les règles sont données
par le concepteur de I'agent. En fait, I'intelligence d'un agent réactif ne vient pas de l'agent
lui-même, mais de la façon d'aborder le problème de la part du concepteur. C'est ce dernier
qui définit de manière précise le comportement de I'agent face à telle ou telle situation.
1.2.4.2. Fonctionnement d'un agent réactif.
Les agents réactifs peuvent être dirigés par des mécanismes de motivation les poussant à
accomplir une tâche, telle que la satisfaction d'un besoin interne (par exemple maintenir leur
niveau énergétique) ou I'accomplissement d'un but défini par le constructeur. On peut aussi ne
les faire répondre qu'à des stimuli issus de I'environnement, leur comportement étant guidé
intégralement par l'état local du monde dans lequel ils se trouvent plongés. On peut dire que
I'agent réactif contient une connaissance compilée des actions à effectuer ; il n'a pas besoin de
construire une représentation mentale de son monde (comme le font les agents cognitifs), car
il lui suffit simplement de réagir aux situations qui se présentent (règles événement-action).
En fait, la simplicité de ses comportements témoigne plus de l'intelligence des concepteurs
que de la sienne.
En résumé, la différence majeure entre un agent réactif et un agent cognitif est que I'agent
réactif travaille dans un monde clos (c'est-à-dire que tous les types de situation à envisager
sont connus) alors que I'agent cognitif travaille en monde ouvert (c'est-à-dire qu'il peut réagir à
de nouveaux types de situation par apprentissage ou par raisonnement, qu'ils soient inductifs
ou abductifs).
1.2.5. Tableau récapitulatif.
Le Tableau I- [ résume les différences entre les deux approches, cognitive et réactive. Il est
cependant possible de concevoir des systèmes hétérogènes comportant les deux types
t5
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
d'agents. II est aussi possible de doter les agents cognitifs de capacités de réaction aux
événements, on les qualifiera alors d'hybrides.
1.3. L'intelligence artificielle distribuée (tAD|
L'intelligence artificielle distribuée (IAD) concerne les problèmes pour lesquels un seul
solveur de problème, une seule machine ou un seul processeur semble inapproprié l24l l31l
136l 146l [49] [61] [67]. El le s' intéresse aux cas de résolution de problèmes enrre cie
nombreuses entités faiblement couplées, pouvant être en situation de coopération ou de
conflit. son champ d'application peut être décomposé en deux thèmes majeurs :
. La résolution distribuée de problème, qui cherche à déterminer comment le travail
de résolution d'un problème particulier peut être réparti entre de multiples modules
(ou experts) ayant chacun des connaissances partielles du problème. On parle aussi
de système multi-experts.
o La résolution multi-agenrs, qui cherche à coord'onner le comportement de plusieurs
agents ou entités autonomes pour la résolution d'un problème. La tâche de
coordination dans un système multi-agents est souvent ardue, car celui-ci peut
aborder des situations "ouvertes" dans lesquelles il n'y a pas de possibilité de
contrôle global, de critère global de réussite au problème, ou même de
représentation globale du système. La cohérence globale ne peut alors provenir que
des interactions (conflit, négociation, compromis) entre agents.
D'une manière générale, I'IAD est confrontée à un certain nombre de problèmes tels que :
o La formulation, la décomposition, et I'attribution de problèmes ainsi que la synthèse
Sy s tème s d' a g ents c o gnitifs Systèmes d' agents réactifs
Représentation explicite de I 'environnement Pas de représentation explicite
Peut tenir compte de son passé Pas de mémoire de son histoire
Agents complexes Fonctionnement stimulus/réponse
Petit nombre d'agents Grand nombre d'agents
Tableau I-l : Les agents cognitifs et réactifs.
r6
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
des résultats d'un groupe d'agents ou d'experts.
o La communication et I'interaction entre les agents (ou experts). C'est-à-dire, quel(s)
langage(s) et quel(s) protocole employer, quelles informations envoyer et à quel
moment.
o La reconnaissance et la conciliation de points de vue disparates et de conflits entre
agents (ou experts).
o La cohérence des décisions et des actions des agents (ou experts).
. La coordination entre agents (ou experts).
Ces problèmes sont liés et, par conséquent, leurs solutions le sont aussi. La résolution de
I'un d'eux apporte souvent des contraintes quant à la solution des autres. Ainsi, par exemple, le
choix de protocoles de communication a des implications sur la cohérence du comportement
de I'agent. De même, à partir de plusieurs décompositions de tâches possibles, il peut en
résulter plusieurs types d'interactions et de modélisation.
1.4. Les sysfèmes multi-agents (SMA).
Par définition, un système multi-agents est composé d'un environnement dans lequel se
trouve un ensemble d'objets et d'agents en interaction pour atteindre un but donné [5]. Les
objets sont des éléments passifs, en ce sens qu'ils peuvent être créés, détruits et modifiés par
les agents. Un agent est un objet particulier figurant les entités actives du système. Il possède
donc un certain degré d'autonomie de décision et une capacité à interagir avec son
environnement. On peut donc dire que les objets sont les entités "processées" et les agents les
entités processeurs du domaine considéré. A cela, il faut ajouter un ensemble de relations et
d'opérations qui unissent les objets (au sens général du terme, comprenant donc les agents)
entre eux et permettent aux agents de percevoir, produire, consommer, transformer et
manipuler des objets [22].
Le principe d'un SMA est de distribuer entre plusieurs agents I'ensemble des
connaissances et la capacité de raisonnement que possède un système dit intelligent I l8] [24]
t 7
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
146l t741. Chaque agent est ainsi spécialisé dans un sous-domaine du domaine de départ, ce
qui lui permet de résoudre une partie, voire la totalité, d'un problème.
Selon certains protocoles de communication existants [21], un agent peut coopérer avec
d'autres agents et, ainsi, soit augmenter sa participation à la résolution d'un problème, soit
compléter les informations de ces agents. Cela implique donc de pouvoir coordonner le
comportement de plusieurs agents autonomes. Bien souvent, cet échange d'information est
assuré par un langage comme KQML (Knowledge Query and Manipulation Language) qui est
un langage de communication particulièrement adapté àcet effet [21] t331. En effet, KQML
perrnet la communication en réseau, au format TCPÆP ou HTTP. Les messages sont tous
formatés selon le principe LISP et comprennent l'émetteur, Ie destinataire et, bien sûr,
l'information communiquée.
En résumé, les trois préoccupations principales d'un SMA sont :
o Lacommunication,
o Le contrôle,
o L'organisation.
des connaissances entre les agents.
Parmi les différents systèmes existants, on peut citer les systèmes à tableau noir, les
systèmes d'acteurs, les systèmes physiquement distribués, et les systèmes à règles de
production Les paragraphes qui suivent sont dédiés à l'étude détaillée du fonctionnement de
ces systèmes.
1.4.1. Les systèmes à tableau noir (TN).
Le modèle à base de tableau noir (TN) est fondé sur un découpage en modules
indépendants, appelés sources de connaissances (SC), qui ne se communiquent directement
aucune donnée, mais qui interagissent indirectement en échangeant ces informations à travers
une mémoire partagée (ou base de données partagée), appelée tableau noir (cf . Figure I-2)
l 8
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
tlSl [19] t32l1401 [49]. Cette entité comprend tous les éléments nécessaires à la résolution
d'un problème. Elle peut être divisée en plusieurs régions appelées niveaux d'abstraction ; les
SC n'ont alors accès qu'à certaines de ces zones en lecture etlou écriture. Les systèmes à TN
se prêtent très bien à la réalisation de systèmes multi-experts et servent souvent
d'architectures de base pour implanter des agents dans les systèmes physiquement distribués.
Figure I-2 : Système à tableau noir.
1.4.2. Les systèmes d'acteurs (SA).
Dans les systèmes d'acteurs tl8l t32l [40] [76], la distribution des informations se fait par
échange de messages asynchrones entre les différents acteurs (chaque entité doit négocier avec
les autres pour coopérer) (cf. Figure I-3). Ces messages correspondent à des requêtes, à des
informations utiles à la résolution d'un problème, à des négociations, ou toute autre forme de
communications.
On distingue deux types d'acteurs : les acteurs sérialisés et les non sérialisés. Les acteurs
sérialisés changent d'état suite à I'exécution d'un message; ils ne traitent qu'un message à la
fois et spécifient leur nouvel état avant de traiter un nouveau message. Les acteurs non
sérialisés traitent plusieurs messages en parallèle.
l 9
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
Figure I-3 : Système d'acteurs.
1.4.3. Les systèmes physiquement distribués (SPD).
Pour ce qui est des systèmes physiquement distribués t32l t40l 146l l52l,les agents sonr,
d'une part, localisés sur des sites distants (ils peuvent même êtres séparés par de grandes
distances) et, d'autre part, plus complexes que ceux des systèmes à TN ou des SA. En effet,
chaque agent est autonome et capable de résoudre un problème seul. Cependant, il lui est
possible d'améliorer la quali té ou la vitesse de sa résolution s' i l accepte de coopérer avec
d'autres agents à travers un réseau de communication.
Dans le modèle du contract net, par exemple, les agents coopèrent par négociation sous
forme de contrats. Un agent peut décomposer un problème en sous problèmes qu'il soustraite.
Pour cela, il lance des appels d'offre et évalue les propositions qu'il a reçues ; il passe alors un
contrat avec I'agent ayant fait la meilleure proposition et lui délègue la tâche.
Dans le système DVMT (Distributed Vehicle Monitoring Test), par contre, les agents
échangent leurs solutions partielles pour arriver à une solution globale satisfaisante. Notons
que chaque agent est en fait un système à TN (ce système a été appliqué, entre autre, à
I'analyse de trafic routier par synthèse des observations de capteurs).
1.4.4. Les systèmes à règles de production (SRP).
Un système à règles de production est défini par la combinaison d'une base de faits, d'une
base de règles de production, formant une base de connaissances, et d'un interprète appelé
20
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage z Etat de I'art.
moteur d'inférence t32l t401. Bien qu'il y ait une grande variété de syntaxes pour la définition
des règles de production, celles-ci sont généralement données sous la forme suivante :
Isi <liste-conditions> alors <liste-actions>],
où <liste-conditions> est associé à des éléments de la base de faits et <liste-actions>
comprend des actions élémentaire, .ornrn. : ajouter/supprimer des éléments de [a base de
faits, activer les commandes d'exécution de I'agent. Si plusieurs règles peuvent être activées,
on dit qu'elles sont en conflit, et le système de contrôle du moteur d'inférence déclenche la
règle qu'il considère comme la plus prioritaire.
Ajouter /Supprimer
Figure I-4 : Agent à base de règles de production.
Dans le cadre des SMA, un agent peut être représenté sous la forme d'un système à règles
de production, muni des fonctions d'interprétation et d'exécution. Dans ce cas, on dit que
I'agent est un système expert ayant sa propre base de connaissances. La fonction de perception
se borne à placer les informations ou les messages perçus à I'intérieur de la base de faits
L agentBase de règles
Moteur d inférence
Base de faits Exécution
Env ironnement
2 l
,,, ""r
rrr,u*"'*"n''"**o *lî'-'--lnjïî:' *
t 'e fonctionnernent du moteur,l:***te'
Y"-- '
--.o d'agent le tonçur""^'- _ r Â\ , _hrê d'agents
-.e en corûpte directernent (Figure 1-4)'
r peuvent avoir un grand nombre
)s systèrnes à règres de production
peuvent avoir t,roro*o,ions)' Les agents ne
muniquanr pu, r',n**euon"
:: :î:,", "-" ï-i;r
contribution à ra résorution
naissant ni la globalité du prob\èrne nt
rn Problèrne est faib\e'
I un système
^
: ;:"1""Jïï: :::
*" approche origïnare qui consi'c
cornrne un agglornéra d,unïtés,
ou holons' dïstribuées et autonornes'
un systèrne holonique est
une société de ho\ons qui coopèrent pour atteindre
un but ou un obiectif ' ces systèmes sont
î:î":'i:,:^.':ï"" ::if l':::{x" Ï .::: J:'i ;.ixe "on" fut aiouté
réso\ution de Ioblectif
g\obal'
Le rerrne ,5s,on" es, dérivé -,î::*:";:ï:::::î-:
.'u:,,,"..ce
a*iricïe\\
,::,:î,:îlïïl*:"î:",-.'.ï:" Ï::'"" ïn'l e\\i gence a*irrcïe\\e
ce*e approche ... .:^ ̂ nrrnre ra capacité u" "'uo * t"îtï-:î""::ït
cette approche est rtv- r
^. ,^ ^nrfrrTrglacapacité dectç"'
--
- ^.,nrre\ un ensemble
,,auronornie d,un ho\on est définie t"î:r":t"r,
," processus grâce auQue\
propres p\ans etJou stratégies' La coopération
est un Proc
d,entités peuvenr créer des prans accePtés
par tous e. -
:: ,;:nr, èû rninirnurn' l'autonomie
Chaque holon est décrit par un ensemble d attributs ou
-'* nitê'r les stations deChaquo ""'- _, ̂ ite.r les
et ra coopération' .r^ns \eS systèmes de production'
ofl peut citer
cornme exernples
d'ho\ons tî,..:
svsrèmes de contrôle
qualïté' et'c' ces ho'l
travail, les sYstèrnes de
')'l
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
ètre agrégés en holons de niveau supérieur tels que le département de planification ou des
cellules de fabrication.
Bien que cela ne soit pas I'objet de l'approche holonique, elle peut facilement être
implémentée ou simulée avec des systèmes multi-agents.
Pour conclure, nous pouvons dire que, bien qu'ils soient fondamentalement peu différents
des systèmes multi-agents, les systèmes holoniques représentent un niveau d'abstraction
supérieur aux agents. Niveau d'abstraction qui se trouve être trop élevé pour notre étude.
1.4.6. Les systèmes neuronaux (SN).
Pour compléter cet état de I'art, nous citerons les systèmes neuronaux (SN). Bien qu'à
proprement parler, ce ne soient pas des systèmes multi-agents, les systèmes neuronaux se
caractérisent par un très grand nombre d'agents ou cellules (appelés neurones), tous
identiques, communicant par flux de données suivant des liaisons fixes et préétablies [20] t40l
t67l t681. Lacontribution de ces cellules à la résolution d'un problème est inf ime en raison de
leur totale absence de connaissance du problème global et d'autrui. Chaque neurone détermine
sa valeur de sortie en fonction des valeurs d'entrée qu'il reçoit d'autres neurones. Les fonctions
d'activité les plus classiques dans ce genre de systèmes sont les fonctions à seuil ou les
sigmoides, qui indiquent qu'un neurone est actif à partir du moment où la somme de ses
valeurs d'entrées dépasse une certaine grandeur.
La base même d'un système neuronal étant la communication, les cellules (ou neurones)
sont reliées entre elles par un réseau (Figure t-5). Celui-ci peut être synchrone ou asynchrone,
à liaisons partielles ou totales, à liaisons aléatoires ou monotones [20] [68].
Il existe un grand nombre de modèles de réseaux de neurones, les plus classiques étant les
réseaux à couches (réseaux de neurones synchrones, à liaisons partielles et aléatoires) et les
réseaux entièrement connectés (réseaux de neurones synchrones, à liaisons totales et
Chapitre I : Les systèmes multi.agents et leurs applications au pilotage : Etat de
monotones). Les réseaux à couches Supposent que les neurones sont regroupés en e^'
appelés couches, et que les entrées des neurones de la couche t? sont reliées aux sorties or'
couche n-1. Dans un réseau à zl couches, la première est directement reliée aux capteurs et la
couche /, aux effecteurs. Les couches intermédiaires, appelées couches intemes ou cachées,
servent à mémoriser des états internes. Dans les réseaux entièrement connectés, chaque cellule
est reliée à toutes les autres et possède même un retour sur elle-même'
Notons, cependant, que la granularité particulièrement faible des neurones les place à un
niveau d'abstraction trop bas pour notre étude'
Données d'entréesDonnées de sorttes
f a /I \_-,/
Couche d'entrée(PercePtion)
Couche interne Couche de sortte(Exécution)
Figure I-5 : Réseott de neurones à ffois couches'
t.5. Le contrôte des sysfètnes multi'agents'
Le contrôle tient une place primordiale dans les sMA t5l t6l t17l t56l' En effet' chaque
résolution partieile d,un problème amène de nouveaux éléments de sorution ou en modifie des
anciens. Ainsi, plusieurs actions peuvent donc être possibles et donc entrer en conflit' Le
système doit donc être capable de choisir quelle partie de la connaissance il va appliquer'
1 À
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
quelles données il va traiter et quelles méthodes de résolution il va utiliser. Pour ce faire. il lui
faut pouvoir évaluer les différentes solutions possibles, juger de leur qualité, stopper le
processus de résolution d'un problème ou d'un sous problème pour en considérer un autre et,
surtout, savoir s'arrêter lorsqu'un problème est résolu. La coordination des activités des
différents agents nécessite donc un mécanisme de contrôle très élaboré. On peut en distinguer
deux types : le contrôle centralisé etle contrôle décentralisé.
1.5.1. Le contrôle décentralisé ou distribué.
Ce type de contrôle implique que tous les agents possèdent une certaine autonomie de
décision ; aucun d'eux ne prédomine I l] t36l [40]. Chaque agent travaille de façon
indépendante et peut, à I'occasion, interagir avec d'autres agents (décomposition d'un
problème en sous problèmes). Les agents décident donc seuls de ce qu'ils doivent faire et des
actions qu'ils doivent exécuter. Un tel état de fait implique qu'il faille s'assurer du maintien de
la cohérence de la résolution (c'est-à-dire ne pas s'éloigner du problème, savoir quand la
résolution est terminée). Il est donc indispensable que les informations nécessaires à la
résolution soient, en permanence, communiquées à l'ensemble du groupe. Chaque agent se
doit alors de posséder des informations sur ses collègues afin de connaître leurs compétences
et de pouvoir collaborer. Ceci implique une certaine difficulté quant à I'ajout ou la
suppression d'agents.
1.5.2. Le contrôle centralisé.
Ce type de contrôle implique la présence d'un supentiseur ayant une vue globale des
activités du système tlll t36l [a0]. La diversité de ses connaissances lui permet de planifier
au mieux la résolution de manière dynamique. Il peut, en effet, modifier le comportement du
système en cours de résolution. Son rôle est de distribuer la charge de travail dans le système
25
chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
et de réaliser la synthèse des résultats. L'existence d'un tel module permet de disposer, dans le
système, d'agents qui ne connaissent pas explicitement I'existence des autres et qui ne
s'appellent pas directement. La mise en æuvre du mécanisme de contrôle est donc liée à la
manière dont les agents communiquent.
S'ils communiquent par l'intermédiaire d'un tableau noir, le contrôle est mis en æuvre :
o Soit par un ordonnanceur ou gestionnaire de tâches qui calcule la priorité de chaqueagent activable et sélectionne celui qui a la plus forte priorité.
o Soit par un programme complexe qui focalise sur la solution en se basant sur lesévénements pour savoir quel agent activer.
o Soit par I'intermédiaire d'un tableau noir dédié au contrôle.
o Soit, enfin, par différents types de connaissances : la connaissance stratégique quioriente la solution vers une région du TN et la connaissance concernant les tâchesqui détermine les agents à activer.
Dans le cas où Ies agents ne communiquent pas par I ' intermédiaire d'une base de faits, le
contrôle est mis en æuvre en utilisant la connaissance du savoir-faire des différents agents qui
peut être explicitement ou implicitement décrite dans le système. Il faut donc conserver
I ' indépendance des agents, ce qui dote le système d'un haut degré de modularité ( l 'aiout ou la
suppression d'un agent n'a pas ou peu d'influence sur les aurres agents).
1.5.3. Contrôle des systèmes à tableau noir.
Dans les systèmes à tableau noir, lorsqu'un agent est activé, il prévient le mécanisme de
contrôle des actions qu'il effectue dans le TN en engendrant des événements. Ceux-ci sont, en
fait, des signaux mémorisant les derniers changements du TN mais ne contenant pas
d'informations sur son contenu. Le contrôle (constitué d'une base de règles, d'une base de
faits et d'un moteur d'inférence) peut alors interroger chaque agent afin de savoir s,il est en
mesure de traiter I'information, puis il les classe par ordre de priorité dans une file d'attente
Ill] t36l [40]. Dans certains systèmes, il peut directement sélectionner les agents en fonction
26
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
du but à atteindre. Ensuite, l'ordonnanceur se sert des coefficients attribués à chaque agent
pour sélectionner celui qui donnera la solution la plus fiable (Figure I-6).
Mécanisme de contrô le
Tableau noi r
Figure [-6 : Mécanisme de contrôle dans les systèmes à tableau noir.
1.5.3.1. Contrôle procédural.
Avec un contrôle de type procédural [40], I'ordonnanceur sélectionne la prochaine source
de connaissances à exécuter en fonction du tableau noir et d'heuristiques grâce à son agenda
qui contient les sources de connaissances exécutables et les procédures (Figure I-7). Dans le
même temps, le moniteur détecte les sources de connaissances intéressées par les derniers
changements du tableau noir et les place dans I'agenda (et ceci après chaque activation d'une
source de connaissances). Ce type de contrôle ne convient qu'à des applications où les
connaissances de contrôle sont parfaitement identifiées.
è n e m e n t
27
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
Tab leau no i r
C h a n g e m e n t sd u T N
M o n i t e u r d u t a b l e a u n o i rS C i n t é r e s s é e s p a rl e s c h a n g e m e n t s
A g e n d aS C
E x é c u t a b l e sO r d o n n a n c e u r
Figure I-7 : Contrôle procédural. "
1.5.3.2. Contrôle à base de tableau noir.
Dans un contrôle à base de tableau noir [40] (Figure I-8), les SC de contrôle interagissent et
communiquent à travers le tableau noir de contrôle et les SC du domaine à travers le tableau
noir du domaine. Les SC du domaine construisent la solution dans le TN du domaine et les SC
de contrôle construisent et adaptent le plan de contrôle dans celui de contrôle. Toutes les SC
sont traitées par un ordonnanceur disposant d'un agenda contenant toutes les SC exécutables.
En raison d'un temps d'exécution très lent, ce type de contrôle est déconseillé dans les
applications où le temps de réponse est primordial ainsi que dans celles nécessitant des
évolutions trop fréquentes des stratégies.
II
S é l e c t i o nd e s S C àE x é c u t e r
M é m o r i s a t i o nd e l a S o l u t i o n
C o u r a n t e -- a ) o u r c e s d e \
ryAct iva t ion
28
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
Tab leau no i rd u d o m a i n e
Tab leau no i rde cont rô le
C h a n g e m e n t sd u T N
A g e n d a
So lu t io n P l a n d e C o n t r ô l e
S C à E x é c u t e r
Fipure I-8 : Contrôle à base de tableau noir.
1.6. La communication dans les sysfèmes multi'agents.
La communication est le fondement même de la résolution coopérative de problèmes, car
elle permet la synchronisation d'actions et la résolution de conflits par la négociation. Elle
repose sur des mécanismes d'envoi et réception de messages et des mécanismes de
synchronisation [6] t18l t331.
Un protocole de communication est constitué d'un ensemble de primitives connues par
chaque entité. Les primitives de base sont les suivantes :
o Etablissement d'une connexion entre deux entités.
o Identification du næud destinataire dans un réseau de communication.
. Définition d'un type de communication (synchrone ou asynchrone).
o Envoi de données.
o Réception de données.
Eurnt"*"lD I= i -
E L -
Ë r,xe
= /j---------------
/ ^ ^ , \i 5 L O u O o m a l n e )
29
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
1.6.1. Les différents types de communication.
La communication est un protocole permettant I'envoi de messages pouvant représenter soit
une information, soit une requête ou encore une interrogation. On peut faire la différence entre
plusieurs types de communicarion [18] 136l t5al :
o Communication sélective ou diffusée : contrairement à la communication diffusée.
la communication sélective s'adresse à un nombre restreint d'agents.
t Communication sollicitée ou non sollicitée : communication demandée, ou non, par
un agent.
o Communication avec ou sans accusé de réception : l'émetteur attend, ou non. une
confirmation de réception du message.
o Communication à transmission simple ou répétée : le message peut être répété sur
plusieurs envois.
1.6.2. Les différents modes de communication.
Il existe principalement deux types de communication dans les systèmes multi-agents : la
communication par envoi de message.t et la communication par portage d'information [18)
t rel t36l ts4l .
Communication par envoi de messages : ce mode de communication consiste à échanger
des messages (compréhensibles) entre des agents selon un protocole clairement établi tel que
KQML par exemple. Il faut donc qu'il y ait un émetteur, un ou plusieurs récepteurs et une
information à véhiculer. Le média utilisé dans ce contexte est un réseau local, ou non, e[ un
ensemble d'outils permettant de mieux gérer la communication, tels que les sockets (cf.
$rtr.3.3).
Communication par partage d'information : dans un système où la communication par
partage d'information est implantée, les agents ne communiquent pas directement entre eux
mais par I'intermédiaire d'une structure de données partagée. Cette structure contient
initialement les données du problème et est enrichie au cours de la résolution jusqu'à
30
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
l 'obtention de la solution. Ce mode de communication conespond à I'architecture blackboard
(tableau noir)' Il existe toute une gamme de possibilités allant du tableau noir général, où tous
les agents peuvent voir toutes les informations, au casier confidentiel, où les agents
communiquent via une petite zone mémoire privilégiée.
1.7. Tableau récapitulatif.
On retrouve dans les différents SMA les caractéristiques suivantes : la granularité (degré
de détail des connaissances de I'agent : plus elle est importante, plus I'agent est cognitif.), le
nombre d'agents, le mode de communication, le contrôle, Ie degré de contribution à Ia
résolution etla connaissance du problème gtobal et d'autrui 1401.
J I
Agents
Critères
Réseaux de
neurones
SN
Règles de
production
SRP
Sources de
connaissances
TN
Acteurs,
Objets
SA
Agents
Physiquement
Distr ibués
SPD
Granularité Fine Fine Moyenne Moyenne Grande
Nombre Très grand Grand Moyen Grand Petit
Communication FIux de
données
Base de
faits
Partage
d'information
Envoi de
messages
Envoi de
messages
Contrôle Totalement
distr ibué
Central isé Central isé Distr ibué Distribué
Degré de
contribution à la
résolution
Infime Faible Moyen Moyen Elevé
Connaissance du
problème global
et d'autrui
Absente Absente Absente Moyenne Elevée
TabLeau I-2 : Les sj-stèmes multi-agents.
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
Le Tableau I-2 résume I'ensemble des architectures possibles de SMA parmi lesquelles on
retrouve principalement les réseaux neuronaux, les systèmes à règles de production. les
tableaux noirs,les systèmes d'acteurs et les sysrè mes physiquement distribués.
1.8. Sysfèmes de pilotage et systèmes multi-agents.
D'une manière générale, piloter un système de production fait appel à deux fonctions
distinctes tl0l t43l [aa] tasl t5tl :
' une fonction de gestion a priori (ou planification) dont le rôle est d'assurer laprogrammation d'un ensemble d'actions ou de décisions. Cette gestion est souventrendue nécessaire par I'inertie (où interviennent des notions de temps de fabrication,
changement d'outils etc. ) et la complexité (due à la diversité des ressources et desobjectifs présents et à la complexité des calculs prévisionnels) du sysrèmc deproduction [59].
o une fonction de gestion en temps réel (ou conduite) dont le rôle est de prendre les
décisions qui relève de I'immédiat, c'est-à-dire qui sont motivées par les événements
tiés à l'état courant du système de production. Cette fonction peut être décomposée
en deux sous fonctions : commande et suivi t4l 126) [79]. Ainsi, la fonction
commande est dédiée aux activités de décision d'où résulteront les ordres transmis à
la fonction de suivi. Cette dernière a pour but de gérer I'exécution des ordres au
niveau physique.
Toute la difficulté dans la réalisation d'un système de pilotage réside dans sa capacité à
assurer une cohérence des décisions avec les contraintes imposées :
t par la fonction de gestion a priori. Ces contraintes portent principalement sur les
objectifs ou les décisions.
r par le système physique (panne, retard, etc.).
1.8.1. Architecture des systèmes de pilotage.
1.8.1.1. Prise en compte de I 'ordonnancement prévisionnel.
Avant de pouvoir qualifier un système de pilotage, il est nécessaire de savoir s'il existe un
) L
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
ordonnancement prévisionnel. La définition d'un tel ordonnancement est donnée par parunak
[64] : "un ordonnancement est un sous-ensemble du produit cartésien Quoi*Où*euand pour
un sous-ensemble de I'ensemble des tâches à réaliser". Dans notre propos, une tâche est une
phase d'une gamme opératoire.
On peut alors définir trois types de pilotage [82] :
o le pilotage sans ordonnancement prévisionnel : les allocations se font en temps réel
et de manière dynamique au fur et à mesure de l'évolution du système de
production. Il s'agit d'une approche relativement récente et qui fait I'obiet de
nombreuses études.
o Le pilotage à ordonnancement prévisionnel partiel : seule une partie des tâches à
réaliser sont planifiées a priori. Les autres sont allouées dynamiquement. Cette
approche est actuellement assez bien développée.
o Le pilotage à ordonnancement prévisionnel total : toutes les tâches à réaliser sont
allouées en amont du système de pilotage. Ii y a quelques années. il s'agissait du
seul type d'ordonnancement implanté en industrie.
1.8.1.2. Les architectures de pi lotage.
Plusieurs approches différentes ont été utilisées pour concevoir les architectures des
systèmes de pilotage [82] Nous les passons en revue dans la suite :
1.8.1.2.1. L'approche central isée.
Il s'agit de I'approche la plus classique et la plus ancienne. Elle est caractérisée par un
pilotage centralisé par un seul module (Figure I-9). Ce module unique a pour rôle de
superviser la production et de gérer en temps réel les événements qui peuvent survenir dans le
système composé de plusieurs ressources (moyens de production).
Cette approche peut servir de base à I'implantation de systèmes de pilotage avec n'importe
lequel des trois types d'ordonnancement :
ordonnancement prévisionnel total,
sans ordonnancement prévisionnel [23] [58] [60],
a
a
J J
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
o ordonnancement prévisionnel partiel [77].
Figure I-9 : Architecture centralisée.
1.8.1.2.2. L'approche hiérarchisée.
De nombreuses études ont été réalisées pour ce rype d'approche ill t3l t4l t26l t37) l7g).
Dans ce type d'approche, la notion de niveaux d'abstraction permet de modéliser une usine
complète (Figure I-10). Chaque niveau a des relations de dépendance avec le nlveau supérieur
et des relations de dominance par rapport aux niveaux inférieurs. Les niveaux d'abstraction
uti l isés sont typiquement ceux définis dans l 'architecture dite architecture NBS ' l47l faisant
in terveni r les n iveaux su ivant :ent repr ise, us ine, a te l ier , ce l lu le , poste, machine t l0 ] t43] .
Atel ier
Ce l l u l e
Poste
Machine
Figure I-10 : Architecture hiérarchisée.
Jusqu'ici, cette structure n'a été utilisée que dans des cas de systèmes à ordonnancement
prév is ionnel par t ie l t l3 l t55 l t801.
' National Bureau of Standards (mainrenant NITS).
34
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de I'art.
1.8.1.2.3. L'approche coordonnée.
Cette approche est basée sur l'approche hiérarchisée. La différence est que dans cette
approche, on perrnet I'existence d'une coopération au sein d'un même niveau (Figure I-l l).
Figure I-l I : Architecture coordonnée.
Théoriquement, cette structure accroît la capacité de décision de chaque niveau. Cependant.
une tel le approche impose la présence d'un contrôle part icul ier qui soit en mesure d'assurer la
cohérence des décisrons.
En général, cette approche est uti l isée avec un ordonnancement prévisionnel part iel [ .1]
t48l t661.
1.8.1.2.4. L'approche distr ibuée.
Cette approche est basée sur une distribution complète de Ia décision sur un ensemble
d'agents t12l t l5l I16l [31] t65l tTl l 1741. Le contrôle d'une tel le architecture [34] est
particulièrement complexe en raison de sa modularité (FigureI-12).
Figure I-12 : Architecture distribuée.
Cette approche est utilisée sans ordonnancement prévisionnel t8l t28l l29l t3l) 14611791.
35
Chapitre I : Les systèmes multi'agents et leurs applications au pilotage : Etat de l,art.
1.8.1.2.5. L'approche distribuée supervisée.
Dans cette approche, on ajoute un superviseur à la méthode distribuée. Le rôle de ce
superviseur est de conseiller, modifier, voire imposer une décision. L'avantage est de faire en
sorte que le superviseur ait une vision plus globale du processus (Figure I-13).
Figure I-l3 : Architecture distribuée supervisée.
Cette approche est souvent uti l isée sans ordonnancement prévisionnel127) [50] [5g]. ou
avec un ordonnancement prévisionnel partiel Ig2].
1.9. Conclusion.
Les principaux problèmes des systèmes multi-agents reposent sur la coopération cles agents
entre eux et le degré de confiance que I'on peut accorder aux résultats obtenus. En effet, ils
doivent coopérer sans se gêner, ce qui implique une notion de priorité afin de gérer au mieux
I'ensemble des agents et de leur éviter d'effectuer deux fois la même opération. Il faut ensuite
rester critique par rapport aux solutions proposées, car deux sources de connaissances
différentes, par exemple, pourront avoir des solutions qui divergent (ceci pouvant être dû à la
diversité des informations, à leur incertitude et à leur évolution dans le temps). Il faut donc
attribuer des coefficients de validité aux solutions. Ces coefficients permettent de savoir à
quel point une solution est acceptable et dans quelle mesure on peut lui faire confiance. Ces
coefficients sont calculés en fonction de paramètres propres à chaque système. Comme
expliqué en annexe l, ARCHON fait partie de ces systèmes visant à faire coopérer plusieurs
36
Chapitre I : Les systèmes multi-agents et leurs applications au pilotage : Etat de l,art.
systèmes initialement non-coopérants. Cela est rendu possible grâce à un gestionnaire de
communications de haut niveau, à un modèle des compétences des autres et de soi, et à un
système de planification et de coordination. Le développemenr de protocoles de négociation,
issue de Ia coopération entre agents, est un domaine actif de recherche. Ceta sert
principalement pour les SA et les SPD dans lesquels les agents doivent négocier entre eux
pour coopérer.
Certains systèmes essaient de contourner le problème de la coopération entre agents en
optant pour une architecture hiérarchisée et en créant des modules indépendants qui se
contentent de gérer leur domaine d'activité, en fonction des ordres reçus, et de rendre compte
de leurs actions à un superviseur qui gère I'ensemble du système. Cela permet également de
ne pas perdre de temps à demander leur avis à plusieurs agents-et à comparer leur solution.
C'est I 'approche retenue dans le projet SYROCO tl l t3l (SYstème Réactif par Objecti f de
COnduite), système réactif, modulaire et configurable de pilotage d'atelier que nous décrirons
dans cette thèse. SYROCO peut, r, priori, s'adapter aux besoins spécifiques des PMI-PIvIE
c'est-à-dire à tout type de système à production discrète. En effet, ce système créée et
configure des modules (agents Cellules, agents Produits et agents Ressources) en fonction de
la production et de ses aléas (pannes, commandes urgentes, etc.). Une fois la production
terminée, Ies modules sont soit détruits, soit désactivés. Ce système perrnet de gérer les
problèmes en temps quasi-réel grâce à une architecture très hiérarchisée et à un module de
décision unique, le superviseur. Le choix d'un SMA va donc dépendre de la nature exacte du
type de travail à effectuer. On choisira alors en conséquence le type d'agents (cognitifs,
réactifs ou hybrides), les relations inter-agents (négociation, compétition, coopération, etc.), le
protocole de communication, la façon de répartir les connaissances et le savoir-faire, la
formulation, la décomposition et I'attribution de problèmes, et le système de contrôle.
5 t
CHAPITRE II
MODELISATION DE L'ARCHITECTURE DEPILOTAGE REACTIF
J 6
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
ll. Modélisation de l'architecture de pilotage réactif.
/l.1. lntroduction.
Dans ce chapitre, nous allons nous attacher à la description de SYROCO et de tous ses
composants. Ainsi, la base de I'architecture, à savoir un système multi-agents, sera choisie et
étudiée en fonction de nos besoins. Les différents agents ainsi que les communications qui les
relient seront développés et spécifiés de manière théorique. Nous nous intéresserons aussl aux
différents outils utilisés par le système dans sa version actuelle. Outils dont l'étude ici n'est
donnée qu'à titre indicatif, sachant qu'ils sont interchangeables en fonction de I'application
considérée. Cependant, pour une meilleure compréhension du système, il nous a paru
opportun de les faire figurer ici et d'en donner la description.
1l.2. Structure conceptuelle.
11.2.1. Type du système multi-agents retenu.
Le choix d'un type de système multi-agents s'est révélé comme I'un des plus ardus que nous
ayons eus à faire. En fait, chaque système allie avantages et inconvénients en propotlions
quasiment égales. Bien sûr, certains systèmes furent éliminés d'emblée. Les tableaux noirs,
I'tA Distribuée et les systèmes à règles de production furent écartés, car trop complexes et pas
assez rapides pour I'application qui nous intéresse. En effet, pour obtenir un système de
pilotage en temps réel, il nous fallait choisir une plate-forme dont les temps de réponse soient
Ies plus efficaces possibles.
Logiquement, s'est donc imposée Ia nécessité de définir une nouvelle plateforme qui
emprunterait aux systèmes existants les avantages qui nous intéressent en essayant, autant que
possible, de s'affranchir des inconvénients.
Nous avons donc repris I'idée de la distribution physique des agents, afin de pouvoir
39
chapitre tr: Modélisation de I'architecture de pilotage réactif.
exploiter les ressources informatiques d'un réseau d'ordinateurs, plutôt que de surcharser une
même machine.
Du système d'acteur, nous avons repris la notion d'échange de messages, afin de pouvoir
concevoir. une plateforrne communiquante de manière efficace et rapide.
Une telle base nous a conduit, de facto, à proposer un système fortement modulaire. Nous
nous sommes donc attachés à pousser à I'extrême cette modularité afin de pouvoir, sans
problème majeur, interchanger les modules en fonction du domaine d'application. pour
I'instant, et tout au long de cet exposé, nous nous sommes fixés comme domaine d'action le
pilotage d'un atelier manufacturier.
Comme nous ne pensions pas que des agents coopérants ne nous permettraient pas
d'obtenir la rapidité désirée, le système de contrôle fut plus simple à choisir. En effet, instaurer
un système de question-réponse entre les agents implique, de la part de chaque agent. trois
actions :
o Question,
o Reflexion,
r Réponse,
plus une décision d'arbitrage de la part du contrôleur. Alors qu'avec une hiérarchisation du
système, nous n'avons plus que deux types d'action :
o Réflexion.
o Commande,
de Ia part du contrôleur, d'où une simplicité accrue du système et un gain de vitesse
évident.
Partant de ce précepte, un système de contrôle centralisé et hiérarchique s'est donc imposé.
Restaient à définir les agents. Allions-nous utiliser des agents cognitifs, réactifs ou
hybrides ? L'analyse de la "partie basse" du système (Cellule, Produit, Ressource) fait
apparaître que ces agents n'ont nul besoin d'intelligence poussée. Seule importe leur réactivité
40
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
face à des événements parfaitement connus et, donc, modélisables. Pour ces agents, la
principale caractéristique du cahier des charges était la vitesse de réaction. Le choix s'impose
donc de lui-même : des agents réactifs de faible granularité sont tout à fait aptes à remplir
cette mission.
Pour ce qui est de la partie "haute" du système de commande (contrôle et réflexion), des
agents réactifs ne pouvaient, bien évidemment, pas être utilisés. Cependant, des agents
purement cognitifs, utilisant les techniques classiques de I'IA (bases de faits et de règles et
moteur d'inférence) voire les techniques de tableaux noirs, nous semblaient trop gros et trop
sophistiqués pour ce que nous avions à en faire.
Notre choix s'est donc porté sur des agents hybrides, alliant la rapidiTé de la réactivité pour
répondre à des demandes prévisibles et modélisables à la faculté de réflexion afin d'être
capable de répondre à des événements aléatoires tels que les aléas de productions. En fait, nos
agents ne disposent pas de toutes les caractéristiques des agents cognitifs et réactifs, en
part icul ier i l leur manque la fonction d'historique, Cependant, ces agents sont en mesure de
répondre de manière automatique à certains stimuli et de rechercher une solution aux
problèmes non triviaux. De plus, ces agents ont une connaissance totale de I'environnement et
de la globalité du problème. En cela, nous pouvons dire qu'ils sont à la fois cognitifs et
réactifs, donc hybrides.
Pour résumer, nous nous sommes donc dirigés vers une plate-forme distribuée, fortement
hiérarchisée, munie d'agents purement réactifs et hybrides. Notons que la hiérarchisation du
système recouvre une notion directionnelle. En effet, par hiérarchie nous entendons que les
ordres sont donnés par la tête de la structure et exécutés, sans contestation possible, par la
base.
Le tout communique par le biais d'un réseau de communication, de type étoile, par envoi de
messages etlou par partage d'information réalisé au moyen de boîtes aux lettres.
4 l
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
/,1.2.2. Une nouvelle approche.
Les approches précédentes de système de pilotage réactif d'atelier se classent en fonction de
I'utilisation, ou non, d'un ordonnancement préalable. Il ressort de cette étude que I'usage
exclusif d'un ordonnancement préalable total peut conduire à I'utilisation de systèmes rigides,
peu réactifs et peu évolutifs. Le principal problème, dans ce cas, réside dans la difficulté de la
gestion des aléas. La plupart des systèmes sont forcés de passer dans un mode de
fonctionnement dégradé. Les premières solutions, utilisées pour palier à cet inconvénient,
furent de ne pas utiliser d'ordonnancement préalable et de I'effectuer en temps-réel. Une telle
approche conduit, de facto, à I'emploi de systèmes coopératifs et distribués. L'allocation
Quoi*Quand étant réalisée à la demande au temps courant. Ces systèmes se révèlent plus
souples, mais demandent des temps et des protocoles de négociation importants. Les dernières
recherches en date réintroduisent un organe de supervision dans les systèmes et effectuent un
ordonnancement prévisionnel partiel 1421. Le but recherché par ces systèmes hybrides est de
permettre d'accélérer la résolution des problèmes les plus ardus. En effet, I'ordonnancenrent
partiel permet de fixer, a priori, les tâches allouées aux ressources goulots ce qui a pour
résultat d'éviter une négociation difficile. D'autre part, I'adjonction d'un superviseur au
système pennet de garder I'objectif global en vue et d'imposer aux agents coopératifs
I'utilisation de telle ou telle règle de fonctionnement afin qu'ils ne s'écartent pas de cet
objectif.
Ces systèmes présentent de bons résultats, mais il nous a paru plus logique, en poussant la
thèse précédente à son paroxysme, de revenir à des structures plus rigides et plus robustes
pour le pilotage d'atelier. C'est pourquoi nous avons décidé d'utiliser un ordonnancement
prévisionnel total et une architecture hiérarchique. Cependant, afin de ne pas retrouver les
problèmes inhérents à cette organisation, nous avons décidé que notre ordonnancement
. 1 1
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
pouvait être sujet à modifications. En d'autres termes, nous utilisons un ordonnancement
prévisionnel total au début et des ordonnancements prévisionnels partiels en cours d'exécution
de l'application.
D'un autre côté, afin de faciliter autant la prise de décision que le pilotage en lui-même,
nous avons choisi une architecture hybride qui se place entre les architectures centralisée et
hiérarchisée. En effet, la commande est centralisée alors que la conduite est hiérarchisée.
Parunak $al a caractérisé les problèmes soulevés par un ordonnancement prévisionnel
total et une architecture centralisée/triérarchisée. Nous pouvons revoir cette caractérisation et
étudier les avantages apportés par notre approche doublement hybride (c'est-à-dire placée
entre deux types d'architecture et d'ordonnancement) :
. "desirability" : il est possible, avec cette approche, de prendre en compte les désirs
des responsables de la production (en adaptant la philosophie d'ordonnancement) et
les contraintes réelles.
o "Stochasticity" : nous pouvons prendre en compte les aléas de manière simple. I l
nous suffit d'effectuer un ordonnancement partiel concemant les tâches af-fectées
par I'aléa. Bien sûr, cela remet en cause une partie de I'ordonnancement total.
. "Tractability" : le calcul de I'ordonnancement est toujours NP-complet.
o "Chaos" : les conséquences d'une décision sont peu prévisibles et cel les d'un
événement ne Ie sont pas du tout. On peut, cependant, y remédier en établissant un
fichier historique des erreurs.
o "Decidability" : le fonctionnement du système est complexe. Cependant, un bon
formatage des messages de compte-rendu permet une bonne compréhension des
phénomènes et, donc, une bonne décision.
Il nous est donc apparu qu'en utilisant un système hybride centralisé/Ïtiérarchisé avec un
ordonnancement préalable total/partiel et une distribution de la localisation informatique des
agents, nous pourrions réaliser un système de pilotage réactif d'atelier, robuste, rapide et
f iable.
Le Tableau tr- l récapitule les architectures des systèmes de pilotage et les types
+ J
chapitre tr : Modélisation de I'architecture de pilotage réactif.
d'ordonnancement utilisés :
Architecture Type d'ordonnancement
CentraliséTotalPartiel [77]Sans [60] [581
Central iséÆIiérarchiséTotalÆartiel (SYROCO)Hiérarchisé Part ie l l80l l55lCoordonné Partiel l-481 l66lDistribué Sans f8l I28lDistribué Supervisé Partiel [82]
Sans f50l
Tableau II'l : Récapitulatif des architectures des systèmes de pilorage.
Cette approche nous a amené à la conception d'un système "clés en main" permettant de
gérer les différents outils nécessaires à la gestion du problème et de mettre en ceuvre une
réactivité en temps réel af in de pouvoir résoudre un problème extérieur à tout moment et en
un temps min imum.
En nous basant donc sur Lrn système mult i-agents tel que défini auparavant, nous avons
développé une architecture communicante mettant en ceuvre des agents réactifs et hybrides
(Figure tr- l). En effet, i l existe dans ce sysrème deux types d'agents principaux :
Les agents hybrides (cognit i fs et réactifs), sièges des prises de décision er du
commandement du système. Les deux agents de ce type présents dans le système sont : le
Superviseur2 dont le rôle est de diriger le système et de prendre les décisions et le Méta-Objet
qui s'occupe de la gestion d'outi ls extérieurs dans le but de créer des agents en fonction du
produit à réaliser.
'Les mots dactylographiés comme suit : Superviseur définissent des agents du système.
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
Système de prodrrftion
'artle
AgentsCognitifs
+Cormandeil t ' \
/ Agents Agents Agents
/ nàctifs Réactifs Réactifs
/r+\/ \
SYROCO
RessourcesRéelles
Figure II-l : Structure générale de SYROCO.
Les agents réactifs (Cellule, Produit et Ressource) qui, comme leur nom I ' indique,
exécutent les ordres et rendent compte de leur exécution. Un peu comme dans une hiérarchie
mrlitaire, il leur est impossible de passer outre un étage de hiérarchie, et les agents de grade
supérieur doivent être tenus informés du bon déroulement des actions commandées. De
même, une demande de renseignement devra être remplie sine die. Ces trois agents sont
disposés hiérarchiquement et ont des rôles complémentaires mais différents. L'agent Cellule
est dédié à la gestion d'un îlot de fabrication dont le but est de réaliser un produit dont la
gamme opératoire est contenue, dans ses moindres détails, dans I'agent Produit. Agent que la
Cellule consultera régulièrement afin d'obtenir les informations de fabrication qu'elle
transmettra à I'agent Ressource concerné. Ce dernier enverra des comptes-rendus précis et
réguliers à I'agent Produit afin que Ie système soit tenu au courant des dernières évolutions de
la production.
PartieOpérative ,
RessourcesRéelles
RessourcesRéelles
 <
chapitre II : Modélisation de I'architecture de pitotage réactif.
11.2.3. Architecture conceptuelle.
11.2.3.1. Introduction.
Le premier fait notable est que ce système présente des agents de granularité et d,espérance
de vie différentes, ce qui en fait sa spécificité. En effet, les agents superviseur et Méta-objet,
qui sont les agents hybrides, ont une durée de vie a tras long terme : ils ne sont pas
sLlsceptibles de disparaître. Par contre, les agents celtutes, produits et Ressources. soit les
agents réactifs, ont une durée de vie beaucoup plus courte qui est dépendante de la production
en cours' Ils ne sont créés etlou exécutés que, et uniquement, si nécessaire. Ce qui évite
d'avoir à prendre en compte des agents qui n'interviennent pas dans la production en cours.
En fait, nous pouvons dire que ce système est centré sur le produit et que ses composanrs
sont créés en fonction du ou des produits fabriqués à I'instant r.
Bien entendu, ceci suppose une approche Technologie de Groupe (TG) (cf. annexe 2) du
problème, vu que I 'on décompose l 'entreprise en une suite de sous éléments (usines, atel iers,
îlots"') et que I'on s'arrangera, dans le cas présent, pour que les flux matières soient optimisés.
Bien entendu, tout autre style d'optimisation est envisageable. II suffit alors de chanser I'outil
d'optimisation concerné.
De plus, notons que les îlots que nous manipulons sont totalement virtuels et n'existent que
le temps d'exécuter une gamme particulière.
Autre particularité de ce système, il permet de n'avoir besoin que d'un minimum de
protocoles de communication. Ce, en raison de sa hiérarchisation poussée et d'une parfaite
modélisation des messages, effectuée dès la conception. En effet, les échanges possibles sont
prévus et modélisés : il n'existe pas dans SYROCO de possibilité qu'un agent envoie un
message inconnu ou qu'il s'adresse à des agents autres que ceux avec lesquels il doit
communiquer.
40
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
Enfin, nous ne faisons pas intervenir de concurrence entre agents : ceux-ci ne discutent pas
entre eux et ne négocient pas, ils se contentent de gérer leur domaine d'activité en fonction des
ordres reçus et de rendre compte de leurs actions.
11.2.3.2. Position du système.
Le système SYROCO se place au niveau du très court terme, soit entre la fonction de
planification (MRP ou autre) et I'atelier physique. Ainsi, il trouve dans les objectifs de
production ses données d'entrées et ordonne en sortie aux ressources réelles d'effectuer teUe
ou telle tâche.
Des objectifs de production, nous ne retirons que des données concernant :
o le nom du produit à fabriquer,
o le nombre d'exemplaires à fabriquer (le flux du produit),' '
o la date l imite de l ivraison,
o la date optimale pour commencer la fabrication (calculée par la planif ication). A
défaut, cette date est assimilée au temps courant,
o la prionté du produit, calculée par la planification.
La méthode de planification employée (PERT, MRP ou autre) nous importe peu du
moment que nous avons ces données.
Les autres informations dont a besoin le système en entrée sont contenues dans des fichiers
binaires. A terme, ces données seront accessibles directement grâce à une base de données
orientée objets. Il s'agit de :
o La localisation physique des ressources (exprimée à I'aide de la position de leur
centre de gravité),
o les gammes standards des produits à fabriquer, c'est-à-dire la liste des types de
ressources devant être utilisées lors de la fabrication.
o I'agenda d'occupation des ressources de I'atelier, c'est-à-dire la charge des ressources
en fonction du temps. Bien sûr, cet agenda est modifié dynamiquement par le
système au cours du temps.
^ 1
chapitre tr: Modélisation de larchitecture de pilotage réactif.
11.2.3.3. Les agents préconisés.
* L'agent Méta-Objet.
Son rôle est de créer des agents Produits en fonction des objectifs de production à atteindre.
ces objectifs de production sont la représentation des opérations à effectuer dans l,enrreprise,
classées séquentiellement et munies d'un coefficient de priorité. plus simplement, il traite
toutes les gammes devant être effectuées. Pour cela, on fait appel à un outil de recherche de
chemin dans I'atelier, nommé optigam (cf. annexe 3). Le rôle de cet outil est de transformer
les gammes standards en gammes atelier. Pour cela, il consulte l'agenda des ressources qui
regroupe leurs plages d'occupation, ce qui lui permet de choisir les ressources libres aux temps
considérés, phase par phase. Une fois les résultats produits par I'outil et I'agenda modifié en
fonction des nouvelles occupations, le Méta-Objet utilise ces données afin de créer le
programme source des agents Produits correspondant aux gammes traitées. Cet agent
n' intervient pas dans le déroulemen[ "normal" du système, i l n'agit qu'à la création du systèrne
ou lors des re-configurations ultérieures. I l n'agit jamais sur sa propre init iat ive mais
uniquement sur requête du superviseur. Du point de vue du système, il s'agit d'un processus
automatique tant qu'il est question de re-configurations liées à la production (commandes
urgentes, pannes...) et semi-automatiques en cas d'une modification des stratégies de
production. Il fournit un code source différent pour chaque agent produit en fonction de la
gamme à exécuter. Ainsi, dans cette optique,'le système ne demande une intervention directe
de I'utilisateur que lorsqu'une nouvelle stratégie de production est adoptée dans I'entreprise.
* L'agent Superviseur.
Son rôle est de contrôler le processus de production dans I'atelier. Il scrute en permanence
l'état du système tant par le "haut" (objectifs de production) que par le bas (ressources réelles,
via les agents). De ce fait, il est capable de réagir dès qu'un problème se présente. Ainsi, en
cas de commande urgente, il ordonnera au Méta-objet d'insérer cette commande dans la
4 8
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
production et en cas de panne matérielle, il demandera une re-direction du produit concerné. Il
ordonne donc la création etlou la destruction, si nécessaire, de nouveaux agents Produits. Il
permet aussi de superviser les différents agents Cellules qui ne peuvent communiquer entre
eux que par son intermédiaire. Ainsi, seuls les agents intéressés par une information donnée la
reçoivent. Il reste le seul maître du système. C'est lui qui instanciera les agents Cellules ce qui
signifie qu'il s'occupera de leur exécution.
* Les agents Cellules.
Exécutés sur ordre de I'agent Superviseur, Ieur rôle est de gérer les îlots virtuels de
production. Les agents Cellules rendent compte à I'agent Superviseur et reçoivent les ordres
de lui, et uniquement de lui. Ces agents ne communiquent pas entre eux. Les agents Cellules
gèrent les agents Produits d'où ils tirent les informations sur la gamme et sur l'état des
ressources. Notons que les agents Cellules sont parfaitement indépendants les uns des autres.
* Les agents Produits.
Créés par l'agent Méta-Obiet en fonction des objectifs de production, ils définissent les
ressources utilisées dans I'agent Cellule ainsi que I'enchaînement des opérations à réaliser. De
même, ils connaissent les temps théoriques de fabrication et peuvent donc émettre des
messages d'alerte en cas de dépassement. Ils font fonction de mémoire de I'agent Cellule. Leur
rôle est de signaler à I'agent Cellule l'état d'avancement de la gamme, et indirectement les
ressources libérées, qui pourront être ré-affectées à un autre agent Produit. De même, ils
signalent les problèmes divers tels qu'une panne ou un dépassement du temps prévisionnel de
fabrication.
* Les agents Ressources.
Ils rendent compte aux agents Produits de leur état (libre, occupé, hors service... ) et du
temps estimé durant lequel ils resteront dans un état donné et transmettent à la partie opérative
les ordres de production. Un même agent Ressource peut être partagé entre plusieurs agents
19
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
Produits, c'est-à-dire plusieurs agents Cellules mais pas au même instant r. Cet agent
Ressource est le lien entre le monde abstrait (monde informatique) et le monde réel (monde
physique). Son degré de complexité dépendra de la partie réelle. En effet, dans le cas où les
postes de travail sont dits "classiques" (c'est-à-dire non intelligents), I'agent Ressource
s'occupera de la prévision des temps et demandera aux opérateurs de le renseigner
régulièrement. Par contre, si les postes de travail sont pseudo-intelligents (c'est-à-dire capables
d'effectuer un certain nombre d'opérations en internes et de rendre compte), alors I'agent
Ressource ne sera plus qu'une simple passerelle entre le monde réel et le monde abstrait. Quoi
qu'il en soit, pour I'instant, il existe un agent Ressource pour chaque ressource réelle. En effet,
à chaque ressource de I'atelier conespond un agent spécialement développé. Ces agents ne
sont pas interchangeables, car chacun d'eux dispose des spécificités de sa ressource
uniquement. Cependant, tous les agents Ressources sont construits sur le même modèle et une
partie de leur source est générique.
11.2.3.4. Les échanges d' informations.
Les échanges d'informations sont la base même de ce système. De par sa hiérarchisation,
les communications y sont extrêmement bien définies au moyen de messages. Le système de
communication est le squelette de l'application et tout est, en fait, géré par le biais de serveurs.
En effet, nous nous sommes appuyés sur des échanges de type client/serveur, chaque agent
étant un client communiquant avec Ies autres agents grâce à des requêtes adressées à un
serveur qui tes répartira vers les agents concernés. L'avantage de ce système est que le dit
serveur peut se trouver sur la même machine ou sut une machine distante sans que cela fasse
la moindre différence, si ce n'est un temps de réponse légèrement plus long en raison du taux
de transfert des données par le réseau.
)U
Chapitre tr : Modélisation de I'architecture de pitotage réactif.
11.2.3.4.1. La communication
Les communications échangées dans le système sont de quatre types différents :
o Les ordres: qui sont les directives transmises par un agent de niveau supérieur à un
agent de niveau inférieur. Notons que lorsqu'un agent donne un ordre à un autre,
celui-ci ne peut s'y soustraire. Il se doit de I'exécuter sur-le-champ.
o Les consultatiorcs : de manière générale, lorsqu'un agent consulte, il va, de lui-
même, chercher I'information qu'il désire dans les données disponibles de I'agent
consulté.
o Les comptes-rendus : qui sont, à I'inverse d'une consultation, des informations
fournies par un agent à un autre agent. Généralement, le flux se fait dans le sens
inférieur vers supérieur. Les comptes-rendus se doivent d'être précis et opportuns. Il
est, en effet, inuti le de signaler que tout va bien.
o Les requêtes: qui sont des demandes d'un agent à un autre. En fait, i l n'y a, pour
I ' instant, qu'un type de requête dans le système. I l s 'agit de Ia demande du
Superviseur au Méta-Objet de générer un(des) nouvel(eaux) agent(s) Produit(s).
Bien entendu, ces informations doivent être les mieux documentées et les plus concises
possible.
11.2.3.4.2. Les messages.
Ainsi, i l existe pour chacun de ces types de message, excepté la requête, plusieurs
catégories différentes : trois ordres, quatre consultations, trois comptes-rendus. Cette
classification est fonction de l'émetteur et du récepteur du messase.
1L2.3.4.2. l . Les ordres.
Les ordres vont tous du haut vers le bas de la structure et s'enrichissent à chaque niveau.
C'est grâce à eux que les décisions, prises par la tête de la pyramide, sont transmises à
I'exécutif. Les trois classes d'ordres sont les suivantes :
o L'ordre I est donné par le Superviseur aux agents Cellules. Ce message est lancé
chaque fois qu'il est nécessaire de lancer une nouvelle production. La date de
5 l
Chapitre tr: Modélisation de I'architecture de pitotage réactif.
lancement est déterminée en fonction du temps de réalisation du produit et de la
date butoir à laquelle I'entreprise doit le livrer. Cet ordre ordonne donc aux Celtules
de commencer la production dont elles ont la charge. Cependant, aucun détail de
cette production n'est fourni. En effet, les Cellules sont créées que, et uniquement,
dans le but de gérer une production bien particulière. Aussi, il n'est pas nécessaire
de spécifier dans I'ordre quelle est la première étape de la fabrication.
o L'ordre 2 concerne les agents Ressources. Il est émis par les Cellules. Par ce type de
message, les Cellules ordonnent aux Ressources de commencer un usinage
particulier. En d'autres termes, il s'agit de commencer une phase de la gamme du
produit géré par la Cellule. Bien entendu, cette fois le message contient un peu plus
de renseignements. Les Ressources étant partagées entre plusieurs produits et donc
plusieurs Cellules, i l convient que chaque ordre qui leur est adressé contienne le
nom du produit à réaliser et le numéro et/ou la description de la phase de la gamme
considérée. Ainsi, chaque fois qu'une phase est f inie, I 'agent Cellule ordonne à la
Ressource suivante de commencer à usiner la phase suivante.
o L'ordre 3 est, en quelque sorte, une copie de I'ordre deux. Il s'adresse à la ressource
réelle, c'est-à-dire la ressource physique qui existe dans I'atelier. Il est produit par
I'agent Ressource qui lui correspond. Sa formalisation sera différente en fonction de
la configuration de la partie réelle. En effet, s'il s'agit de ressources "classiques",
c'est-à-dire ne sachant pas communiquer avec I'extérieur de manière automatique,
cet ordre ne sera qu'une copie de I'ordre 2 transmise à I'opérateur de la dite
ressource par le biais d'un écran ou de tout autre moyen à la convenance de
I'entreprise (fiche de fabrication, messagerie de type "tam-tam" etc.). Par contre, si
la ressource est instrumentée et qu'elle peut être directement reliée à un réseau, rien
n'interdit Ia transmission directe de I'ordre en I'enrichissant de données utiles telles
5 2
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
que le programme CN adapté, la gestion des outils, voire même, des modifications à
apporter suite aux usinages précédents. Dans tous les cas, il s'agit sans doute de
I'ordre le plus important car c'est par lui que les décisions du système seront
transmises à I'atelier.
I 1.2.3.4.2.2. Les consultations.
Les consultations servent à apporter à un agent les informations dont il a besoin pour
prendre ses décisions ou savoir ce qu'il doit faire. Comme I'agent concerné est le seul à savoir
quand il besoin de ces informations, il décide seul d'aller les chercher où elles se trouvent. Les
quatre classes de consultations sont les suivantes :
o la consultation I concerne le Méta-Objet qui se renseigne auprès de la base de
données orientées objets (BDOO) sur les informations techniques dont il a besoin
pour générer ses agents. Ces informations portent sur les ressources avec des
renseignements sur leur position physique, leur agenda qui représente en fait ler.rr
charge, leur capacité etc. ainsi que sur les gammes standards des produits où sont
définies les étapes nécessaires à leur fabrication. Ainsi, chaque fois que le Méta-
Objet doit générer un nouvel agent Produit, il consulte la base de données afin
d'obtenir ces informations.
r La consultation 2 permet au Superviseur de prendre en compte les changements
intervenus dans Ia production (une nouvelle commande, par exemple) et de les
traiter. Ainsi, régulièrement, le Superviseur vérifie les objectifs de production afin
de s'assurer qu'il n'y a pas de nouveaux produits à fabriquer depuis sa dernière
actualisation. En cas de nouvel objectif, le Superviseur se renseigne sur le produit à
fabriquer et sur sa date butoir de livraison. Une priorité, calculée en fonction du
temps -incompressible- de fabrication et de la date butoir, lui permet :
o d'ordonner le traitement des produits les plus urgents si plusieurs commandes
5 3
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
anivent simultanément.
o de pouvoir déplacer des produits moins urgents si la nouvelle commande n'est
pas réalisable en temps et heure avec [a configuration actuelle de la production.
Cette consultation est la plus importante du système car c'est le point d'entrée
"haut". C'est par ce biais que le système communique avec I'extérieur (en
I'occurrence le service commande ou le chef d'atelier) et, en quelque sorte, prend ses
ordres.
La consultation 3 permet aux agents Cellules de se renseigner sur la gamme et l'état
d'avancement du produit qu'ils ont à fabriquer. Pour cela, les Cellules interrogent les
agents Produits qui gardent en mémoire les étapes de fabrication ainsi que les
temps, et sont informés par les Ressources de l'état d'avancement de la tâche en
cours. Ainsi, chaque fois qu une phase est f inie, ou chaque fois que [a Cettule doit
faire son rapport au Superviseur, el le consulte l 'agent Produit af in de saroir qu'el le
est la prochaine opération ou pour obtenir les derniers renseignements sur la
production dont el le s'occupe.
o La consultation 4. enfin, est, comme la consultation 3, interne au système. Elle
permet au Superviseur de se renseigner sur les dates de début de certaines phases.
Cela n' intervient que lors d'une panne. Le Superviseur a, en et-fet, besoin de
connaître les dates de début des phases qui auraient du se réaliser sur la ressource
défectueuse. Ces informations lui permettront d'indiquer au Méta-Objet à quelles
dates il doit faire commencer les gammes déplacées en raison de la panne.
1L2.3.4.2.3. Les comptes-rendus.
Les comptes-rendus sont, en fait, I'inverse des consultations. Lors d'un compte-rendu,
I'agent envoie des informations à un autre sans lui demander quoi que ce soit. Ce mode de
communication est utilisé surtout pour remonter I'information au niveau supérieur et s'assurer
Chapitretr:Modétisationdel'architecturedepilotageréactif'
qu'un problème est immédiatement transmis et ne doit pas attendre une série de consultations
pourêt repr isencompteet t ra i té 'Lest ro isc lassesdecompte. rendussont :
o | - ecomp te . rendu ipe rme tà la ressou rce rée l l ede fa i r esavo i ràson image
informat ique( l ,agentRessource)sonétatactuel (panne,maintenance,us inageetc. ;
e tp rév i s ionne l 'C ,es ta ins ique l ,onpeu tS ,assu re rqu ,uno rd reab iené tée f fec tué ,
quelestempssontrespectésetc 'Demême,c.estgrâceàcelaqu 'unproblèmeate l ier
serarépercutédanslesystème.Cecompte-renduest ,enfa i t , lependantdel .ordre3.
I ls 'agr tde l ,organepr inc ipa ldecommunicat ionentre lapar t ieopérat iveet lapar t te
commande 'C ,es t cecana lqu ipe rme t l e re tou rdes in fo rma t i onsdans lapa r t i e
commande.
Lecomp te . rendu2es t i n te rnee tn ,es ten fa i t que la t r ansc r i p t i on l i t t é ra l edu
compte-rendul .C,esta ins iquel ,agentRessourcerépercute l ' in format ionauniveau
supér ieu r ,àsavo i r l . agen tP rodu i t , l eque lag rége ra tou tes les in fo rma t ionsvenrn t
des différents agents Ressource et retransmettra le tout à r'agent ce*ure rors de la
consultation 3'
o Le compte-rendu 3 est I'agrégation finale des messages
agents Cellules rapportent au Superviseur' C'est par
Superviseur pourra surveiller Ia production et réagir en
11.2.3.4.2'4. La requête' ' , --a^-r Ànnn la reouête. C'est par ce biais que
Ledern ier typedemessagespouvantêt reéchangéestdonclarequête.C'estp
re superviseur va demander au Méta-obiet de produire le programme source d'un nouvel agent
Produit. Bien entendu, la requête doit comporter des renseignements vitaux tels que le nom du
futur agent produit et re produit dont * devra s,occuper. c'est à partir de ces informations que
re Méta-obiet saura que'es informations consulter dans ra BDoo et pourra' partant de ces
informations, utiliser l,outil de recherche de chemins qui transformera la gamme standard en
de retour du sYstème que les
ces comptes-rendus que le
cas de Problèmes'
5 5
chapitre II : Modélisation de I'architecture de pilotage réactif.
gamme technique. De là, seront extraites les informations qui permettront de produire le
programme source des agents produits (ressources utilisées, temps etc.).
I 1.2. 3.4.2.5. Tableau récapitulatif.
Le Tableau tr-2 récapitule les différents types de messages.
Tableau II-2 : Récapitulatif des messages
11.2.4. Conclusion.
La Figure tr-2 lait apparaître les type de communication et la hiérarchie entre agents et
résume ce paragraphe. Ce schéma permet, en particulier, de montrer et spécifier les relations
et communications inter-agents.
Types Classification Emetteurs Récepteurs Commentaires
ORDRES
Ordre I Superviseur Cellule Commencer uneproduction
Ordre 2 Cellule Ressource Commencer unephase
Ordre 3 Ressource RessourceRéelle
CommencerI'usinage
CONSULTATIONS
Consultation I Méta-Obiet BDOO Informationstechniques
Consultation 2 Superviseur Objectifs deProduction
Informations deproduction
Consultation 3 Cellule Produit Avancement de la.qamme
Consultation 4 Superviseur Cellule Données sur unephase
COMPTES-RENDUS
Compte-rendu I RessourceRéelle
Ressource Etat de laressource réelle
Compte-rendu 2 Ressource Produit Etat de laressource
Compte-rendu 3 Cellule Superviseur Avancement degamme
REQIJETE REOUETE Superviseur Méta-Objet
Demande decréation denouveaux produits
56
Chapitre tr: Modélisation de I'architecture de pilotage réactif.
IPrévisions
IAléas
Consultation -r
Consultat ion I
t lt lt l
-J--l-I lrcta-ouiet k-rd
I
Créat ion
Requête decréation
Consultation 4
Ordre 2
t lt. lr l
Ordre 2 |
| _J_| [ Produit ]u I
lRessource l l- t3"tMJ
Figure II-2 : Schéma de principe de l'architecture SYROCO.
L'architecture de SYROCO apparaît donc comme une architecture fortement hiérarchique
où se mêlent des agents hybrides et des agents réactifs placés à des niveaux hiérarchiques
précis. Les agents hybrides sont chargés de la partie "réflexion" du système. C'est là que sont
tî--r",,-r.r K)ï-
Ordre 3
Définition des obiectifs
Consultation 2
J I
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
prises les décisions relatives aux chemins des gammes et aux dates de début des phases. Ces
décisions sont, par la suite, transmises au reste du système. Nous n'avons pas voulu que le
Superviseur et le Méta-obiet soient uniquement cognitifs et nous leur avons adjoint une part
de réactivité. Ceci, parce que dans le cadre d'un système de pilotage d'atelier, un certain
nombres d'événements sont prévisibles. Il nous a donc paru inutile de laisser les agents
"réfléchir" sur un problème dont on connaît la réponse. C'est pour cette raison que ces agents
ont une part de réactivité et qu'ils sont donc de type hybrides.
Les autres agents (Cellule, Produit et Ressource) sont purement réactifs. Ils ne font, en
effet, qu'exécuter des ordres et réagir à des événements très bien modélisés et connus. La seule
exception vient de I'agent Ressource qui, dans certains cas, peut être hybride. Soit pour
arnéliorer la communication avec les ressources en leur proposant automatiquement les outils
etlou le programme à utiliser, soit dans le but d'en faire un agent générique qui por"rrrait
s'adapter à n'importe quel type de ressource réelle.
L'autre point important de I'architecture est le ciment qui fait tenir toutes ces briques
ensemble : la communication. Celle-ci revêt, en effet, une importance particulière, car elle
seule permet à la partie exécutive de recevoir ses ordres et de renvoyer des comptes-rendus
par la suite. C'est pourquoi il nous a fallu modéliser avec un grand soin les différents messages
échangés dans le système, car se sont eux qui le font progresser. Cela peut facilement être
vérifié en modélisant le système à I'aide d'un formalisme événementiel spécifiant les différents
états dans lesquels il peut se trouver, à savoir le formalisme des Statecharts.
ll1.3. Spécification théorique de I'architecture par les Stafecharts.
11.3.1. Les Statecharts.
Les Statecharts [39] t73l t78l sont des diagrammes d'états utilisés pour modéliser les
5 8
Chapitre tr : Modélisation de l'architecture de pilotage réactif.
différents états que peuvent prendre des systèmes complexes réactifs soumis à des événements
extérieurs et intérieurs, ainsi qu'à des contraintes liées au temps. Ils conespondent à une
amélioration des machines à états, basée sur la hiérarchisation du modèle et sur la
synchronisation d'états évoluant en parallèle. On les représente grâce à des graphes dont les
sommets, représentés par des rectangles arrondis, correspondent à des états du système, et les
arcs à des transitions entre états représentant des actions du système.
11.3.1.1. Concept de hiérarchisation.
La Figure tr-3(1) est la représentation d'un système à trois états A, B et C et quatre actions
a, b, c et d, basée sur une approche machines à états. La Figure f4Q) représente le même
système, mais utilisant une approche Statecharts où on retrouve bien les trois états A, B et C et
les quatre actions a, b, c et, d mais les états A et C peuvent être généralisés en un état global
D. La comparaison de ces deux figures montre bien le concept de hiérarchisation des
Statecharts permettant de regrouper ou d'encapsuler des états, ayant des transitions communes,
dans des macro-états, ce qui allège considérablement le graphique.
Lorsque I'on se trouve dans l'état D, on peut se trouver soit dans A soit dans C mais pas
dans les deux à la fois. La Figure n3Q) peut être représentée d'une manière moins détaillée
comme le montre la Figure tr-3(3). On peut ainsi faire abstractiond'une partie des états d'un
système en évitant de détailler un macro-état.
(A,f=-"Y\ \
i x
+ -XB)
l b Y.t--'. | ./(9*'
(1) Apprcche'machine à états' (2) App toch€ Slatech âfts,
concept de HiéHrchisation
(3) Apprcche Stateùads,
concept d'Abstectiff i
fDl,-\
l (A)
î l '
Figure II-3 : Machines à états et Statecharts.
59
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
11.3.1.2. Concept d'abstraction.
La Figure tr-4(l) donne une représentation plus détaillée de la Figure tr-3(3), mais dans
laquelle on ne sait pas à qui s'adressent les entrées anivant sur l'état D. Pour connaître l'état
auquel elles s'adressent, on effectue une représentation plus détaillée (Figure il- (Z)).
16,---I (A ) f-".t Y l \t i t , \I + f'{B)i l> ' - -i - t - l /I (c) f"'.\Z-J
11.3.1.4. Concept de simultanéité.
On parle de simultanéité entre deux
état. Pour cela, on utilise la fonction IN
(1)
Figure II-4 ' Affinage de la
11.3.1.3. Concept de synchronisation.
On parle de s_rtnchronisation lorsque deux états
au même moment. Dans la Figure II-5, les états X
également synchroniser deux états différents.
(
(2)
r e pré s entation d' é tat.
différents d'un même système sont activés
et Y sont activés simultanément. On Deut
(
(A)x
o(in'
Y(.ry
X
Figure II-5 : Synchronisation et simultanéité.
( C )*----\--,/
o t
/ t l \/n)1 ./'D)\ c Y>--.'/ /( E F--"
états lorsque I'activation d'un état
comme Ie montre la Figure tr-5. On
dépend d'un autre
passe de l'état B à
60
Chapitre tr: Modélisation de I'architecture de pilotage réactif.
l'état A lorsque I'on a la transition b et que l'état E est actif.
11.3.1.5. La fonction historique.
Les Statecharts possèdent également une fonction historique I/ permettant de mémoriser le
dernier état activé d'un macro-état désactivé. Dans la Figure tr-6(l), lorsque l'on rentre dans le
macro-état A, on peut soit se trouver dans l'état B, soit dans l'état C.
\ ,a
( e / ' )\ lA I
I I ô \A II ô \' . v , /
,"f.--' ]ef ,' (ol l
( ^ (i \ (s)
a'T.-..--'^i I I "1rA i , \r (B) \ (D)l - \r9
) - (R) À
(B) \ (D)À
9 ii , / \ u
Figure II-6 : Différentes fonctions.
Si on rentre pour Ia première fois dans A, alors on va dans B, sinon on va dans Ie dernier
état pris par le macro-état avant de le quitter (si on se trouvait dans l'état C avant d'en sortir,
alors on retourne dans l'état C).
11.3.1.6. Les fonctions de condit ion et de sélection.
Tout comme la fonction historique, il existe des fonctions de condition (C) et de sélection
(S) d'entrée dans les états. Dans la Figure tr-6(2), on peut voir que pour entrer dans un des
états du macro-état, il faut, en plus de l'événement "a", une condition qùr départage I'ensemble
des états accessibles grâce à cet événement. Pour ce qui est de la fonction de sélection
(Figure II-6(3)), l'état sélectionné dépend de la valeur de l'événement.
11.3.2. Modélisation du système.
Afin d'alléger ces figures, nous avons dû utiliser des abréviations pour ce qui est des
6 l
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
transitions entre états et dont la liste apparaît ci-dessous (Tableau tr-3) :
Abréviation Sienification Abréviation Sienificationc3 Consultation 3 init Initialisationcf Compte-rendu m Maintenancecr1 Comote-rendu I modif Modification^-.,v t L Compte-rendu 2 nc Nouvelle sammecr3 Comote-rendu 3 o l Ordre Idd Date début o2 Ordre 2f ae Fin traitement asenda p Pannef an l Fin analyse requête ( l) reD Réponsef anT Fin analyse requête (2) rép c Réoonse consultationfé Fin émission rép-dd Réponse date débutf sen Fin eénération d'asent tgq Requêtefp Fin phase sol Obtention d'une solution
f sup Fin suppression
Tableau II-3 : Abréviations utilisées.
Nous nous sommes également servis d'opérateurs logiques dans la formulation des
transit ions lorsque I 'on disposait de plusieurs possibi l i tés pour passer d'un état à un autre. Le
"OU logique" correspond donc au signe posit i f (+), le "ET logique" à un point (.) et la
négation à une barre oblique (slash : /).
11.3.2.1. Le système.
SYROCO étant composé de plusieurs applications s'exécutant en parallèle, il n'est pas
possible de le représenter dans son entier à I'aide des Statecharts. En effet, comme expliqué
précédemment, ce formalisme ne permet que de montrer les différents états d'une même
application et les événements qui permettent les transitions entre ces états. Or, au niveau
général, le système ne change pas d'état, mais communique. Seuls les agents changent d'états
en fonction des communications reçues.
Par conséquent, il est utile de se référer au schéma (cf. Figuren-2) qui fait apparaître les
communications et la hiérarchie entre agents plutôt qu'à un Statechart qui ne serait que peu
significatif. De plus, ce schéma est complémentaire à la description Statecharts dans la mesure
62
chapitre tr : Modélisation de I'architecture de pilotage réactif.
où il permet de montrer et spécifier les relations et communications entre agents.
En ce qui concerne les agents, nous donnons une formalisation sous forme de Statecharts
pour chacun d'eux.
11.3.2.2. Les agents hybrides
11.3.2.2.1. Le Superviseur (Figure th7).
L'état initial du Superviseur est un état d'attente. En effet, il attend l'arrivée d'un message
réseau pour pouvoir le traiter. Il existe deux types de messages possibles : une consultation
des objectifs de production (consultation 2) ou I'arrivée d'un compte rendu (de type 3).
\ \
Interrogation
Méta-ObjetAttente )
I
Ic13
Figure II-7 : Modélisation du Superviseur par les Statecharts.
En cas de compte-rendu et quel que soit son contenu, le Superviseur passe en mode
"modification de I'agenda" afin de tenir celui-ci à jour des modifications transmises par les
agents Cellules. Il repassera en mode "attente" dès la fin de la ré-actualisation dans la plupart
des cas. Seule une panne I 'amènera à consulter (consultation 4) la Cellule émettr ice, puis, à
Superviseur
I/- . .-.____\I bmlssron li consultation ';-f_ag
. p
t_(C"llul")___,
r l
f - ag .p / I/;r.
-r--\
i I raltement ]
\ Agenda )
63
chapitre tr : Modélisation de I'architecture de pilotage réactif.
I'aide des informations reçues, il interrogera le Méta.objet pour qu'il analyse la situation et
propose une nouvelle solution. Enfin, il enverra de nouveaux ordres de fabrication (OF).
Lors de la consultation 2, s'il advient qu'une nouvelle gamme apparaît dans les objectifs de
production, le Superviseur interrogera le Méta-objet afin qu'il la place dans I'atelier et créée
I'agent Produit correspondant puis il enverra I'ordre de fabrication.
Le message "init" est un peu particulier. II ne s'agit pas d'un message réseau, mais d,un
ordre qui intervient lors de I ' init ial isation du système, c'est-à-dire la première fois qu' i l est
lancé. Il provoque une interrogation du Méta-obiet afin de placer toutes les gammes des
objectifs de production dans I'atelier.
11.3.2.2.2. Le Méta-Objet (Figure tl-8).
Méta-Objetl
/ \. \ léta-Objer otï l\_i
,:q
Méta-Objet i, z )
: \Analyse
requête i
I ( n i veau l ; I
f-an I- , 1
j Replacement /Recherche I' UeplAcement + - \ i l | / - - -de chemin
I chemins\_ , . l
\ sol\
. t -sot- , ' \
V an r l r " e i
r-^.-.* -..-_r,
l ueneratlonj d'og.nt, i! l
, {Produi t )
)----rr-
Analyse i ,,.: requête
f,lïYr/
Figure II-8 : Modélisation du Méta-Objet par les Statecharts.
Le Méta-Obiet n'est pas actif en permanence. Seule I'arrivée d'une requête de création du
o4
Chapitre tr: Modélisation de I'architecture de pilotage réactif.
Superviseur le rend actif. Sa première tâche est alors de I'analyser afin d'en connaître les
termes. Ceci fait, il fait appel à l'outil de recherche de chemins (Optigam) qui lui renveffa une
solution. Une deuxième analyse permettra d'extraire de cette solution les informations
nécessaires à la génération d'agents Produits. Une fois I'agent généré, le Méta-Objet se
désactive.
Note : si Optigam est incapable de fournir une solution perrnettant de respecter les délais de
fabrication, le Méta-Obiet passe en mode "ré-affectation" et fait appel à un outil de stratégie
qui modifie le chemin de gammes moins prioritaires afin de pouvoir placer la nouvelle
gamme.
11.3.2.3. Les agents réactifs.
Les agents réactifs étant très proches, nous avons préféré les représenter comme une seule
application, dotée de processus parallèles (cf. Figure tr-9).
Àgents
2creat lon
/création'\-----------
Cel lu le of f i
i iu I t_Sup
l lY I
[1l!j1_i
I
Ressource otT
c-l+c12 f_prod_onI
I
o2 o2+p+fp
. i Ii )
[]i:T" i_j
Figure II-9 : Modélisation des agents réactifs par les Statecharts.
La Cellule (Figuretr-10) est activée au moment ou elle reçoit I'ordrel en provenance du
Superviseur; elle consulte alors le Produit et attend de recevoir une réponse. Dès que celle-ci
est arrivée, la Cellule envoie I'ordre de commencement d'usinage de la phase considérée (ordre
Produit on
65
chapitre tr : Modélisation de I'architecture de pilotage réactif.
de type 2) à une Ressource et se met en attente.
Figure II-10 : Modélisation de la Cellule.
Toutes les minutes paires, elle consulte le Produit afin de se tenir au courant de
I'avancement de la gamme. Si, lors de cette consultation, il n'y a pas de réponse, la Cellule se
remet en attente. Si la réponse est "fin", elle supprime le Produit puis se désactive. Si la
réponse est "fin phase", elle consulte de nouveau le Produit pour envoyer un nouvel ordre
d'usinage à la Ressource suivante. Si la réponse est "compte-rendu", "maintenance", "réponse
date début" ou "panne", la Cellule envoie I'ensemble du message au Superviseur. Une fois
l'émission terminée, elle se remet en attente. Dans le cas d'un message "panne", elle consulte
le nouveau Produit pour pouvoir lancer un nouvel ordre d'usinage. Toute les minutes impaires,
la Cellule consulte le Superviseur ; s'il lui signale qu'il y a eu des "modifications" dans la
gamme, alors elle consulte le nouveau Produit, compare les informations avec les siennes et
juon I P
I Emission
I| ^
,éænr" l-",
\ JuPervtseuf f-_-_.-\_J
f é . o l
66
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
lance un nouvel ordre d'usinage si nécessaire. Si le Superviseur lui demande la date de début
d'une phase, alors elle consulte le Produit et envoie la réponse au Superuiseur dès qu'elle la
reçoit. S'il n'y a pas de réponse, la Cellule se remet en attente.
Le Produit (Figure tr-11) est créé par le Méta-Objet sur ordre du Superviseur. Il est ensuite
activé chaque fois que la Cellule le consulte ou que la Ressource lui envoie le compte-rendu 2.
Lors d'une consultation, il envoie une réponse à la Cellule consultante, et lors d'un compte-
rendu il enregistre le message jusqu'à ce qu'on le consulte. Ensuite, il se désactive jusqu à ce
qu'on le sol l ici te à nouveau.
I Produit I
f o r
Prodult
o n
Produit off
c-1 +cr lI
f\(s)
, / \/ / \C J
. t . ,j Emission
I réponse
t'-lîyl__-
Figure II- l I : Modélisation de I'agent Produit.
La Ressource (Figure IJ-n) est activée sur ordre de la Cellule via I'ordre 2; elle envoie
alors un ordre d'usinage à la ressource réelle puis se met en attente jusqu'à ce qu'un nouveau
message arrive. Lorsqu'elle reçoit le compte-rendu l, elle I'envoie à l'agent Produit concerné
puis se remet en attente, sauf en cas de panne ou de fin de phase, où elle se désactive. Il en va
de même lorsqu'elle reçoit un ordre de la Cellute lui demandant de se désactiver.
67
chapitre tr : Modélisation de larchitecture de pilotage réactif.
Figure II-12 : Modélisation de l'asent Ressource.
11.3.3. Conclusion.
La modélisation des agents à I'aide des Statecharts montre qu'il s'agit bien de modules
événementiels. Les messages échangés provoquent, lors de leur arrivée, un changement d'état
du module auquel ils sont destinés. Les événements de notre système sont donc caractérisés
par les messages. Ceci renforce l'importance de la communication dans SYROCO.
La formalisation par les Statecharts nous perrnet aussi de faire ressortir le parallélisme du
fonctionnement des agents réactifs. En effet, ceux-ci sont créés etlou instanciés en cascade
suivant I'ordre du Superviseur. Puis, dès cet instant, ils fonctionnent de manière simultanée.
Cependant, il convient de ne pas perdre de vue que le formalisme par les Statecharts est
insuffisant pour caractériser entièrement SYROCO. En effet, comme nous I'avons déjà iait
remarquer, ce système est un assemblage de modules interdépendants. Or, les Statecharts, s'ils
68
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
permettent de faire ressortir I'action de tel ou tel événement, ne perrnettent pas d'expliquer la
provenance du dit événement. Il faut donc, pour que la formalisation du système soit plus
précise, adjoindre aux schémas Statecharts le schéma de principe (Figure II-2) qui, seul,
permet de rendre compte du cheminement des événements entre les modules.
D'autre part, aucune de ces deux modélisations ne prend véritablement en compte le facteur
temps, Il faut donc garder à I'esprit qu'une Cellule ne gère qu'une Ressource à la fois. En effet,
les agents Ressources ne sont pas tous lancés au même instant, mais suivant un calendrier de
fabrication (contenu dans l'agent Produit).
//l.4. Les outils développés
f f .4.1. Les îlots virtuels (voir annexe 2).
11.4.1.1. Modél isat ion.
Soit un atelier (Figure tr-13) défini par un ensemble M de ressources hétérogènes (tours,
fraiseuses. etc.).
Perceuse
Fraiseuse
Rectif ieuse
Tour
Figure II- l3 ; Modélisation d'un l'atelier.
Pour placer les gammes dans un tel atelier, nous avons développé deux modèles
EEEE
EEtrE
EE
E
E
E
E
FIUE
E
E
EE
E EE
69
chapitre tr : Modélisation de larchitecture de pilotage réactif.
mathématiques, I'un global, utilisé à I'initialisation du système, I'autre local,
fonctionnement. ces modèles sont utilisés par I'outil d,ordonnancement
appelé par le Méta-objer, afin de créer les agents produits.
11.4.1.2. Analyse globate.
utilisé en cours de
Optigam, qui est
Cette analyse est utilisée lors de I'initialisation du système afin de placer toutes les produits
contenus dans les objectifs de production dans I'atelier. Dans ce cas, nous ne renons pas
compte des temps d'occupation des ressources. Le seul objectif est de minimiser le coût de
fabrication (C) calculé en fonction de la distance parcourue par le produit dans l,atelier et de la
quantité de pièces à fabriquer. Dans ce cas de figure, il faut traiter un ensemble G de sammes
à placer dans un atelier comportant M ressources. Ainsi donc :
Soit un ensemble G de gammes standards de fabrication défini par :
. une su i te ordonnée de ressources sr = { (^) , ( * r ) , . . . , (^^) }
' un flux de produits (quantité de pièces à fabriquer pour chaque produit)
Soit une ressource m1 définie par :
. la posit ion de son centre de gravité ̂ i={rg,,yg,} ou xgi et ygi sont les
coordonnées cartésiennes du centre de gravité exprimées dans un repère attaché à
I'atelier.
Le problème se ramène à la recherche d'un ensemble E de Q doublons (Figure tr-14) de la
forme :
E = { * , ' go }
où pour toute ressource rn1, on connaît sa gamme d'appartenance gp.
70
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
E1... Eta ,
tl]*;--'El
EE
E
E
E E
EEEE
Perceuse
Fraiseuse
Rectifieuse
Tour
Figure II-14 : Solution du problème.
11.4.1.2.1. Contrainte.
Chevauchement de gammes interdit. Ce qui se traduit par :
I oa l ,
M G T T G
! Ix,rÀ>Ix,,=a pour k+tt = l r = l i = t t = l
avec :
[1ç : ensemble des ressources pour la gamme k
11.4.1.2.2. Fonction objectif.
c ( u , u \utn(c)= >l >I Y, ir ' f r . d,, . x,o x,r I
r=r \ i=r y=r )
avec :
G : nombre de gammes.
M : nombre de ressources.
k, I : indices de gammes.
i, j : indices de ressources.
7 l
Chapitre tr: Modélisation de I'architecture de pilotage réactif.
f1 : flux de produits de la gamme k.
dii : distance euclidienne ou rectangulaire entre la ressource i et la ressource i.
X* = I si le produit k passe sur la ressource i, 0 sinon.
Y1ç = I si la ressource j est juste après la ressource i dans la gamme k, 0 sinon.
11.4.1.3. Analyse locale.
Cette analyse sert lors de I'adjonction d'une gamme dans I'atelier. Dans cette configuration,
d'autres produits sont déjà en cours d'usinage et il faut placer la nouvelle gamme dans les
espaces libres, c'est-à-dire qu'il nous faut, cette fois, tenir compte des temps d'occupation ( Ar, )
des ressources, tout en gardant le critère de minimisation du coût (C). D'autre part. nous ne
traitons plus, cette fois, qu'une gamme à Ia fois. Ainsi donc :
Soit un ensemble G de gammes standards de fabrication défini par :
. une suite ordonnée de ressources sr = {Qa, ntr),(mr, Ltr.), . . . ,(*,, a/,, ,)} où les ar,
sont init ial isés à 0.
. un flux de produits
Soit une ressource n1 définie par :
o la posit ion de son centre de gravité, et par son temps d'occupation A/,, soit:
fr r 'l
m,= l \xT , , ) ' 9 , ) ,L t i I .
Le problème se ramène à la recherche d'un ensemble E de Q singletons de la forme :
r ' lE =IEo, I
où Eo, est un ensemble de P doublons de la forme :
Eo, =(g,m,)
où pour toute gamme gp, on connaît la ressource mi utilisée pendant le temps Af .
72
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
;--flE
EE
E
tr
t-ll F l
r:.l l+Jl . l :
[Ël' e3' 't r lt-J
l F ll-t
Perceuse
Fraiseuse
Rectifieuse
Tour
Figure II-15 : solutions locales
11.4.1.3.1. Contrainte.
Chevauchement de ressources pendant le temps A, interdit. Ce qui se traduit par :
I r a l ,
P , \ 1 G P ' V G
I ILx,*.I>Lx,r=a pour k+tP = l r = l t = l P = l j = l ! = l
avec :
Iç : ensemble des ressources pour la gamme k
11.4.1.3.2. Fonction obiectif.
c ( p M M \
uin(c)= I l I ILY,,r. fr . d, i X,* ' x,* |t = l \ p = t i = l / = l )
avec :
G : nombre de gammes.
P : nombre de phases de la gamme
M : nombre de ressources.
k, I : indices de gammes.
EEEE
I )
chapitre II : Modélisation de ilarchitecture de pilotage réactif.
p : indice de phases.
i, j : indices de ressources.
fr : flux de produits de la gamme k.
d1.; : distance euclidienne entre ra ressource iet laressource i.
Xitp = I si le produit k passe sur la ressource i durant la phase p, 0 sinon.
Yijt = I si la ressource j est juste après la ressource i dans la gamme k, 0 sinon.
Ces deux analyses sont réalisées par le même outi l : Optigam, décrit en Annexe 3.
,1 .4.1.4. Conclus ion.
Travail ler dans une tel le optique, nous a paru la solution la plus souple et la plus eff icace.
En effet, grâce à la théorie des î lots virtuels, nous pouvons placer une production dans I 'atel ier
en uti l isant des ressources l ibres que nous agglomérons en cellules. Si nous avions Lrt i l isé cles
îlots de production classiques, i l est à craindre que nous ayons perdu en f lexibi l i té. En effet.
des cellules f ixes nous auraient imposé de leur demander leur charge actuelle avant de leur
attr ibuer une production. A notre avis, i l est plus faci le d'obtenir un groupe quelconque de
ressources non chargées dans I 'atel ier que de vérif ier la charge d'un ensemble précis de
ressources. De plus, une tel le organisation impose une discussion avec les agents Cellules, or
une discussion avec I 'enchaînement classique :
o euestion,
o Réflexion.
o Réponse,
est plus longue et, surtout, plus problématique qu'un simple ordre de création. C'est grâce aux
îlots virtuels que nous avons pu instaurer une hiérarchie aussi poussée dans le système.
Bien sûr, le problème dans notre approche tient à I'ordonnancement dynamique de I'atelier.
Dans ce domaine, nous aurons toujours plus d'éléments à gérer, car le nombre de ressources
1 A
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
sera toujours supérieur, ou égal, au nombre de cellules. Le risque était donc grand de perdre en
rapidité ce que nous avions gagné en flexibilité. Les tests effectués (cf. gtV) montrenr que ce
ne fut pas le cas.
Gardons aussi à I'esprit que I'outil de recherche de chemins utilisé n'est pas le plus
performant et qu'il laisse de côté un certain nombre de paramètres tels que [a gestion des outils
de machines, par exemple. Il n'est certainement pas le plus rapide ou le plus efficace. Mais, ce
n'est qu'un utilitaire de calcul, il est donc, à ce titre, interchangeable.
11.4.2. le générateur d'agents.
L.4.2.1. Le type d 'agent .
Les agents que nous générons sont les agents Produits. En effet, le générateur n'est qu'un
uti l i taire et, comme pour Optigam, nous avons choisi de prendre une application simple, juste
suffisante pour que le système SYROCO puisse fonctionner.
Les agents générés sont donc aussi simples que leur générateur. Ce sont des agents réactifs,
basiques, dont le seul rôle est de fournir à I 'agent Cellule les informations concernant la
gamme dont il s'occupe et les comptes rendus de la Ressource. Ces agents sont donc
parfaitement incapables de la moindre "réflexion" et se contentent de retourner des réponses à
des questions précises. Ils sont adaptés aux produits auxquels ils correspondent et à aucun
autre. De plus, ils sont incapables de répondre à une question dont la réponse n'est pas
expressément inscrite dans leur code source.
Pour ce qui est de la communication, ces agents reçoivent les informations par Ie biais
d'une exécution paramètrée et répondent grâce à une boîte aux lettres (cf. $Itr.3.a.2).
11.4.2.2. Mode de génération.
Lorsque I'on active le générateur, on lui passe le nom du Produit concerné en paramètre. Il
t i
chapitre tr : Modélisation de larchitecture de pilotage réactif.
génère le code d'un agent en fonction de la gamme du produit dont il s'occupe. pour cela, il
consulte le fichier solution de I'outil de recherche de chemins (optigam) dans lequel se rrouve
la gamme atelier du produit à fabriquer, et le fichier agenda où se trouvent les informations de
la phase. ces fichiers sont structurés de la manière suivante :
Fichier solution :
PRODUITI
5
DECOUPEUSEI
PERCEUSE I
TARAUDEUSE I
FRAISEUSE4
Fichier a_eenda :
TOUR I
2
PRODUITT
26700
1000
PRODUIT6
21700
1800
Nom du Produit.
Nombre de phases.
Phase de la gamme
Nom de la ressource.
Nombre d'entrées dans I'agenda.
Nom du premier produit qui ut i l ise la machine.
Date de début de la phase en CMn depuis 7h00.
Durée de I'usinage en CMn.
Nom du deuxième produit qui ut i l ise la machine.
Date de début de la phase en CMn depuis 7h00.
Durée de I'usinage en CMn.
)
)
)
à
)
)
)
)
)
)
)
Muni de ces informations, il rajoute ensuite, dans le source générique des agents, la gamme
constituée des différentes phases à mettre en ceuvre pour la fabrication. Ces phases sont
définies par un numéro, une date de début, une durée et un poste de travail (une ressource
réelle). Il donne ensuite aux agents un nom identique à celui du produit dont ils s'occupent. Le
programme source complet des agents est alors sauvegardé dans un fichier texte. Le
générateur fait alors appel à un compilateur "C++" qui génère le code exécutable de I'agent. Il
ne reste plus au générateur qu'à éliminer les fichiers temporaires et à placer les agents générés
76
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
dans le répertoire de travail. Ces agents poulront alors être activés dès qu'une Cellule aura
besoin d'informations concernant les phases de la gamme.
11.4.2.3. Remarque.
Le générateur d'agent nous perrnet donc de produire le code exécutable pour les agents
Produits de manière automatique. Ces agents contiennent toutes les informations concernant
la gamme du produit auquel ils sont liés et sont capables d'assurer la retransmission des
comptes rendus des Ressources vers la Cellule.
Cependant, ces agents, tout comme leur générateur, restent très simples et très basiques. II
ne s'agit que d'agents purement réactifs, dont la principale uti l i té est, pour l ' instant, d'avoir des
agents Cellules génériques. En effet, seul I'agent Produit est-modifié en fonction de la
production eVou des aléas de production. Ceci nous permet d'avoir un agent Cellule générique
pour tous les produits et qui n'a pas à être re-configuré en cas de problème.
La simplicité du générateur ne doit pas faire perdre de vue qu'il s'agit d'une pièce
essentielle du système car il est indispensable que les agents Produits soient générés de
manière autonome et interne. De plus, ce n'est qu'un outil et, en tant que tel, il est
interchangeable et pourra être remplacé ultérieurement par un générateur plus performant et,
surtout, plus générique. Le but final est de pouvoir générer des types d'agent différents en
fonction du type de production à réaliser.
l1.5. Conclusion.
La structure de SYROCO est donc basée sur un système multi-agents hiérarchique et qui
est hybride. Une telle conception nous permet d'obtenir rapidité et modularité qui étaient les
deux points principaux de notre cahier de charges. Le fait de mixer deux types d'agents
différents, aux durées de vie diverses, peut sembler audacieux mais s'adapte particulièrement
77
chapitre tr : Modélisation de larchitecture de pilotage réactif.
bien à la philosophie et aux buts du système. En effet, I'utilisation du concept d,îlots virtuels
comme point de départ de notre approche de pilotage, impose, logiquement, la création
d'agents correspondant aux îlots virtuels intervenant dans I'atelier. or, par définition, un îlot
virtuel n'a comme espérance de vie qu'un temps limité et déterminé à I'avance par les
contraintes de production' Il apparaît donc comme normal que nos agents aient une durée de
vie calquée sur celle de l'îlot qu'ils gèrent.
D'autre part, la distribution physique de I'application avait pour principaux buts de
rapprocher les agents de leurs correspondants physiques (ou réels) et d'éviter la surcharge
d'une ressource informatique. Partant de cette contrainte, il nous a fallut élaborer toute une
collection de messages permettant aux agents de discuter entre eux. En fait, il esr apparu que
la communication est devenue la colonne vertébrale du système et qu'elle fut à I'origine de
nombre des spécifications informatiques des agents. Ce système ne fonctionne que s'il peut
communiquer! Les échanges d' informations sont d'une importance vitale, mais, à la différence
des systèmes coopératifs, le but n'est pas de se pencher à plusieurs sur la résolution d'un
problème commun. Ici, la communication sert, principalement, à ordonner et rendre compte,
parfois à obtenir des informations utiles. Si nous reprenons I'analogie militaire, il est
indispensable que les "officiers" puissent donner leurs ordres en permanence et qu'ils soient
tenus au courant de l'évolution des choses en temps réel, sinon, c'est la défaite. La
formalisation par Statecharts nous a montré que les messages sont les principaux événements
du système et que ce sont eux qui provoquent des changements d'états des agents.
Pour terminer, nous pouvons noter que SYROCO est extrêmement modulaire et que le
Méta'obiet ne fonctionne qu'en faisant appel à des outils extérieurs. Cela fut conçu ainsi afin
que Ie système soit évolutif et puisse bénéficier, à terme, des meilleurs outils (ou des plus
adaptés) pour réaliser ses actions.
7 8
Chapitre tr : Modélisation de I'architecture de pilotage réactif.
La modélisation du système étant terminée, nous verrons dans le prochain chapitre
I'application de celle-ci, ainsi qu'un exemple de fonctionnement de SYROCO.
79
CHAPITRE III
IMPLEMENTATION DU SYSTEME SYROCO
80
Chapitre Itr : Implémentation du système syRoco.
lll. lmplémentation du système SYROCO.
lll.1. lntroduction.
Après avoir présenté I'analyse et la modélisation du système, ce chapitre aborde les aspects
techniques liés à son implémentation.
Dans un premier temps, nous décrirons, du point de vue informatique, les différents
modules qui entrent en jeu dans SYROCO, à savoir :
les agents :
o Superviseur,
o Méta-Obiet,
o Cellules.
o Produits
o Ressources,
ies outi ls uti l isés :
' OPtigam,
o Générateur d'agents,
et le serveur dont le rôle est de perrnettre la communication entre ces différents modules.
Nous nous attacherons, ensuite, à analyser et décrire le système de communication qui est
l'épine dorsale du système. Nous montrons quels modes de transferts sont utilisés, pourquoi et
comment.
lll.2. Description informatique des modules.
111.2.1. Le Superviseur.
En tant qu'élément maître du système, le Superviseur est le seul agent qui soit sous le
contrôle de I'utilisateur. Informatiquement parlant, il se compose de trois modules
indépendants et communiquants : le Deamon (ou tâche de fond), le Scheduler (ou
8 l
Chapitre Itr : Implémentation du système SYROCO.
séquenceur/ordonnanceur) et la visualisation (ôf. figure m.7).
111.2.1.1. Le Deamon.
Du point de vue de I'utilisateur, le Deamon est le point d'entrée du système. C'est le seul
programme qui devra être exécuté par une intervention extérieure, et c'est lui qui lancera les
autres modules en cascade lorsque cela sera nécessaire. Programmé en C++, le Deamon
permet d'initialiser les variables systèmes et d'exécuter une application serveur sur la machine
hôte du Superviseur. Ceci étant, il exécute le Scheduler, se met à l'écoute du système et se
place dans le "tray" (bane de tâches) de Windows 95rM (pour la version PC) ou en icône (pour
Ia version UND(). En fait, le Deamon est un programme qui tourne en tâche de fond et qui
remplit le rôle d'un serveur de sockets (cf. $Itr.2.4 et Figure U-l). Pour des raisons de facilité
d'exécution, nous avons séparé le serveur du Superviseur des serveurs classiques. Ainsi. les
agents du système communiquent avec le Superviseur de manière directe en s'adressanr à une
adresse et à un port particuliers qui lui sont strictement réservés par le système d'exploitation.
Lorsqu'il reçoit une requête réseau, le Deamon I'inscrit dans un fichier d'échange en lui
adjoignant une date de traitement. Cette référence temporelle servira au Scheduler à classer les
requêtes afin de réaliser les opérations dans le bon ordre. Il existe cinq types de messages
différents dont les quatre premiers se rapportent au compte-rendu 3 et le cinquième à la
consultation 2 :
o "Panne" qui indique qu'une ressource est en panne. Les informations contenues dans
ce message sont : le nom du produit stoppé, le temps restant sur la phase en cours,
le nom de la ressource défaillante, la date de la panne, sa durée et un commentaire
laissé à la discrétion de I'opérateur. La syntaxe de ce message est :
ult, temps restant, ressource, t, durée, commentai|pan ' le l
Un exemplede ce message pourrait être :
8 2
Chapitre Itr : Implémentation du système SvROCO.
trahaenarlcel
Un exemple de ce
|mâintenancel
I panne | | atptra, SOO, TOUR
Ce qui signifie que le TOURI est tombé en panne à la date 30000 (nombre de CMn
écoulées depuis le début de la journée) alors qu'il usinait Ie produit alpha. Cette panne
concerne les roulements de la contre-pointe et sa durée prévisionnelle est de 1200
CMn (12 mn). Il aurait fallut 500 CMn de plus pour que la phase en cours sort
terminée,
o "Maintenance" qui indique qu'une ressource va être placée en maintenance. Les
informations transportées sont les mêmes que pour une panne (temps restant
excepté). La syntaxe de ce message est de la forme :
ressource, produtt, debut, cluree, commental
message pourrait être :
TqUR1, alpha, 42000, 1500, nettoyage du bac à copea
Ce qui signif ie que la ressource TOUR1 (qui, actuellement, usine le produit alpha)
sera placée en maintenance à partir de la date 42000 et pour une durée de 1500 CMn.
L'opération de maintenance consistera à nettoyer le bac à copeaux.
r "Fin phase" indique qu'une Cellule vient de terminer une phase donnée de sa
production. Les informations fournies sont : Ie nom du produit considéré, le nom de
la ressource qui vient de finir son travail, le numéro de la phase terminée et Ia date
de la fin de phase. La syntaxe de ce message est de [a forme :
roduit, ressource, numéro,
message pourrait être :
alpha, TOUR1,2, 3
Ce qui signifie que la ressource TOUR1 vient de terminer (à la date 36000) I'usinage
de la phase 2 du produit alpha.
l-rh ph"*l EUn exemple de ce
lf* eh*"] @
8 3
Chapitre Itr : Implémentation du système SyROCo.
Création et attachement de lasocket d'écoute
v
traitement de la demande
Figure III-l : Organigramme du Deamon.
"Commentaire" indique qu'une ressource a envoyé un commentaire afin de
renseigner le système sur I 'avancement de son travail (nombre de pièces usinées,
nombre de pièces restantes, temps avant la fin de la phase, etc.). Ce commentaire
sera sauvegardé et mis à la disposition de I'utilisateur (via le module de
visualisation). La syntaxe de ce message est de la forme :
te commental
message pourrait être :
(TOURI) fin de la préparation ase I du produit al
Un exemple de ce
lcomrnentarEl
Ce qui n'est rien d'autre
ressource. Ce commentaire
intérêt est de permettre aux
qu'une information transmise au Superviseur par une
ne sera, bien entendu, pas utilisé par le système. Son seul
opérateurs de préciser certaines informations, si nécessaire.
Ouverture du service
Création d'un sous-processus
84
Chapitre Itr : Implémentation du système SYROCO.
o "Gamme" indique qu'une nouvelle gamme vient d'être ajoutée aux objectifs de
production. La syntaxe de ce message est de la forme :
Ce message est invariable.
Il y a un sixième type de commande qui peut-être transmise au Scheduler : il s'agit de [a
commande d"'initialisation" (tout aussi invariable que "gamme") qui n'est utilisée qu'une fois
dans la vie du système. Cette commande est envoyée par le Deamon lors de son exécution afin
que le Scheduler initialise le système et place dans I'atelier toutes les gammes qui étaient en
attente.
D'autre part, le Deamon permet, via un menu, d'accéder à la partie visualisation du système,
| 1.2.1.2. Le Scheduler.
Lancé par le Deamon lors de l ' init ial isation du système, le Scheduler est la part ie opérative
du Superviseur. I l reçoit les requêtes du Deamon et les classe, en uti l isant un algorithme de tr i
rapide (cf. Annexe 4), en fonction de leur date d'exécution. Puis, en fonction de la requête. i l
lance le module utile. Il existe cinq types d'opérations possibles en fonction des commandes
entrantes :
. Lacommande "initialisatlon" conduit à une lecture des objectifs de production et au
placement de tous les produits dans I'atelier.
o La commande "fin phase" provoque un réajustement de l'agenda afin de faire
disparaître I'entrée correspondant à la phase considérée.
o La commande "panne" conduit, elle aussi, à une modification de I'agenda afin que
la ressource concernée soit bien enregistrée par Ie système comme étant en panne
durant le temps fixé. Puis le Scheduler exécute le Méta-Obiet pour ré-affecter les
gammes touchées par le mauvais fonctionnement de la ressource.
85
Chapitre Itr : Implémentation du système SYROCO.
o La commande "maintenance" provoque les mêmes effets que la commande ,,panne,,
à ceci près qu'il n'y a pas de ré-affectation de gamme. En effet, à la différence d,une
panne, une maintenance est prévisible et doit donc être placée durant les temps
libres des ressources.
o La commande "gbmme" conduit à la relecture des objectifs de production afin d,en
extraire la nouvelle gamme à placer dans I'atelier. Ensuite, le Scheduler envoie au
Méta-obiet une requête de création d'un nouvel agent produit correspondant à la
nouvelle gamme.
existe cinq autres types de commandes qui sont internes au Scheduler. Il s'agit de :
o L'ordre de fabrication envoyé aux Cellules (ordre l) et leur ordonnant de
commencer la fabrication. Cette commande n'est pas le résultat d'une requête réseau
mais est produite en fonction des informations des objectifs de production indiquant
à quelle date il faut commencer une production donnée. La syntaxe de cet ordre est :
message pourrait être :
Ce qui indique que le serveur doit ordonner à une cellule de commencer la fabrication
du produit alpha.
o L'ordre de modification (ordre l) qui permet d'indiquer à une Celute que les
ressources utilisées par le produit dont elle s'occupe ont été modifiées suite à un
aléa de production. La syntaxe de cet ordre est de la forme :
produit, modification
a, modification
ls..rper"fsenrl
Un exemple de ce
|sup"I"''e*l
I ce i lu le l lpro
Un exemple de ce
I cellulel lulp
message pounait être :
86
Chapitre Itr : Implémentation du système SYROCO.
Ce qui signifie que la Cellule qui gère le produit alpha doit prendre en compte les
modifications de ressources.
o L'interrogation (consultation 4) qui pelTnet au Superuiseur de savoir à quelle date
une phase doit commencer. La syntaxe de cette consultation est :
date-début, produit, no ph
Un exemple de ce message pourrait être :
date-début, alpha,
Ce qui signifie que le Superviseur demande à la Cellule qui gère le produit alpha de
retourner la date de début de la phase 3.
o La commande "début de journée" qui provoque une remise à zéro des dates et une
ré-affectation des temps de phase dans I'agenda ainsi qu'un "réveil" du système.
o La commande "fin de journée" qui stoppe le processus de scrutation et place [e
système en sommeil.
111.2.1.3. La v isual isat ion.
Module complètement indépendant des deux autres, la visualisation permet à I'utilisateur
d'avoir une représentation graphique de l'état de I'atelier et ce, à deux niveaux. En effet, il est
possible, grâce à ce module, de visualiser les ressources et Ies gammes utilisées. Chaque
gamme est matérialisée par un trait de couleur différent et orné de symboles indiquant son état
(OK ou stoppé). De même, chaque ressource est représentée par un dessin dont la couleur de
fond change en fonction de l'état (repos, actif, panne ou maintenance). De plus, un simple
"click" souris sur les éléments pennet d'obtenir des renseignements complémentaires tels que
I'historique, la position physique, travail prévisionnel, etc.
D'autre part, comme le réseau et I'état des différents ordinateurs présents dans I'atelier sont
d'une importance capitale, nous avons aussi introduit une visualisation du parc informatique.
87
Chapitre Itr : Implémentation du système SYROCO.
Cette représentation nous perrnet de connaître la position physique des éléments (ordinateurs,
stations et câbles réseau) ainsi que leur état actuel. De plus, comme pour la visualisation
atelier, il est possible d'obtenir des informations complémentaires telles que le modèle et la
puissance de la machine, son taux d'occupation CPU, les applications actives, etc.
Le principal atout de ce module de visualisation tient au fait qu'il est programmé en
TCLÆK qui, en ce qui concerne I'affichage graphique et la porrabilité, présente de sérieux
avantages sur la programmation en C.
111.2.1.4. Remarque 1.
Nous avons décidé de séparer la partie opérative de la partie "serveur" (à savoir le Deamon)
dans le Superviseur pour deux raisons principales. La première, et la plus importante, étant de
s'assurer que les actions seront exécutées dans I'ordre et sans interférer les unes avec les
autres. En effet, le système de traitement du serveur impose de générer des applications
"filles" pour gérer les requêtes arrivantes, tout en restant à l'écoute afin de ne pas rater une
information arrivante. Or, ces applications sont indépendantes les unes des autres et s'ignorent
mutuellement. Le risque était donc grand de voir des modifications du système s'opérer de
manière anarchique. D'où la solution de ne demander à ces applications qu'une écriture dans
un fichier d'échange. Læ Scheduler reprend donc ces informations de manière séquentielle et
ne les traite que I'une après I'autre, ce qui nous assure une parfaite sécurité. Un tri des
commandes est bien entendu rendu nécessaire afin de s'assurer qu'elles seront bien traitées
dans le bon ordre.
La deuxième raison de ce choix découle de la première. Le système ne peut générer qu'un
certain nombre d'applications filles en parallèle. De plus, les opérations à réaliser en fonction
des commandes prennent un certain temps. Nous risquions donc de ne plus avoir de temps
CPU disponible pour traiter une requête et de devoir la mettre en attente. Le système
8 8
Chapitre III : Implémentation du système syRoco.
Deamon/Scheduler nous pennet de contourner ce problème. En effet, avec cette solution, les
applications filles ne sont actives que pendant un temps restreint : juste le temps d'inscrire la
commande dans le fichier d'échange.
111.2.1.5. Remarque 2.
Si le Superviseur et le Méta-Objet sont exécutés sur la même machine, il n'en est pas de
même des outils. En fait, ceux-ci, principalement I'outil de recherche de chemins et le
générateur d'agents, sont lancés sur la machine la moins occupée (en terme de temps CPU).
Ceci est réalisé à l'aide d'une fonction de broadcast. C'est-à-dire que le Superviseur interroge
toutes les ressources informatiques répertoriées dans la BDOO à I'aide d'un message de la
forme:
A cette interrogation, les serveurs de chaque ressource informatique répondent par :
taux d'occupation CPU
A l'aide de toutes ces réponses, le Superviseur choisit la machine la moins chargée et
demande au Méta-Objet d'y exécuter ses outils. La même opération est réalisée lors de
I'exécution des agents Cellules. Ceci afin d'accélérer le système au maximum et de ne pas
surcharger une machine par de nombreuses applications, d'autant plus que le système n'est pas
censé être la seule application active sur les ordinateurs. Notre but est de permettre aux
utilisateurs de se servir de leurs machines avec le moins de gène possible, même lorsque
I'application est active et qu'elle travaille.
89
Chapitre Itr : Implémentation du système SYROCO.
111.2.1.6. Récapitulatif des messages.
La coLonne "lntitulé" indique le h,pe de message d'identification envo\,é par L'éntetteur.C'est ce message qui permettra ûu Superuiseur de taiter les infonnations utilestransntises. La syntaxe de ces informations est rappelée dans la colonne "Message".
Tableau III-l : Messages du Superviseur
111.2.2. Le Méta-Objet.
I e Méta-Obiet est d'une structure beaucoup plus simple que le Superviseur. Il tient en un
seul module dont la tâche est principalement de décrypter la requête de création du
Superviseur et d'interroger les différents outils.
En effet, le Méta-Objet reçoit la requête de création du Superviseur sous Ia forme :
îlot(produit)=?, X, Y
Intitulé Message Emetteur I Receveur Interne?
"Panne"
"produit, temps restant,
ressource, début, durée,
commentaire"
Cellule / Superviseur non
"Maintenance" "ressource, produit, début,
durée, commentaire"
Cellule / Superviseur non
"Fin_phase" "produit, ressource, numéro,
date"
Cellule I Superviseur non
"Commentaire" l e commentaire" Cellule I Superviseur non
"Gammg" g Objectifs de Production /
Superviseur
non
Ordre de fabrication "produit" Superviseur / Cellule non
"date début" "numéro de phase concernée" Superviseur / CelluLe non
"Init ial isation" a Superviseu r / S upe n' is e ur our
"Début de iournée" a Superviseur / Superviseur our
"Fin de journée" a Superviseu r / Superviseur oul
dont un exemple pourrait être :
90
Chapitre Itr : Implémentation du système sYRocO.
ilotl(al ? ,1
Ce qui littéralement signifie : "créer I'ilotl correspondant au produit alpha en commençant
à la phase I et dont Ie temps de fabrication doit être inférieur à 50fi) CMn." L'argument
indéfini "?" devra être remplacé par une liste de ressources. [æ Méta-Objet s'emploie donc à
analyser cette requête en s'aidant des informations obtenues grâce à la consultation I (dont la
forme est fonction du type de base de données). Puis, il demande à I'outil de recherche de
chemins (Optigam) de réaliser ce travail, Ceci est la première partie de la tâche du Méta-Obiet.
Lors du retour des résultats, deux cas peuvent se présenter :
o Le placement s'est effectué sans problème,
o Il est impossible de placer la gamme avec la configuration actuelle de I'atelier.
Voyons ce qui se passe dans ces deux cas :
111.2.2.1. Placement sans problème.
Ce cas est le plus faci le et celui qui pose le moins de diff icultés. Optigam renvoie au Méta-
Objet une solution comprenant les ressources uti l isées par la gamme et les temps prévisionnels
d'usinage de chaque phase. La syntaxe de cette solution prend la forme d'un tableau (cf.
Tableau m-D.
No phase nom de la ressource date de début durée
I FRAISEUSEI 5000 5002 TOUR3 5500 700aJ ALESEUSE4 6200 3004 DECOUPEUSE I 6500 1000
Tableau III-2 : Syntaxe de la réponse d'Optigam.
Le Méta-Objet entre donc dans sa deuxième panie et demande au générateur d'agents de
créer I'agent Produit correspondant à la solution obtenue. Puis, il informe le Superviseur, grâce
à un message de la forme :
îlot(produit)=((ressource l),(ressource 2),...,(ressource n))
9 l
Chapitre Itr : Implémentation du système SyRoCO.
ilot I (alpha)= ((FRATSEUSE 1 ),(TouR3),(ALESEUSBI),(DECOUPEUSE I )
Ce qui, dans notre exemple se traduit en :
Ce qui signifie que le produit alpha géré par la Cellule ilotl devra passer sur les ressources
FRAISEUSEI, ..., DECOUPEUSEI.
/,1.2.2.2. Placement avec problèmes.
Comme dans Ie premier cas, Optigam revoie une solution (cf. Tableau Itr-2). Mais, ici, le
temps complet d'usinage provoque un dépassement des délais. Le Méta-objet demande alors à
['utilisateur si le dépassement est acceptable. Dans I'affirmative, tout rentre dans I'ordre et le
Méta-Objet entre dans sa deuxième partie.
Dans le cas contraire, cela signifie qu'il faut revoir la répartition des gammes dans I'atelier
afin de pouvoir toutes les placer sans dépassement de délais. Pour parvenir à ce résultat. le
Méta-Obiet fait appel à I'outil de "stratégie de replacement" qui va s'occuper de remanier Ia
configuration de I'atelier afin que toutes les gammes puissent être réalisées dans les remps.
Puis, une fois I'atelier remanié, le Méta-objet informe le Superviseur des changements et entre
dans sa deuxième partie.
L'organigramme du Méta-Objet se présente comme sur la Figure m-Z .
111.2.3. Agents réactifs.
111.2.3.1. L'agent Cel lule.
L'agent Cellule reçoit du Serveur un message lui demandant de s'exécuter lorsque la
fabrication du produit dont elle s'occupe doit commencer. Cette requête d'exécution est lancée
sur l'ordre du Superviseur. Elle doit envoyer les ordres de fabrication vers les Ressources
concernées à chaque début de phase et transmettre les comptes rendus du Produit vers le
Superviseur. Informatiquement parlant, la Cellule scrute les messages, venant soit de I'amont
92
Chapitre Itr : Implémentation du système sYROco.
(le Superviseur) soit de I'aval (le Produit) et réagit en fonction du contenu de ces messages (un
message de panne ne provoque pas les mêmes réactions qu'un message de fin de phase).
Du Superviseur, elle ne peut recevoir que deux messages :
Le premier (ordre l) est I'indication de "modification" qui lui indique que la gamme dont
elle s'occupe a été modifiée. Cela n'anive que lors de I'introduction d'une nouvelle gamme
dans le système. lorsque ce message arrive, la Cellule consulte I'agent Produit (nouvellement
recréé) afin de s'informer des modifications et de la ressource qui doit maintenant réaliser la
phase en cours.
Le deuxième message (consultation 4) va de pair avec la modification. En effet, il s'agit
d'un message d'interrogation, "date début", dans lequel le Superviseur demande à la Cellule de
lui retourner la date d'un début de phase. Ce message n'est utile que lors de la ré-affectation
des gammes suite à une panne. Le Superviseur se renseigne alors auprès des Cellules qui sont
touchées par la panne afin de savoir exactement quand devait commencer la phase qui ne
pourra plus être effectuée par la ressource hors service.
Note: I'ordre (ordre 1) de commencer la fabrication n'est pas transmis à la Cellule
directement via une socket. En fait, I'exécution de I'agent fait office d'ordre de démarrage. Le
serveur effectue une copie du programme générique de Cellule en lui donnant un nom en
rapport avec le produit dont elle va s'occuper (cell-nomprod) et il I'exécute en lui passant en
paramètre ce même nom de produit. Cet état de fait nous permet d'avoir un code générique
pour tous les agents Cellules, seul leur paramètre d'exécution change en fonction du produit.
L'agent Produit envoie vers la Cellule cinq types de messages différents qui conespondent à
la consultation 3 :
o Ie message "panne" qui provoque I'anêt (vis-à-vis du système) de la production, un
transfert d'information vers le Superviseur et une attente de la modification du
chemin de la gamme pour reprendre la production. La syntaxe de ce message est :
9 3
Chapitre Itr : Implémentation du système SyRoco.
l-
lpanne | | proclult, ress
Un exemple de ce message
fpannel |aiptra'roûi
produit, ressource, début, durée, commentai
pounait être :
alpha, TOURl, 30000, 1200, roulements de contre-poi
Ce qui signifie que le TOURI est tombé en panne à la date 30000 (nombre de Cmn
écoulées depuis le début de la journée) alors qu'il usinait le produit alpha. Cete panne
concerne les roulements de la contre-pointe et sa durée prévisionnelle est de 1200
Cmn (12 mn) .
o lç message "maintenance" qui provoque l'émission d'un rapport vers le Superviseur
afin qu'il prenne I'information en compte. La syntaxe du message est la même que
celle indiquée dans la section "Le Superviseur".
Le message "fin phase" qui provoque une consultation de I'agent Produit par la
Cellule afin de savoir quelle ressource est affectée à la phase suivante et quel est le
temps de fabrication prévu. Bien sûr, le Superviseur est tenu informé. La syntaxe du
message est la même que celle indiquée dans la section "Le Superviseur".
Le message "commentaire" qui regroupe des informations sur la production venues
de la ressource via le Produit, et qui est directement transmis au Superviseur. La
syntaxe du message est la même que celle indiquée dans la section "Le
Superviseur".
Le message de réponse à une consultation qui permet à la Cellule de savoir quelle
Ressource elle doit contacter. Dans la plupart des cas, ce message est composé d'un
nom de ressource, et d'une durée de phase. Il existe une exception à ce cas : lorsqu'il
n'y a plus de phase à effectuer, le Produit renvoie simplement le mot "fin". La
syntaxe de cet échange est de la forme :
information, no dequestion :
94
Chapitre Itr : Implémentation du système sYRoco.
reponse : ressource, temps d'usin ouE
Un exemple de cet échange pounait être :
question : lnlormauon,
réponse ' lrotlng, Too l
Ce qui signifie que la Cellule a demandé au Produit des informations sur la phase 2
de la gamme et que le Produit Iui a répondu qu'elle devait s'exécuter sur la ressource
TOUR3 et que sa durée prévisionnelle est de 700 CMn.
Une fois la production de sa gamme terminée, la Cellule est désactivée par le serveur sur
requête du Superviseur. Puis, son code exécutable est effacé.
L'organigramme de I'agent Cellule est montré par la Figure Itr-3. L'algorithme de I'agent
Cellule est donné ci-dessous pour perrnettre de mieux comprendreson fonctionnement :
l-Récupération du nom du Produit à consulter.2-Récupération du nom de la machine sur laquelle se trouve la Cellule.3-Création d'une socket pour communiquer avec le Superviseur.4-Création des boîtes aux lettres serveur/Cellule et Cellule/Produit.5-Consultation du Produit en lui passant en paramètre le numéro de la phase à usiner ( l).
6-Initialisation de la boîte aux lettres Cellule/Produit, lecture de la réponse, écriture dans Iaboîte pour préciser qu'elle a été consultée et libération de I'accès à la boîte.
7-La Cellule stocke le temps d'usinage de la phase.8-Création d'une socket pour communiquer avec la Ressource chargée d'usiner la phase en
cours.9-Envoi d'un ordre d'usinage à la Ressource à I'aide de la socket.10-Envoi d'un deuxième message à la Ressource pour compléter le premier.
I l-Récupération de la date de début d'usinage.
des informationsété consultée et
I2.1.2.t. I-Envoi d'un premier compte-rendu au Superviseur pour luisignaler la fin de la phase.
12.1.2.1.2-Envoi d'un deuxième compte-rendu au Superviseur pourcompléter I'information du premier.
12.1.2.1.3-Consultation du Produit en lui passant en paramètre le numérode la nouvelle phase à usiner.
95
Chapitre Itr : Implémentation du système syRoco.
12.1.2.1.4-Initialisation de la boîte aux lettres celluleÆroduit, lecture dela réponse, écriture dans la boîte pour préciser qu'elle a étéconsultée et libération de I'accès.
I2 . t .2 .1 . i la réponse est différente de "fin", faire :12.1.2.1.5. I -La Cellule stocke le temps d'usinage de la phase.12.L.2.1.5.2-Fermeture des anciennes sockets et création des
nouvelles.12.1.2.1.5.3-Envoi d'un ordre d'usinage à la Ressource.12.1.2.1.5.4-Envoi d'un deuxième message à la Ressource pour
compléter le premier.12.1.2.1.5.5-Récupération de la date de début d'usinage.
, l tz . t .z . l .6 . l -A l ler en 13.112.L2.2-Sinon, si le message est "panne", faire :
12.1.2.2.1-Calcul du temps restant à usiner.12.1.2.2.2-Destruction de I'agent Produit.12. 1.2.2.3 -Fermeture des sockets.12.1.2.2. -Création d'une socket pour communiquer avec le Superviseur.12.1.2.2.s-Envoi d'un compte-rendu au Superviseur.12.1.2.2.6-Consultation du nouveau Produit en lui passanr en paramètre
le numéro de la phase à usiner.12.1.2.2.7-Init ial isation de la boîte aux lettres Cellule/Produit, lectr"rre de
la réponse, écriture dans la boîte pour préciser qu'el le a étéconsultée et l ibération de l 'accès.
12.1,2.2.8-Création d'une socket pour communiquer avec la nouvelleRessource chargée d'usiner la phase en cours.
12.1.2.2.9-La Cellule stocke le temps d'usinage de la phase.12.1.2.2.10-Envoi d'un ordre d'usinage à la Ressource.12.1.2.2.1l-Envoi d'un deuxième message à la Ressource pour compléter
le premier.12.1.2.2.12-Récupération de Ia date de début d'usinage.
I f Z.f .Z.:-Sinon, si le message est "maintenance", faire :
ItZ.t.Z.l.t-Envoi d'un premier compte-rendu au Superviseur pour lui
I signaler la maintenance.
112.1.2.3.2-Envoi d'un deuxième compte-rendu au Superviseur pourI compléter I'information du premier.
ItZ.t.Z'.,+-Sinon, si le message est "compte-rendu", faire :
|'12.1.2.4.1-Envoi de la première partie du compte-rendu au Superviseur.|.12.1.2.4.z-Envoi de la deuxième partie du compte-rendu au Superviseur.
I tZ.Z-S' i t s 'agi t d 'une minute impaire, fa i re:12.2.1-Initialisation de la boîte aux lettres serveur/Cellule, Iecture des informations
qu'elle contient, écriture dans la boîte pour préciser qu'elle a été consultée etlibération de I'accès
12.2.2-Si les informations n'ont pas encore été consultées, faire :
ItZ.Z.Z.t-Si le message est "modification", faire :
|,12.2.2.1.[-Consultation du nouveau Produit en lui passant en paramètre
I le numéro de la phase à usiner.
112.2.2.1.2-La Cellule stocke le nom de I'ancienne Ressource et le numéro
I de I'ancienne phase.
Chapitre Itr : Implémentation du système SYROCO.
12.2.2.1.3- Initialisation de la boîte aux lettres celluleÆroduit, lecture dela réponse, écriture dans la boîte pour préciser qu'elle a étéconsultée et libération de I'accès.
12.2.2.1.4-La Cellule stocke le nom de la Ressource, le numéro de laphase et les compare au nom de I'ancienne Ressource et aunuméro de I'ancienne phase.
12.2.2.1.5-Si les noms ou les numéros sont différents. faire :12.2.2.1.5.1-Envoi d'un ordre à la Ressource pour stopper la
production.12.2.2.1.5.2-Fermer les sockets.12.2.2.1.5.3-Création de nouvelles sockets pour communiquer
avec le Superviseur et le Produit.12.2.2.1.5.4-Envoi d'un ordre d'usinage à la Ressource.12.2.2.1.5.S-Envoi d'un deuxième message à la Ressource pour
compléter le premier.12.2.2.1.5.6-Aller en 12.
l3-Destruction des boîtes aux lettres serveur/Cellule et Cellule/Produit.l4-Destruction de I'agent Produit.15-Envoi d'un compte-rendu au Superviseur pour signaler que la production est finie.l6-Fermeture de toutes les sockets.l7-Désactivation de la Cellule.
111.2.3.2. L'agent Produit.
L'agent Produit a la particularité d'avoir un code différent à chaque instanciation, Cet agent
est généré par le système en fonction de la solution retenue par le Méta-Obiet. Bien entendu,
une partie de son code est générique, mais tout ce qui concerne le déroulement de la gamme,
c'est-à-dire les ressources utilisées et les temps (débuts et durées), dépend du résultat de la
recherche de chemin. C'est I'agent qui a, potentiellement, la durée de vie la plus courte. En
ef'fet, chaque modification des chemins de gamme entraîne une reconstruction et une re-
compilation des agents Produits concernés.
L'agent Produit est, en quelque sorte, la mémoire de I'agent Cellule. C'est lui qui Ie
renseignera sur les opérations à effectuer lors d'une consultation. Comme tous les agents du
système, ses interlocuteurs restent timités : un agent Cellule et une Ressource, jamais plus.
Avec I'agent Cellute, le Produit communique par le biais de consultations, lesquelles
interviennent à une fréquence de une minute environ. A chaque consultation, I'agent Cellule
demande s'il y a du nouveau sur le système et réagit en fonction de la réponse. Si celle-ci se
97
Chapitre Itr : Implémentation du système SvROCO.
traduit par une fin de phase, la Cellule consulte le Produit afin de savoir quels sont les
paramètres de la phase suivante.
Vis-à-vis de la Ressource, le Produit enregistre les messages afin de les transmettre à
l'agent Cellule lors de la prochaine consultation. Ces messages conespondent au compte-rendu
2, et leur syntaxe a déjà été définie dans les sections "Le Superviseur" (pour "fin phase,,,
"maintenance" et "commentaire") et "La Cellule" (pour "panne"). Bien sûr, au cours de sa
"vie", I'agent Produit communiquera avec plusieurs Ressources différentes, mais une seule à
la fois : celle qui est en train d'effectuer la phase en cours.
Informatiquement parlant, I'agent Produit n'est pas actif en perrnanence ; il n'est exécuté
que lorsqu'on en a besoin. Ainsi, la Cellule I 'exécute à chaque consultation en lui passant sa
question en paramètre et le Produit transmet sa réponse par le biais d'une boîte aux lettre. De
même, il est exécuté par le serveur à chaque arrivée de message réseau en provenance d'une
Ressource, le message lui est passé en paramètre et il l 'inscrit directement dans la boîte aux
lettres que viendra consulter la Cellule par la suite. Nous avons choisi cette solution afin de ne
pas encombrer la mémoire et le processeur avec une application qui n'est utile que
ponctuellement. De plus, cet état de fait simplifie les échanges d'informations Cellule/produit.
Lors de la fin de la production, la Cellule détruit le code de I'agent Produit avant d'êrre
désactivée.
L'organigramme de l'agent Produit est donné par la Figure ltr-4. L'algorithme de l'agent
Produit est le suivant :
I t-Extraction du premier paramètre du message passé au Produit.l]-Si te premier paramètre est "information", faire :
l2.l-si le reste du message conespond à un numéro de phase existant, faire :
| 2. l. I -Récupération des informations concernant la phase à usiner (le nom de la
, I Ressource, la durée de I'usinage et la date de début).12 .2-S inon :
, lZ.Z.l-Le Produir enregisrre "fin".
12.3-Ouverture et Initialisation de la boîte aux lettres Cellule/Produit, écriture desI informations récupérées et libération de I'accès.
98
Chapitre Itr : Implémentation du système syRoco.
l3-Sinon, si le premier paramètre est "Ressource"3.1-Ouverture et Initialisation de la boîte aux
rendu, et libération de I'accès.
, faire :lettres CelluleÆroduit.écriture du compte-
l4-f"nn.ture de la boîte aux lettres.| 5-Désactivation du Produit.
111.2.3.3. L'agent Ressource.
L'agent Ressource reçoit donc de
de cet ordre est du type :
Ia Ceffule les ordres de fabrication (ordre 2). La svntaxe
ressource, produit, ressource informatique de la cellule, no phase, durée,Iocalisation des oièces
dont un exemple pourrait être :
UR3, alpha, roy, 2, 700, CUl
Ce qui signifie que la Ressource TOUR3 doit gérer la phase 2 du produit alpha pendant
700 CMn, que les pièces viennent du CUf et que le Produit avec lequel el le doit
communiquer se trouve sur l 'ordinateur "roy".
Il les transmet à la ressource réelle (ordre 3 dont la syntaxe dépend de la ressource réelle) et
ce transfert peut se faire de deux manières. Dans le cas où la ressource réelle est classique
(c'est-à-dire non instrumentée), les messages seront transmis à I'opérateur soit par le biais de
l'écran de son ordinateur soit par tout autre moyen si I'ordinateur n'est pas présent dans
I'atelier. Ces moyens peuvent, par exemple, être l'édition de fiches de fabrication, I'utilisation
de messageries portables (type TAM-TAM), une transmission vers un automate
programmable, etc. Quel que soit le moyen, les informations seront toujours les mêmes : nom
du produit usiné, numéro de la phase, temps moyen de la fabrication, indication de la
localisation des pièces (en fait nom de la ressource précédente) plus toutes les autres
informations utiles telles que les outils à employer, les remarques faites lors d'usinages
précédents, etc.
99
Chapitre Itr : Implémentation du système sYRoco.
Au cas où la ressource est dite "intelligente" (c'est-à-dire qu'elle est instrumentée et capable
de communiquer directement de manière informatique), toutes ces informations, plus
quelques autres telles que le programme CN, les correcteurs d'outils, etc., lui seront transmises
directement. L'opérateur (s'il existe) en prendra connaissance directement sur l'écran de sa
machine. Il ne lui restera plus qu'à lancer la fabrication, tous les paramètres étant déjà
enregistrés.
De même que pour la Cellule, la Ressource est exécutée par le serveur lors de I'arrivée de
I'ordre. Les données nécessaires lui sont transmises par paramètre et elle se désactive à la fin
de la phase. Ceci, afin de simplifier les échanges d'informations et d'éviter d'encombrer Ie
système par des agents Ressources qui ne seraient pas en état "travail". Au cas où il faudrait
transmettre à la Ressource un ordre d'arrêt (ré-affectation de la production suite à un aléa).
nous utilisons une boîte aux lettres entre le Serveur et la Ressource.
L'organigramme de I'agent Ressource est donné par la Figure Itr-5. L'algorithme de I'agent
Ressource se présente comme suit :
l-Ouverture et Initialisation de la boîte aux lettres serveur/Ressource, lecture des informations
qu'elle contient, écriture dans la boîte pour préciser qu'elle a été consultée et libération de
I'accès.2-Envoi d'un ordre d'usinage à la Ressource réelle.
3-Répéter :
13. t-Tout"s les minutes paires, faire :
l : .1.1- Ouverture et Init ial isation de la boîte aux lettres serveur/Ressource, Iecture des
I informations qu'elle contient, écriture dans la boîte pour préciser qu'elle a été
I consultée et libération de I'accès.
lf . t .Z-Si les informations n'ont pas encore été consultées, faire :
| 3 .1.2.1-Si le message est "s top" , fa i re :
l l . t .z . l . I -a l ler en 4.
13.2-Tout"s les minutes impaires, faire :
ll.Z.l- Ouverture et Initialisation de la boîte aux lettres Ressource réelle/Ressource,
I t..ture des informations qu'elle contient, écriture dans la boîte pour préciser
I qu'.lle a été consultée et libération de I'accès.
lf .Z.Z-Si les informations n'ont pas encore été consultées, faire :
l l .Z.Z.l-Si Ie message est "panne" ou "f in phase", faire :
l l .Z.Z.l . l-Envoi d'un compte-rendu au Produit.
l l .Z.Z.l .2-Envoi d'un deuxième message au Produit pour compléter leII premler.
r00
Chapitre Itr : Implémentation du système sYRoco.
l,, '.)lr?;2r' 3 -A'er en 4
ll.Z.Z.Z.l-Envoi d'un compte-rendu au Produit.
13.2.2.2.2-Envoi d'un deuxième message au Produit pour compléter le
I premler.
l4-Désactivation de la Ressource.
L1.2.4. Le serveur.
Le serveur n'est pas un agent du système. Il n'en est pas moins indispensable à son
fonctionnement. En effet, sur chacune des ressources informatiques du système, se trouve une
application serveur. Son rôle est de recevoir les messages socket destinés aux agents se
trouvant sur le même ordinateur que lui.
Ainsi, chaque fois qu'un agent désire communiquer avec un autre agent, il envoie une
socket vers l'ordinateur hôte de cet agent et c'est le serveur qui la récupère, la pré-traite puis la
re-dir ige vers I 'agent concerné. Cette application est donc, à I ' instar du Superviseur. exécutée
en tâche de fond et ne réagit que lors d'une arrivée socket. Elle créée alors une application fille
(Figure ltr- l) dédiée au traitement du message et se remet immédiatement à l'écoute du réseau.
Chacune des applications filles est structurée de la même manière. Elle effectue un
traitement séquentiel du message afin de savoir à qui il est destiné puis, en fonction du
destinataire et du contenu, elle le transmette soit par une exécution paramètrée, soit par une
boîte aux lettres. C'est dans I'unique but de simplifier I'application serveur que tous nos
messages sont structurés de la même manière à l'émission : un premier identifiant est d'abord
envoyé, c'est lui qui permettra au serveur de connaître le destinataire du message. Puis, le
corps même du message est émis, le serveur Ie transmettra alors à I'agent concerné. Ce corps
de message est lui-même composé de deux parties : un identifiant de message (panne, fin
phase etc.), puis les informations se rapportant à cet identifiant.
Les seules communications qui échappent à cet état de fait sont les consultations
Cellule/Produit qui s'effectuent grâce à une boîte aux lettres et les messages en direction du
@,0
Chapitre Itr : Implémentation du système SYRoco.
Superviseur. En effet, celui-ci dispose d'une partie serveur directement intégré (Deamon).
Nous avons préféré séparer le serveur général du serveur du Superviseur, car celui-ci est
unique (à la différence des Cellules, Produits, Ressources) et sa localisation est parfaitement
connue. Il nous a donc paru inutile de surcharger le code du serveur (dupliqué sur tous les
ordinateurs du réseau) alors qu'une seule machine accueillerait le Superviseur. D'autre part, le
Superviseur occupe une place particulière dans le système, il nous a donc paru plus judicieux
de lui réserver un traitement particulier et différent des autres asents.
111.2.5. Les Outils nécessaires.
111.2.5.1. Opt igam.
Optigam est un outil de recherche de chemins perrnettant de placer des gammes dans un
atel ier de production manufacturière. Pour ce faire, i l ut i l ise la consultation I af in d'obtenir les
informations nécessaires. Cet outil peut traiter une gamme à partir de n'importe quelle phase.
Ceci est très utile en cas de replacement en cours de production. En effet, dans un tel cas, les
gammes à replacer sont déjà en cours de fabrication, il est donc inutile de s'occuper des phases
déjà terminées, seule la phase en cours et les suivantes sont importantes.
,L.2.5.2. Stratégies de replacement.
Suivant les cas, ou suivant le choix de I'entreprise, on peut faire appel à différentes
stratégies de replacement. Toutes n'ont pas la même complexité et, donc, les mêmes temps de
réponse. D'autre part, la validité des solutions proposées est souvent fonction du temps de
calcul. Les différentes stratégies sont :
111.2.5.2.1. Première stratégie.
. Stopper la gamme la moins prioritaire de I'atelier parmi celles qui présentent le plus
grand pourcentage de corrélation avec Ia nouvelle gamme c'est-à-dire la gamme qui a la
t02
Chapitre Itr : Implémentation du système syRoco.
similarité, mesurée par certains indices à définir, la plus importante avec la nouvelle
gamme.
o Replacer la nouvelle gamme puis la gamme déplacée.
o S'il y a un dépassement sur I'une ou I'autre, recommencer llopération du début.
La complexité maximale d'une telle stratégie se définit par :
c = [(l + n)xn]/2 itérations, avec n : nombre de produits dans I'aterier.
111.2.5.2.2. Deuxième stratégie.
Stopper toutes les gammes et toutes les replacer dans I'atelier de la plus prioritaire à la
moins prioritaire.
La complexité maximale d'une telle stratégie se définit par :
C = n itérations, avec n : nombre de produits dans I'atelier
111.2.5.2.3. Troisième Stratégie.
. Placer la nouvelle gamme sans se préoccuper des informations de I'agenda, mais en
privi légiant la solution qui ut i l ise le moins de ressources déjà prises par d'autres
gammes.
o Replacer les gammes modifiées.
o S'il y a un dépassement sur une des gammes à replacer, effectuer la même stratégie.
La complexité maximale d'une telle stratégie se définit par :
ns r /
C = L(p, + l) itérations, avec n : nombre de produits dans I'atelieri = l
et pi : nombre de phases de la gamme considérée.
1L.2.5.2.4. Choix de la stratégie.
La logique informatique veut que l'on choisisse la stratégie ayant, en moyenne, la
complexité la plus faible, ce qui élimine la deuxième solution, car elle présente une
complexité constante de n itérations. En fait, cette solution revient à refaire une initialisation
r03
Chapitre Itr : Implémentation du système sYRoco.
complète du système en cours de production, ce qui prendrait bien trop de temps. Cependant,
dans le cas où I'atelier serait chargé au maximum de sa capacité, les deux autres stratégies se
révéleraient particulièrement catastrophiques en termes de temps de calcul. En effet, dans un
tel cas de figure, ces deux solutions effectueraient le maximum d'itérations possibles avant de
fournir une réponse satisfaisante, or leur complexité maximale est bien supérieure à celle de la
deuxième stratégie.
En fait, le choix de la stratégie ne doit pas être fixé de manière immuable dans le système.
Il convient de choisir la solution en fonction de l'état de l'atelier et de la nouvelle gamme.
Ainsi, si I 'atel ier est part icul ièrement chargé, la deuxième solution est la meil leure. Sinon,
on choisira la première ou la deuxième en fonction du taux de conélation des phases de la
nouvelle gamme avec les gammes déjà en place. Si ce taux est faible, on uti l isera la troisième
solution, sinon, on prendra la première.
Le Tableau ltr-3 récapitule les critères de choix de la stratégie de replacement :
Atel ierfortement
chareé
Atel ierfaiblement
chareé
Taux decorrélationimportant
Taux decorrélation
faible
Stratésie IStratéeie 2Stratésie 3
Tableau III-3 : Critères de choix de la stratégie de repLacement.
Quoiqu'il en soit, il est bon de garder à l'esprit que SYROCO est incapable de miracle.
Dans I'état actuel des choses, il lui est impossible de surcharger I'atelier. Si on essaye
d'imposer une nouvelle gamme dans un atelier déjà chargé au maximum, il y aura
dépassement, c'est obligatoire. La seule chose que puisse faire le système dans un tel cas, c'est
de déplacer le dépassement vers une des gammes les moins prioritaires, c'est-à-dire les moins
urgentes. Quoi qu'il en soit, notons que la discussion au sujet des stratégies de replacement
104
Chapitre Itr : Implémentation du système SyRoco.
reste, pour le moment, entièrement théorique, aucune d'entre elles n'étant implémentée dans le
système.
111.2.5.3. Le Générateur d'agents.
Comme la majorité des applications de SYROCO, la génération d'agents est réalisée par
un programme indépendant et extérieur au Méta-Objet. Ce dernier exécute donc le générateur
en lui passant en paramètre le nom du Produit à générer. Après récupération des informations
utiles et nécessaires dans les fichiers de données, le générateur créée le code source d'un agent
Produit en C++. Une fois ce code sauvegardé, le générateur fait appel à un compilateur C++
afin de compiler le programme exécutable de I'agent. Toutes ces opérations sont réalisées dans
un répertoire spécial où se trouvent les bibliothèques nécessaires à la compilation de I'agent.
Le générateur nettoie alors ce répertoire en effaçant tous les fichiers temporaires (.cpp et .obj)
puis déplace Ie code exécutable vers le répertoire partagé de I'ordinateur maître où les serveurs
pourront venir le chercher pour le transférer à sa destination f inale.
Nous allons maintenant représenter le générateur sous la forme d'un organigramme
(Figure m-6). L'algorithme du générateur d'agents est donné ci-dessous afin de mieux
comprendre la manière dont il fonctionne :
I I : Ecriture du nom de l'agent Produit dans une variable.
l2 : Lecture du fichier agenda.
l3 : Lecture du f ichier solution.
14 : Répéter :
lRecherche dans l'agenda de la ressource utilisée correspondant à la phase i.
lRecherche dans Ie calendrier de la ressource le Produit.
I Sauvegarde des informations.
lSi- i = nombre de phases, faire :
ln l ler en 5.ls inon
l i= i+1Ecriture de I'agent Produit.Exécution du programme "bcc32" pour compiler Ie fichier "error.obj" et celui de I'agent
Produit.cpp.Effacer les fichiers temporaires et le code de I'agent Produit.Déplacement du fichier compilé, dont le nom vient d'être écrit dans une variable, dans le
56
8
r05
Chapitre Itr : Imptémentation du système syRoco.
I répertoire de travail.le : fin de la génération d'agent.
Traitement dela requête
Intenogationd'Optigam
dépassementacceptable ?.
I Appel auGénérateur d'a,qentsl
j
I Envoi de la réponseI au Superviseur ,-__- -_ - -=-_- - -_ .
Figure III-2 : Organigramme de l'agent Méta-Objet
r06
Chapitre Itr : Implémentation du systèmeSYROCO.
Envoi de I'ordreà la Ressource
( - l ) ' > 0
Envoi de I'ordre"commencer" à la
nouvelle Ressource
In , / \ o
lv"'.lt
Consul tat ion du IProdui t i
Figure III-3 : Organigramme de l'agent Cellule.
i Envoi de I 'ordre
r07
Chapitre Itr : Implémentation du système SYROCO.
lEnregistrement du iCompte-Rendu de
1la Ressource l
t
i Renvoi msg
i vers Ce l lu le
Figure III-4 : Organigramme de l'agent Produit
Y1 ^i Kenvol l . ln
1 vers Cellule Ims_9 = Info phase
t08
Chapitre Itr : Implémentation du système syRoco.
( - t ) ' > 0
msg = msg
" ;le seul message que puisse recevoir une Ressource en cours d'exécution en provenance
de la Cellule est l'ordre de stopper la production.
Figure III-5 : Organigramme de l'agent Ressource
Envoi Compte-Renduvers le Produit
109
Chapitre Itr : Implémentation du système SyRoco.
Recherche dans [e calendrierrde la ressource le produit r
t
Sauvegarde desIntbrmations
v
Ecriture du sourcede l 'agent Produit
t
Compilation du Isource- ' - . . - - - - . - - -
i
i
Effacement des
l
Ji-,
Figttre III-6 : Organigramme du générateur d'agents
i l0
Chapitre Itr : Implémentation du système SYRoco.
lll.3. La communication.
Comme nous l'avons déjà mentionné, la communication est une des composantes les plus
importantes de SYROCO. n nous a donc paru opportun de faire figurer une section qui en
explique le fonctionnement ainsi que les différents médias utilisés. Par conséquent, nous
aborderons ici, le réseau de manière physique et les protocoles informatiques que nous
utilisons et qui pennettent de gérer le transfert des informations. Nous étudierons aussi le
mécanisme de socket, permettant de faire transiter des informations entre deux points d'un
réseau 15)t721et, enfin, la transmission des données entre deux processus s'exécutant sur la
même ressource informatique.
111.3.1. Le réseau.
SYROCO est prévu pour fonctionner à I'aide d'un réseau local, c'est-à-dire un réseau dont
l'étendu est de I'ordre du kilomètre et dont le média est physique (câbles coaxiaux, fibres
optiques, paires torsadées, etc.) et non d'ordre électromagnétique (liaisons radio). Dans une
telle configuration, le débit d'informations est de I'ordre du Mbits par seconde.
Bien qu'a priori,la topologie d'un tel réseau puisse être quelconque, celle que nous avons
utilisée, non par choix, mais par obligation, est une topologie en étoile, c'est à dire un réseau
point à point. Cependant, attendu que nous ne gérons pas les communications au niveau de Ia
couche physique, la topologie du réseau employé nous importe peu. La seule contrainte est
que le système d'exploitation des ressources informatiques et le matériel réseau employé
soient bien configurés.
En fait, I'important, pour nous, fut surtout les couches réseau et transport du modèle
OSI-ISO [69] et, en particulier, les protocoles qu'elles utilisent : en I'occurrence, IP et TCP.
l i l
Chapitre Itr : Implémentation du système SyRoco.
111.3.2. Protocole TCp/lp.
La multiplication de réseaux locaux qui n'offraient de services qu'à un groupe restreint
d'utilisateurs a vite atteint ses limites. Le besoin s'est alors fait sentir de dépasser le cadre local
des échanges' Cependant, I'hétérogénéité des différents réseaux constituait un frein important
à la satisfaction de ce besoin. Ainsi, Ia DARPA (Defense Advanced Research project Agency)
a demandé à ce que des recherches soient menées dans I'objectif de construire un "réseau
logique" perrnettant I'interconnexion de tous les réseaux, quelle que soit leur technologie.
L'aboutissement de cette recherche correspond à la formalisation de protocoles correspondant
aux couches réseau, transport et application du modèle OSI à sept couches. On y fait
généralement référence en nommant les deux plus importants, c'est-à-dire TCpÂp. C'esr à ces
deux protocoles que nous allons nous attacher plus particulièrement [69].
Le protocole IP (Internet Protocol) est un protocole de niveau réseau servant à l'échan_se
de datagrammes, qui sont des paquets d'informations, en mode non connecté. Ce protocole ne
garantit pas I'arrivée à bon port des messages. Cette fonctionnalité sera introduite au niveau de
la couche supérieure avec le protocole TCP.
Le protocole IP perrnet donc de spécifier le format d'un datagramme (ensemble de
données), lequel est constitué essentiellement d'un en-tête permettant son identification et des
données elles-mêmes. En descendant dans les couches inférieures, cet objet sera encapsulé
dans une trame physique. Le datagramme complet constituera la partie donnée d'une trame, le
reste étant constitué de diverses informations spécifiques au protocole utilisé.
Les informations de I'en-tête sont particulièrement nécessaires au contrôle de la
fragmentation. En effet, un message parvenant depuis la couche supérieure à la couche IP
(couche TCP) peut éventuellement être découpé en plusieurs datagrammes IP. L'en-tête
contient donc des informations permettant la reconstitution d'un message à partir des
TT2
Chapitre Itr : Implémentation du système SYROCO.
fragments qui le constituent. D'autre part, tout datagramme IP contient un champ destiné à
éviter qu'il reste sur le réseau indéfiniment.
Le protocole TCP (Transport Control Protocol) est un protocole de la couche transport,
supérieure à la couche réseau.
Ce protocole a pour but de permettre la communication entre activités (processus) sur des
machines distantes. Une telle activité constitue un point d'entrée dans le système. Or, pour
pouvoir dialoguer avec elle, il est nécessaire de pouvoir la désigner. Seulement, comme la
désignation de processus est différente d'un système à I'autre, il s'avère indispensable de
définir une méthode d'identification indépendante des systèmes. Le principe retenu est de
séparer I'identité du processus réalisant une fonction donnée de cette fonction elle-même. La
notion de service est privilégiée par rapport à celle de processus. Il est ainsi parfaitement
possible qu'un même service soit assuré par plusieurs processus ou qu'un même processus
assure plusieurs services. Le concept Internet correspondant à cela est Ie concept de port.
Ainsi, il existe un certain nombre de ports identifiés par un nombre entier et c'est par leur
intermédiaire que le module TCP réalisera le multiplexage.
Il permet d'offrir un service sûr de transport de flots d'octets : les octets émis d'un côté de la
connexion sont délivrés dans le même ordre de I'autre côté de celle-ci. Notons que ce flot
d'octets n'a aucune structure particulière et que la communication est réalisée en mode duplex,
ce qui signifie qu'elle supporte une communication simultanée dans les deux sens.
Le problème principal que doit résoudre le protocole est d'assurer un transfert fiable de
I'information en s'appuyant sur des mécanismes que ne le sont pas. Pour cela, le protocole
utilise différents mécanismes sous-iacents. Parmi ceux-ci, nous mentionnons :
111.3.2.1. L'acquittement.
Cette technique consiste à attendre que soit parvenu un accusé de réception, émis par le
u3
Chapitre Itr : Implémentation du système SYROCO.
destinataire d'un paquet, avant d'envoyer le paquet suivant. Si cet accusé de réception ne
parvient pas dans un laps de temps donné (principe du timeout), le paquet est ré-émis. Les
duplications éventuelles de paquets sont détectées à I'aide d'un numéro d'ordre attribué à
chacun d'entre eux.
t,1.3.2.2. Les fenêtres à anticipation.
Cette technique (sliding window) est une amélioration de la précédente. Elle permet I'envoi
de plusieurs paquets consécutifs sans attendre I'acquittement d'un paquet pour émettre le
suivant. Ainsi, par exemple, si une fenêtre de tai l le l0 contient à un instant donné dix paquets
de numéros de séqueflcÊS n1, n2,... . , h1s, celâ signif ie que ces dix paquets ont été émis et que
leur acquittement n'est pas arrivé. Lorsque I'acquittement du paquet nl arrivera, cela
provoquera un gi issement de la fenêtre d'une posit ion, autorisant l 'émission d'un nouveau
paquet n11. Ce mécanisme est également uti l isé du côté récepteur d'une connexion.
Les services fournis par Ie protocole TCP sont au nombre de 4. Il s'agit de :
o la demande d'ouverture de connexion. Ce service à une forme active du côté de
l'initiateur de l'appel et une forme passive du côté de I'appelé,
o I 'expédit ion, avec Ia possibi l i té :
' d'envoyer des messages urgents,
de forcer I'envoi d'un message (afin qu'il soit émis sans que le module TCP ne le
regroupe avec un autre).
o la réception avec la possibilité d'accéder à un message urgent directement,
o la fermeture d'une connexion.
111.3.3. Les sockets.
Les sockets Berkeley offrent un mécanisme général de communication entre deux
processus quelconques e[ ce, qu'ils appartiennent à un même système ou non 172]. Ce
I 1 4
Chapitre Itr : Implémentation du système SYROCO.
mécanisme peut, en fonction du but recherché, utiliser le protocole TCP ou le protocole UDp
(User Datagramme Protocol). La meilleure manière de comprendre le mécanisme des sockets
est de travailler par analogie. Lorsque deux individus désirent communiquer, ils peuvent
utiliser soit le courrier, soit le téléphone. Dans ce cas, chacune des personnes doit disposer
d'un point de contact : respectivement une boîte aux lettres ou un poste téléphonique. Une
socket n'est rien de plus que l'équivalent de I'un de ces objets. Une socket est donc un point de
communication par lequel un processus pourra émettre ou revoir des informations.
La principale différence entre ces deux objets réside dans la manière de communiquer.
Dans une boîte aux lettres, on dépose un message complet alors que le téléphone perrnet
I'envoi de flot d'informations dont la structure n'est pas clairement définie. Cette différence est
prise en compte lors de la création de la socket en modifiant son type. D'autre part, les
protocoles sous-jacents ne sont pas les mêmes : le protocole UDP servira à la communication
par messages, le protocole TCP permettra I'envoi d'un flot d'informations. C'est ce dernier
mode que nous avons choisi, car il reste Ie plus souple d'utilisation : en effet, les informations
échangées n'ont pas de structure interne définie par le mécanisme, toute donnée peut donc être
émise et reçue, quelle que soit sa taille eVou son type. Cette flexibilité extrême nous
avantageait, puisque nos messages sont de natures très différentes. De plus, seul ce mode nous
permet d'obtenir les propriétés suivantes :
o fiabilité de la transmission : aucune donnée émise n'est perdue,
o préservation de I'ordre : les données arrivent dans I'ordre où elles ont été émises,
. non-duplication de données,
. communication en mode connecté : la connexion est établie entre deux points avant
le début de la communication et, donc, une émission depuis une extrémité est
implicitement destinée à I'autre extrémité. De plus, ce mode de communication
permet au demandeur de savoir rapidement si le receveur accepte de communiquer
avec lui, comme lors d'une communication par téléphone : on ne peut discuter que
si le receveur de I'appel décroche,
r 15
Chapitre Itr : Implémentation du système SvROCO.
o émission de messages urgents : possibilité d'envoyer des messages hors du flot
normal qui sont donc accessibles immédiatement.
Une autre fonctionnalité importante concerne les points de communication joignables.
Ainsi, un téléphone intérieur à une entreprise ne permet de joindre que des postes intérieurs à
cette même entreprise, alors qu'un poste extérieur perrnettra de sortir. Il en va de même avec
les sockets, dont on définira le champ d'accès grâce à la caractéristique de domaine. Bien sûr,
comme notre système est prévu pour fonctionner sur, d priori, n'importe quel système
informatique, voire sur un ensemble de systèmes différents en même temps (UND( et
WINDOWS 95), nous avons choisi de configurer nos sockets sur le plus large domaine
possible : le domaine Internet.
111.3.4. Partage d' informations.
Si le mécanisme des sockets est part icul ièrement uti le pour transmettre des intormations
entre deux processus ne se trouvant pas sur Ia même ressource informatique, i l devient
totalement inutile lorsqu'il s'agit de partager des informations entre deux processus s'exécutant
au même endroit. Or, il s'agit là d'une configuration que nous retrouvons souvent dans
SYROCO. En effet, lorsque le serveur reçoit un message via les sockets, il lui faut encore
pouvoir le transmettre à I'agent visé. De même, les couples d'agents Cellule et Produit
s'exécutent sur la même ressource informatique, par conséquent les consultations et leurs
réponses ne s'effectuent pas par le biais de sockets. Pour tous ces cas de figure, il nous a fallu
trouver un autre média pour communiquer, pour partager des informations. Deux solutions se
sont offertes à nous. et nous avons décider de les utiliser toutes les deux. car elles sont en fait
complémentaires.
111.3.4.1. L'exécution paramètrée.
La première méthode employée, la plus simple, est I'exécution paramètrée. Il s'agit
i l6
Chapitre Itr : Implémentation du système SyRoco.
d'exécuter un module en lui passant en paramètres de démarrage les informations utiles. Cette
méthode est particulièrement utile lorsque :
o I'application considérée n'est pas déjà en cours d'exécution,
o le message à transmettre est plutôt simple.
Nous utilisons cette méthode, en particulier lors de la consultation du Produit par la Ceilule.
En effet, puisque Ie Produit n'est exécuté qu'à la demande, il est facile pour I'agent Cellule de
le lancer en lui passant en paramètre la question de sa consultation : "date début" ou
"information".
Les agents Ressources, ainsi que I'outil Optigam, sont exécutés de la même manière. Là où
se présente un problème avec cette manière de faire, c'est lorsque deux applications, déjà en
cours d'exécution, doivent échanger des données. Dans ce cas, nous utilisons la deuxième
solution dite de mémoire partagée.
111.3.4.2. La mémoire partagée.
Ce cas de figure concerne surtout les réponses que font les applications à une consultation.
En effet, la question est passée en paramètre, mais il est bien évident que la réponse ne peut
pas suivre le même chemin. Car, à ce moment-là, les deux applications sont toutes deux en
cours d'exécution, il devient donc impossible de réaliser une exécution (paramètrée ou non).
Ainsi, dans ces cas-là, nous utilisons de la mémoire partagée. Cette fonctionnalité, accessible
tant sous WINDOWS 95 que sous UND(, est proche du principe de la boîte aux lettres. En
effet, une zone mémoire (la boîte) est créée dans le système et est rendue accessible par tous, à
condition qu'ils en connaissent I'adresse. Alors, chaque application écrit dans cette zone les
informations qu'elle doit transmettre (elle dépose ses lettres) et les autres processus viennent
chercher le courrier-
Notons, cependant, que la simplicité du mécanisme n'est qu'apparente. En effet, pour des
raisons de persistance et de validité de I'information, il ne faut pas que le receveur vienne lire
tt7
Chapitre Itr : Implémentation du système SYROco.
trop tôt dans la boîte ou que l'émetteur réécrive trop vite et efface ses messages précédents.
Pour palier à cet inconvénient, il est nécessaire d'instaurer un système de sémaphore.
Pour reprendre I'analogie d'une véritable boîte aux lettres, pensez à I'indicateur rouge que le
facteur relève sur les boîtes nord-américaines. Il s'agit exactement d'un sémaphore. Ainsi, le
receveur sait quand il a un message, et peut donc aller lire en toute sécurité. De la même
manière, lorsque le sémaphore est rabaissé, l'émetteur sait qu'il peut écrire à nouveau : les
messages précédents ont été lus.
C'est donc par ce principe, appelé "fichier de mappage" sous WINDOWS 95 et "segment
de mémoire partagé" sous UND(, que le Produit répond à la consultation de la Cellule,
qu'Optigam retourne sa solution ou que la Ressource est avertie d'un ordre d'arrêt de la
production.
111.3.5. Récapitulatif des messages.
Dans le Tableau III-4, nous récapitulons les différents types de messages échangés dans
SYROCO.
Classification Messages
Ordre I suDerviseur produit
cel lule produit. modification
Ordre 2 uslner ressource, produit, hôte, no phase, durée, localisation pièces
Ordre 3 o dépend du type de la ressource réelle
Consultaton l ? déoend du tvoe de la base de données
Consultaton2 samme
Consultation 3
panne produit, ressource, début, durée, commentaremalntenance ressource. produit, début, durée, commentare
fin phase produit, ressource, numéro, date
commentalre le commentaire
ouestion information, no de phase
reDonse ressource, temps d'usinage ou fin
Consultation 4 cellule date-début, produit, no phase
Comnte-rendu I ? déoend du tvpe de la ressource réelle
I 1 8
Chapitre Itr : Implémentation du système SyROcO.
Compte-rendu 2Danne produit, ressource, début, durée, commentairé
malntenance ressource, produit, début, durée, commentairefin phase plgduit, ressource, numéro, date
commentaire le commentaire
Compte-rendu 3Danne produit, temps restant, ressource, début, durée, commentaire
malntenance ressource, produit, début, durée, commentairefin phase produit, ressource, numéro, date
commentarre le commentaireREQUETE îlot(produit)=?, no phase, temps maximum
Tableau III-4 : Récapitulatif des messages.
lll.4. Synchronisme / Asynchronisme.
L'un des principaux problèmes que nous ayons eu à résoudre lors de la programmation fut
le synchronisme des applications. En effet, les fichiers de données sont lus et modifiés par
plusieurs modules et les communications ne fonctionnent que si les deux intervenants sont
synchrones. Pour ce qui est de I'accessibilité des fichiers, le problème fut résolu assez
simplement. Afin d'éviter que deux applications ne modifient le même fichier en même temps,
il nous a suffi d'exploiter les fonctionnalités des systèmes qui imposent qu'un fichier ne soit
pas ouvert simultanément par deux applications. Ainsi, lorsqu'une application doit travailler
sur un fichier, elle le garde ouvert durant toute la durée du traitement : elle n'utilise pas
d'image du fichier. Ainsi, si une autre application veut ouvrir le fichier à son tour, elle en est
empêchée par le système et doit attendre qu'il soit libéré. C'est en fait un système de
sémaphore.
Pour ce qui est de la communication, le problème est plus difficile. En particulier, pour ce
qui est de la communication par mémoire partagée. En effet, la communication par sockets
utilise un système de serveurs qui sont en permanence à l'écoute. Il s'agit donc bien d'une
communication asynchrone, mais dont I'un des acteurs est en perrnanence prêt. Le
synchronisme devient donc intrinsèque. Par contre, pour ce qui est de la communication par
boîte aux lettres, il fallait s'assurer que les messages transmis seraient lus en un temps court et,
l 1 9
Chapitre Itr : Implémentation du système SYRocO.
surtout, avant qu'ils ne soient effacés par le message suivant. En fait, c'est un problème sans
solution. Le mieux que nous puissions faire est de simuler le fonctionnement d'un serveur en
forçant I'une des applications à lire le plus fréquemment possible le segment de mémoire
partagée afin de vérifier qu'il n'y a rien de nouveau d'inscrit. Si c'est Ie cas, elle le remplace par
un identificateur marquant le fait qu'elle ait lu le message. Du côté de l'émetteur, nous avons
fait en sorte qu'il n'écrive rien tant qu'il n'a pas détecté la présence de cet identificateur. Ce
n'est pas un fonctionnement synchrone, mais une manière de s'arranger pour passer outre
I'asynchronisme des systèmes monoprocesseurs.
Bien évidemment, de tels verrous ne sont efficaces que si I'asynchronisme du système ne
devient pas trop important. C'est pour cette raison que le système est avare de boîtes de
messages destinées à renseigner I 'ut i l isateur et que toute la visualisation est réservée à une
application à part entière. En effet, les boîtes de dialogue, en particulier sous Windows 95.
sont parfaitement asynchrones et augmentent considérablement I'asynchronisme du système.
Cependant, la nature asynchrone de Windows 95 nous pose tout de même quelques
problèmes. En effet, puisque Windows ne permet à une application de travailler que de temps
en temps, celles-ci prennent du retard les unes par rapport aux autres. Sur un système
particulièrement chargé, il peut s'écouler plusieurs secondes, voire plusieurs dizaines de
secondes, avant qu'une application ne reprenne la main. Cet état de fait est la principale raison
des retards observés lors de la remontée des messages : I'agent concerné ne peut émettre que
s'il a la main. La solution à ce problème serait de pouvoir changer les priorités d'exécution des
modules, afin qu'ils aient des priorités sensiblement égales à celles du système (KERNEL).
il1.5. Portabilité.
La portabilité fut un de nos soucis majeurs. En effet, comme nous voulions que SYROCO
puissent être utilisé sur un parc informatique, a priori, inconnu, il nous fallait une application
t20
Chapitre Itr : Implémentation du système SyRoco.
portable. Bien qu'il existe une multitude de systèmes et d'OS, nous avons décidé, dans un
premier temps de nous limiter aux plus répandus d'entre eux : UND( et WINDOWS 95.
Pour réaliser une compatibilité la plus parfaite possible des codes de nos modules vis-à-vis
de ces systèmes, il nous a fallu développer en utilisant un langage C++ le plus standard et le
plus portable possible : notre choix s'est donc porté sur le C ANStr. Ainsi, tous nos modules
sont écrits de cette manière et seuls quelques changements mineurs, pris en compte à I'aide de
"define", sont à effectuer avant de les compiler dans le système cible.
ll y a deux exceptions à cet état de fait. La première concerne les serveurs. En effet, comme
expliqué précédemment, cette application nécessite de pouvoir créer une application i i l le
destinée à traiter la requête socket. Or, s' i l s 'agit d'une opération simple en UND(. el le devient
ardue et nécessairement différente sous WINDOWS 95. Il existe donc deux types de serveurs
différents, bien qu'ayant les mêmes fonctionnali tés : un pour UNX, I 'autre pour WNDOWS
95. Bien sûr, le même problème se pose pour le Deamon et trouve la même solution. Ceci
renforce [ ' idée d'avoir séparé le Deamon du Scheduler qui, lui, reste inchangé. Notons.
cependant, que le Deamon est unique dans le système alors qu i l y a plusieurs serveurs. Ainsi,
s'il peut être nécessaire d'avoir les deux types de serveurs dans SYROCO, il n'y aura routoLlrs
qu'un seul des deux types de Deamon.
La deuxième exception concerne les échanges de données entre deux applications. Sous
UND(, nous utilisons les segments de mémoire partagée qui permettent un échange rapide et
fiable. Sous WINDOWS 95, cette fonctionnalité existe mais est gérée de manière dit-ferente.
Nous utilisons donc des fichiers de mappage qui fonctionnent à la manière d'une boîte aux
lettres : une application y dépose un message, qu'une autre application ira lire par la suite.
Cependant, si les instructions sont différentes, Ia philosophie reste la même entre ces deux
modes de communication. Nous pouvons donc programmer les deux méthodes et choisir à la
compilat ion, à I 'aide de"define", cel le que nous uti l isons, en fonction du système cible.
t2r
Chapitre Itr : Implémentation du système SyRoco.
Mis à part le C++, nous avons utilisé aussi le langage TCL/TK. Là, il y a encore moins de
problèmes, car, justement, ce langage fut inventé pour réaliser des applications portables.
Quant aux sockets, elles sont parfaitement implémentées sous WINDOV/S 95, bien que
venant du monde UND(. Basées sur le protocole TCP/IP, elles permettent la communication
entre les deux mondes sans aucun problème et s'utilisent de ta même manière d'un côté
comme de I'autre.
Pour finir, nous dirions que, tel qu'il est actuellement, le système est utilisable sous UND(
et sous WINDOWS 95 de manière certaine. Mais, à notre avis, il est capable de fonctionner
sur toute plate-forme 32 bits, moyennant quelques modifications mineures.
lll.6. Conclusion.
Nous avons pu étudier dans ce chapitre l ' implémentation du modèle théorique. que nolrs
avions spécif ié à I 'aide des Statecharts, présenté au chapitre II . I l apparaît que, si le svsrème
reste complexe de par sa philosophie, la plupart de ses agents se révèlent très simples à
implanter. En effet, les agents Cellule, Produit et Ressource, en raison de leur nature purement
réactive, ne nécessitent pas un code important. Ainsi, seuls deux agents du système
(Superviseur et Méta-Obiet) durent faire l'objet d'une étude informatique poussée.
Ce chapitre nous a aussi permis de faire le point sur les messages échangés par le système.
Nous les avons entièrement spécifiés en explicitant leur syntaxe. Chaque agent du système ne
peut envoyer ou recevoir que, et uniquement que, les messages que nous avons spécifiés dans
ce chapitre. Comme nous le présentions lors de la modélisation, l'échange d'information reste
le point crucial du système, SYROCO exige un flux d'information assez important et toute sa
fiabilité et sa robustesse en dépendent. En effet, il semble que le point faible du système soit la
connexion réseau (au sens physique) entre les ordinateurs. Si le réseau tombe en panne,
SYROCO suit. Il s'agit cependant d'un facteur sur lequel nous ne pouvons pas intervenir
t22
Chapitre Itr : Implémentation du système SyROCo.
directement. La seule solution que nous ayons est de prévoir un système de fichier historique
et une reprise sur erreurs. Couplé avec un système d'alarme automatique, à chaque niveau du
système, cela devrait nous permettre de détecter un problème réseau, d'en avertir le
responsable et de pouvoir reprendre le pilotage dès que le problème réseau est réglé.
L L )
Chapitre [V : Exemple académique.
. Fraiseuse : F.
o Tour : T,
o Aléseuse : A,
o Centre d'Usinage : CU,
o Rectif ieuse : R,
o Fraiseuse Horizontale : FH.
Dans cet atelier, nous avons décidé de faire passer lreize produits différents. Ces treize
produits sont identifiés par un numéro et leurs gammes standards sont données par le Tableau
IV-2. Dans ce tableau, les chiffres indiqués en gras (1) donnent I'ordre des phases. Les
nombres donnés en ital ique et entre parenthèses ((200)) indiquent les temps standard d'usinage
de la phase en unité de temps (dans I 'exemple, i l s 'agit de I 'unité technologique usuelle : la
Centiminute ou centième de minute : CMn). Ces temps ne sont pas les temps unitaires. I l
s 'agit des temps f inaux qui prennent en compte le nombre de pièces de chaque t l pe ù
fabriquer.
Ress.P F T A CU R FH
2.00/8.335.32 t8 .33?.321r .00r0.00/8 33
)aJ
A
5 5.32lr0.00
6 2.00t2.665.32/2.6610.0/10.0
78
9 r0.00/2.66r4.0013.612.00/1.002.00/4.332.00/6.00
0I1
1J
L̂+ 2.00/10.00
5 5.32t4.33
6 10.00/4.3314.00i 8.337
Tableau IV- I : Répartition des ressources par tlpe.
t26
Chapitre [V : Exemple académique.
r Fraiseuse : F.
. Tour : T,
. A léseuse: A,
o Centre d'Usinage : CU,
. Rectif ieuse : R,
o Fraiseuse Horizontale : FH.
Dans cet atelier, nous avons décidé de faire passer treize produits différents. Ces treize
produits sont identifiés par un numéro et leurs gammes standards sont données par le Tableau
lV-2. Dans ce tableau, les chiffres indiqués en gras (l) donnent I'ordre des phases. Les
nombres donnés en ital ique et entre parenthèses ((200)) indiquent les temps standard d'usinage
de la phase en unité de temps (dans I 'exemple, i l s 'agit de I 'unité technologique usuelle : la
Centiminute ou centième de minute : CMn). Ces temps ne sont pas les temps unitaires. I l
s 'agit des temps f inaux qui prennent en compte le nombre de pièces de chaque trpe ù
fabriquer.
Ress.P F T A CU R FH
I
I 2.00/8.335.32/8 332.321t .0010.00/8.33
-J
4
5 5.32l 10.006 2.00/2.66
5.32t2.6610.0/10.0
78
9 t0.00t2.6614.00t3.672.00/ l .002.00t4.332.00/6.00
10ilt tt aI J
4 2.00/10.00
5 5.32t4.336 r0.00/4.33
14.00/8.331
Tableau IV- L' Répartition des ressources par type.
[ 6
Chapitre IV : Exemple académique.
lV. Exemple académique.
1V.1. Présentation de I'exemple.
Afin de pouvoir vérifier la réactivité
académique. Nous avons donc défini
ressources de sept types différents.
système, nous l'avons appliqué à un exemple
atelier (cf. Figure [V-l) composé de dix-sept
du
un
rËlt I{
ffiFFAISEUSE I !
,Ft l
i f f i -"'iil"*'ffi'",ffi""'''ffi
1j,:,qÈâJ - H
iË"'ffi
rÊttï{W
R
N ' -
I luesday, I 6 Septernber ' l 997 | 1 6 08 07
Fipure IV-l : Présentation de l'atelier.
Le nombre de ressources par type, ainsi que leurs coordonnées physiques en unités de
distance, est donné par le Tableau tV- I où sont grisées en plus foncé les ressources uniques.
Note : les abréviations utilisées dans la présentation de I'exemple sont :
o Perceuse : P,
I a J
CHAPITRE IV
EXEMPLE ACADEMIQUE
t 1 Àt L +
Chapitre Itr : Implémentation du système SYROCO.
directement. La seule solution que nous ayons est de prévoir un système de fichier historique
et une reprise sur erreurs. Couplé avec un système d'alarme automatique, à chaque niveau du
système, cela devrait nous permettre de détecter un problèrne réseau, d'en
responsable et de pouvoir reprendre le pilotage dès que le problème réseau est réglé.
Chapitre IV : Exemple académique.
Bien qu'académique, cet exemple n'est pas le fruit du hasard. Nous I'avons voulu ainsi afin
de faciliter les tests tout en vérifiant les limites du système. En effet, les temps de phase sont
courts et, donc, assez peu réalistes. Cependant, de tels temps nous perrneftent d'avoir une
production à la durée de vie assez courte (le produit le plus long demande vingt-cinq minutes
de fabrication) d'où un temps de test assez court, ce qui nous perrnet de faire plusieurs tests de
manière enchaînée. D'autre part, la principale caractéristique du système étant sa réactivité,
plus les temps de phase sont courts, plus SYROCO doit réagir vite afin de ne pas observer de
trou dans la production en cas de problème. Ainsi, en fixant des temps de phase minimum à
200 CMn, le système doit avoir un temps de réaction inférieur à la minute pour être considéré
comme temps réel.
Outre les contraintes de temps, nous avons introduit dans I 'exemple des contraintes de
charge. En effet, même si I'atelier n'est pas chargé au maximum de sa capacité de manière
globale ( i l y a des ressources inactives en cours de production), la charge des ressources
uti l isées est importante. La Figure [V-2 donne le nombre moyen de produits que chaque
ressource (en fonction de son type) devra traiter au cours de la production. En analysant cette
figure, il est aisé de remarquer que si les ressources de type F, T et P n'ont qu'un faible nombre
de produits à traiter, les ressources FH, R et surtout A en ont un nombre très important. Ceci
est dû au fait que ces ressources sont seules de leur type. Ceci démontre bien qu'il s'agit de
goulots d'étranglement et que la production dépend en grande partie du bon fonctionnement de
ces trois ressources. D'autre part, la présence de ces goulots nous permettra de savoir si le
système est capable de les gérer sans problème.
ProduitP F T A CU R FH
I 3 (200) l (200) 4 (200) 2 (300)2 2 (200) 3 (200)r (200)1J 2 (200) | (300)4 2 (200)3 (s00) 4 (200) L (800)
I2 ' l
Chapitre [V : Exemple académique.
5 | (800) 2 (500)6 3 (800)2 (200) | (200) 4 (200)7 2 (200) 3 (300) l (200)8 2 (300) 1(200)3 (300)9 3 (200)| (200) 2 (400)t0 r (200) 3 (200)2 (300)il | (900) 2 (200)t2 2 (200) | (200)I tT J 3 (500) | (200)
5 (400)2 (900) 4 (600)
Tableau IV-2 : Gammes et temps de phases des produits.
4,00
3,
2,00
1 ,00
0,00
Figure IV-2 : Répartition des produits par ressources.
|V,2. Chronogramme de l'application.
Avant de pouvoir commencer à travail ler avec cet exemple, i l nous a fal lu établir des
objecti fs de production en rapport avec les produits que nous avions à traiter. Bien entendu, à
terme, les objectifs de production devront être générés en externe au système, en fonction des
résultats de la planification.
Les objectifs de production sont contenus dans un fichier structuré comme dans Ie
Tableau [V-3 :
Produit Priorité date limite Déià traitée ? fluxPI 4 Au ourd'hui. T0+2h Non 100P2 9 Au ourd'hui, T0+2h Non 500P3 t2 Au ourd'hui, T0+2h Non 200
r28
Chapitre [V : Exemple académique.
P4 2 Auiourd'hui, T0+2h Non 750P5 l Auiourd'hui, T0+2h Non 820P6 a
J Auiourd'huT0+2h Non 100P1 t0 Au ourd'huT0+2h Non 250P8 5 Au ourd'hu T0+2h Non r000P9 6 Au ourd'hu T0+2h Non 650
P10 8 Au ourd'hu T0+2h Non 300P l l il Au ourd'hu T0+2h Non 450P12 t ô
I J Auiourd'huT0+2h Non 500Pl3 Auiourd'huT0+2h Non 750
Tableau IV-3 : Structure des objectifs de production.
La priorité est calculée en fonction du temps prévisionnel total d'usinage et du nombre de
ressources uti l isées par chaque produit. Ainsi, I 'ordre des priori tés croit à mesure que le temps
prévisionnel d'usinage décroît. Le nombre de ressource uti l isé intervient en cas d'égali té de
temps de fabrication : dans ce cas, le produit qui ut i l ise le plus de ressource obtiendra la
priori té la plus forte. Pour des raisons de test, la date l imite de la production n'est pas i ixe.
mais est calculée en fonction de la date de début du test. On accorde à chaque produit deux
heures pour être fabriqué.
La colonne "déjà traitée ' l ' du Tableau fV-3 existe afin de permettre au Superviseur de
savoir quels produits sont déjà en production. Cette information est part icul ièremenr
importante lors de I 'ajout d'une nouvelle gamme. En effet, puisque les objecti fs de production
ne sont pas effacés tant que la production concernée n'est pas entièrement terminée. i l fal lait
que le Superviseur puisse faire. iaci lement, la différence entre une entrée déjà traitée et une
nouvel le .
Note : les objectifs de production ne sont effacés que lorsque le produit correspondant a été
entièrement usiné et non pas dès que le système les a pris en compte. Cette gestion des
informations fut établie afin de pouvoir garder une trace de ce qui est en train d'être usiné dans
I'atel ier, soit pour vérif ication par I 'ut i l isateur, soit pour ré-init ial isation du système après un
problème d'ordre informatique.
t29
Chapitre fV : Exemple académique.
Toutes les données d'entrées étant fixées, nous avons pu effectuer la série de test. Ces tests
furent réalisés sur trois ordinateurs, nommé "daniel", "dams" et "maryam", respectivement un
Pentium 200+, un Pentium 133 et un Pentium 100. Le Superviseur fut installé sur la plus
puissante des machines et la gestion des Ressources fut partagée entre les trois ordinateurs,
comme le montre le Tableau fV-4. L'ordinateur "daniel" étant le plus puissant, il fut plus
chargé en agents Ressources.
La première action du système est donc I'initialisation. Le Superviseur va prendre les
objectifs de production et les traiter par ordre de priorité. Chaque exécution d'Optigam, de
même que chaque couple Cellule/Produit résultant, sera réalisée sur un ordinateur différent. Il
est impossible de prévoir, a priori , quel ordinateur hébergera quel couple, attendu que cela
dépend uniquement de la charge (en terme d'uti l isation CPU) courante des ordinateurs. Une
trace est gardée dans un f ichier événement. Par exemple, l 'un de nos tests u donné la
répartition donnée par le Tableau [V-5.
Tableau IV-4 : Répartition des Ressottrces par ordinateur.
RECTIFIEUSE5PERCEUSET PERCEUSE6
TOUR3 PERCEUSES FRAISEUSE9FRAISEUSEI3 FRAISEUSEIOFRAISEUSEH I4 FRAISEUSEI I
FRAISEUSEI2ALESEUSEI5
Ordinateur Produit Heure de début ducalcul
Heure de fin ducalcul
Création sur danie de PRODUIT I3 6:22:41:040 6:23:06:02Créa on sur danie de PRODUIT4 6:23 :08 :016 6:23:21:40Créaton sur danie de PRODUIT6 6:23:23:060 6:23 :37 :05Création sur danie de PRODUIT I 6:23:39:025 6:23:57: lOCréation sur dams de PRODUIT8 6:73:59:024 6:24:12:92Création sur dams de PRODUIT9 6:24:15:023 6:24:28:68
Création sur dams de PRODUIT5 6:24:30:088 6:24:44' ,12Création sur dams de PRODUITlO 6:24:46:031 6:25 :00 :10Création sur dams de PRODUIT2 6:25:02:030 6:25 :15 :86
r30
Chapitre [V : Exemple académique.
Création sur dams de PRODUITT 16:25: l8:006 l6 :25 :31 :68Création sur marvam de PRODUIT1 l l6:25:33:088 l6 :25 :46 : l8Création sur maryam de PRODUIT3 l6:25:48:038 I6:26:01:45Création sur dams de PRODUIT I2 l6:26:03:070 16:26:17:27
Tableau IV-5 : Exemple de distribution des calculs.
Le chronogramme d'utilisation des ressources réelles (tableau de GANTT) est donné par la
Figure tV-3. Ce chronogramme ne fait pas apparaître de différences entre les produits, seul
I'enchaînement des tâches et les temps d'inactivité sont montrés. La Figure fV-4 montre, à tirre
d'exemple, I 'agenda d'une des ressources, à savoir I 'ALESEUSEI5. On peut noter que tous les
tests ont donné la même distribution des tâches sur les ressources. Ce qui nous permet
d'affirmer qu'Optigam génère des résultats stables, fiables et prévisibles dès qu'un certain
nombre de configurations ont été traitées.
l ,égent le : F]chel le des temps :
l l occupé. lL ,b r . lEnP* . E= l ruu te
Val ider I Remettre à :èro I au r :e, I
FRÀrsErrsEll E!!!trouns Iæl
EERcEUsE6 l-lIE!!læPERcBrrsxT IE=!-IE:=-FRÀrsEUsE -æIæFÏÀTSEUSB12
- - I - - - - -- - - - - - - -cur6 Il!:!:-I=:l
FsSE-uSErt l:!r(Al!.riusri.r.J IE-
rorlRr læI:lIÊ==!=: I :- - -- - -
curT IE=!=IÊ===!- - - -- - - -
R&CIINEUSE:'
sERcBnsEr IE!!-I:
îigure IV-3 : Chronogramme d'utilisation des ressources.
La Figure [V-5 montre la gamme technique du PRODUITI3 ainsi que les ratios de temps
de travail, manutention et attente. On peut noter que I'enchaînement des tâches se retrouve sur
le chronogramme (cf. Figure IV-6),
Une analyse plus poussée de ce chronogramme et des suivants (cf. Figure [V-3, Figure [V-
Chapitre fV : Exemple académique.
6 et Figure fV-7) nous perrnet de remarquer que la plupart des temps d'attentes de chaque
ressource sont dus aux contraintes de production : nécessité d'attendre la fin d'une phase pour
passer à la suivante et priorité du produit. Seules les attentes initiales, au tout début de la
production, sont dues aux temps de calculs (au maximum 3'sur les CUl6 et CUlT). On peut
noter qu'ils sont susceptibles de disparaître à partir du moment ou une planification
prévisionnelle sera mise en place en amont du système. En effet, une telle planification devra
fournir des dates réelles de début de production qui ne seront que rarement égales aux dates
d'apparition de la gamme dans les objectifs de production. Ainsi donc, le système aura le
temps de traiter les gammes avant leurs dates de début de fabrication.
h'oiluit Ntunero phase Ternps dÉpart I)ru ee
PRODIIITIO
PRODIIITJ
snanrnf13PRODIIIT6
PROôINTb
5i1"00
58JÛO
igloo60500
eiooô
1
_1
JI
;_1
8'10
1000
l I00
50û
s00
PRODIIIT2 6ts00 :00 l,.rÂtG&ffi *i.::!;',i1::i;lU,J
Figure IV-4 ; Agenda de I'ALESEUSEI5.
Tr,1e t le re:ssotuce Temps ilepart Druee
FRIISEUSETI
TOI]R.3
56300
57000
j00
r+ooPERCJEUSEJ
.{LESEUSEI5
58400
59J00
i lû00
: l l00
; 90060500
o'bTernps Utrlisatron i rlont o'ôTravail 0"ol\Ianutenhon
50.98 ** {9 0l
; o'bTemps Jttende
.0
Figure IV-5 : Gamme technique du PRODUIT 13.
| ) L
Chapitre fV : Exemple académique.
Note:Les Figure IV-3 à Figure IV-16 sont obtenues grâce à des pages HTML dédiées à
SYROCO. En effet, tous les résultats générés par I'application sont traités par des utilitaires
écrits en "perl" (Practical Extraction and Report Language écrit par Larry Wall) afin de
pouvoir les obtenir rapidement et de manière conviviale. L'autre utilité de ce traitement est
qu'il est possible de consulter les résultats et de piloter I'application, en temps-réel et à
distance à I'aide d'un simple navigateur tel que Netscape@ ou lnternet Explorer@3.
vàt ider I Remertre a zéro I , f u, t rer I
ix.rrsiusrrr f-]rorrR! Ir--------]
FERôiùsEC fE!æI ElmRcEullE7
FRÀrsEUsEe -æ-æl!'RÀrsËusBl2
-:r:-: : := I : I :
r.xe,sr.usr:ru rti!.ruarsELsE^r I-i
rorm.l l@llællætroriR? tælIæl
- - -
I : I :
Figure IV-6 : Chronogramme du Produitl3 : pas d'attente.
Légcnde :
! o..up.. I L,br. I En Pr*.
Echel le des temps :
El= 1 minute
lFRoournî-f
[ : Selecuonné
t Adresse Internet pour la consultation des résultats : htlp:l/194.57. 140. 162lsyroco/welcome.html.
1 3 3
Chapitre [V : Exemple académique.
E o..rpé. lLibr, I Eo pu*.
rnersrusæu Elllt
Echel le des temps :
El= I mnwe
lFFo-orJrr-!
[: Selecnonné
Valider I Femeilrs à zéro I eu,tter I
IOIIR:} Iæ
FERCEUSE TE!E!IE!l!l:=!!ll|rrERcEUsET Ml!ll!!IElEllllltFr.lrsEUsE I@IEIErlÂrsEusE12ar.rssusÏii
cur6 [email protected]:rtru f æ
rnarsrusrrr IæTOI'RI IæIæT:IErorrrur IEEEtf EIIEIE
- E - - I- - -cuIT rE-tl:==
FnârsrusErn4 IE!E!=E!æ@RECTIIÏEUSIs
EERCEUSET -æIE!E
Fiettre IV-7 : Chronoqramme du Produitl2 : attente due à I'utilisation de la ressource 5.
1V.3. Résultats produits.
Avant de nous attacher à la réactivité du système face aux aléas de production, il nous a
paru opportun de faire figurer ici quelques résultats significatifs et de les commenter. Le
premier de ces résultats concerne le taux d'occupation des produits c'est-à-dire le pourcentage
du temps durant lequel le produit n'est pas en attente. Ce taux est de 79,5Vo en moyenne. En
d'autres lerrnes, sur I'étendue de notre production, les produits sont inactifs durant 20,5Vo du
temps. Sachant que notre atelier est loin d'être chargé au maximum de sa capacité et qu'il n'y a
pas de nouvelles gammes injectés en perrnanence, ces taux d'occupation sont plutôt
prometteurs. ils dénotent d'un faible temps d'inactivité et, donc, d'une optimisation assez
poussée de I'ordonnancement prévisionnel.
Les autres résultats (cf. Figure [V-8) concernent surtout les temps de calculs et de
transmission. Ainsi, en ce qui concerne le temps d'initialisation du système (c'est-à-dire
I'ordonnancement total et la création des couples Cellule/Produit) on peut voir qu'il est, en
t J +
Chapitre fV : Exemple académique.
moyenne, de 4 mn t 30 s. les indications de temps minimum et maximum permettent de
mieux situer l'étendue de la valeur. Notons que ce temps est à considérer dans les conditions
de f 'expérience et avec les treize produits traités. Il est certain que ce temps est entièrement
fonction du nombre de produits à I'initialisation et des ordinateurs présents dans le système.
Quoiqu'il en soit, on peut avoir une bonne estimation du temps d'initialisation en regardant les
temps de création. En effet, I'addition de ces temps de création (c'est-à-dire I'ordonnancement
de tel ou tel produit) constitue la plus grande part du temps d'initialisation. Le reste (27"75 ou
ll,87o) étant utilisé par les transmissions.
Le temps moyen de la création d'un produit est donc de 15"91 t 5"81. Nous pouvons noter
qu'il s'agit de temps très faibles, surtout en regard des temps de phases (minimum 2 mn),
limites basses accordées au système.
I M.t="g" I Moy"no" lrc"tt T:æ" I Minimum
00:03:I7:90
Figure IV-S : Temps de calculs.
Enfin, le temps noté "fin phase" dans la Figure [V-8 correspond au temps moyen de prise
en compte d'une iin de phase, depuis le moment où la ressource I'a signalée jusqu'à ce que le
Scheduler I'ait traitée. Nous pouvons déjà remarquer qu'il s'agit, là encore, d'un temps très
court (18"74 + 5"16). Cependant, il nous a paru intéressant de préciser ce temps en
différenciant la transmission du traitement (cf. Figure IV-9).
FF;F
Maximum
00:00:01: 14 00:00:27: 14
t J f
Chapitre [V : Exemple académique.
l n, TemFr ùItryenne Ecart T1rye ; Minimum , Mrximum i
i remonté flrnphase 00:00:18:5Û i 00:00:05:16 I 00:00:06:2900:00:26:36
calcul fin phare.
-. -:*1-tPi)Ë:'rÈ?ji- :'t : i1::::-.::t,:i
00:00:00:18 i 00:00:00:0500:00:00:94
Figure IV-9 : Analyse du temps de "fin de phase".
On s'aperçoit alors que, à la différence de la création, cette fois, c'est le temps de
transmission (18"5 r 5"16) qui est le plus important (sans pour autant devenir cri t ique), alors
que le remps de traitement est quasiment négligeable (1" dans le pire des cas). Le rapport
entre ces deux temps parle de lui-même :9816To du temps pour la transmission.
Cette analyse des résultats montre donc que les temps de calculs et de transmissions sont
faibles et parfaitement acceptables par rapport aux temps d'une production. Ces premiers
résultats, preuves d'une bonne réactivité -générale, augurent d'une bonne réactivité en ca.s de
problèmes. C'est ce que nous nous proposons de vérif ier dans la section suivante.
1V.4. Réactivité.
|V.4.1. Réactivité aux aléas d'atelier.
Afin de tester la réactivité aux aléas d'atelier (c'est-à-dire aux pannes de ressources ou aux
ruptures de stock), i l nous a fal lu trouver un pall iat i f au fait que nous n'avions pas de part ie
opérative réelle. De toute façon, même si nous avions eu à notre disposit ion de véritables
ressources, nous n aurions pu attendre qu'el les tombent en panne d'el les-mêmes. En effet, af in
d'avoir assez d' informations pour pouvoir en t irer des conclusions signif icatives, i l nous fal lait
un grand nombre de pannes, ce qui n'est pas très conforme à la réalité. Les ressources réelles
n'ayant pas pour but de casser fréquemment.
Ainsi donc, pour atteindre notre objecti f (dans Ie cadre du test), nous avons associé à
chaque agent Ressource une probabilité de panne. Ainsi, chaque fois qu'une Ressource traitait
r 36
Chapitre fV : Exemple académique.
une phase de la production, il y avait l\Vo de "chance" qu'elle génère un message de panne et
se considère dans cet état.
C'est ainsi que nous avons pu observer un nombre suffisant d'occurrences de panne pour en
tirer des résultats analysables et significatifs. Observons deux de ces occurrences, qui
présentèrent I'avantage d'apparaître quasiment au même moment (deux minutes d'intervalle
entre les deux pannes). La Figure IV-10 nous donne le tableau de GANTT de la production
juste avant qu'apparaissent les pannes.
Les pannes affectèrent les ressources TOUR4 et
respectivement, les premières phases des produits 8 et 2.
tableau de GANTT après la re-configuration de I'atelier due
rx.rrsrusrrr EEEErorru -@
mRcrusre a@-@EERcxusET IN--\\-SSS -@FRÀrsEusEe -@I,æt
CUlT tandis qu'el les usinaienr,
La Figure IV- I I nous montre le
aux pannes.
FRÀISEUSE12 4r y l
ÀrEsEUsErs -@-@@@N.tlSS f---- -]
Cr,re -æIEglFRÂrsBûsEro aærnnrsEusErs Iæ
roriRr IE!æIæII@lrouRz l:Iæl- - -
- - -crnT lllïïTilrr:fl@
FRArsEusEHl4 l@RECTIIIEUSE:I t - - - - ! -
- - - - E
mncrusrs IflirTlllE@l
iiil-ITilll pRoDUIr2 7V7/Z pRoDurrs
Figure IV- l0 : Configuration avant les pannes.
t37
Chapitre [V : Exemple académique.
niArÈEûsErl ilËËËf
rrncsllsE6PERCSûSfi
ALEsEusEurr'=Ë=-I-æ:-l4v7v7/7v1fr ffi -tt';,T]r
t'RÂrsEusËrs rEFRArsEUstsrs -:
ronnr* a-F7777V)
ior.'nl fl--læcurz ff--Iæ
rri.ussustlira læl==-l
cur6 lElæËl|l'r-.-fl
RICTIFIEUSEs
rrncsûsEi
FRArsBnsEe -:I:rRArsBùiBrt- æ
- - - - -- - - - -Irrrrt rFTi:f-:-:]E l l l L I
llfl. PRoDUIT2 71772. PRoDUITg l--_-l p*n.
FigLtre IV-11 : Configuration après les pannes.
Le Tableau IV-6 nous montre les modifications intervenues dans les -eammes de ces
produits, les cel lules grisées marquent les phases modif iées.
En analysant ces résultats, nous pouvons remarquer plusieurs choses :
o Les ressources en panne ont été remplacées par des ressources équivalentes. Bien
sûr, cela n'aurait pas été possible si les ressources concernées avaient été des
goulots d'étranglement.
PRODUIT2avant Danne
PRODUIT2après panne
PRODUITSavant Danne
PRODUITSaprès panne
CU 17 CU16 TOUR4 TOUR I
PERCEUSES PERCEUSES PERCEUSET PERCEUSE6
ALESEUSEI5 ALESEUSEI5 ALESEUSEI5 ALESEUSEI5
Tableau IV-6 : Modifications des gammes.
o Le PRODUITZ aété placé en fin de file sur Ie CUl6, car il n'y avait pas de trou
dans la file d'attente assez grand. En raison du retard que ce placement induit au
niyeau de la fin de la première phase du produit, la phase numéro 2, effectuée sur
r38
Chapitre fV : Exemple académique.
la PERCEUSE8, a été déplacée dans la file d'attente de la ressource. Elle esr
passée de la première position à la dernière place.
o Le PRODUITS, par contre, a pu être placé dans un trou de la file d'attente
TouRl. Il n'empêche que le retard accumulé a provoqué un changement
ressource pour la phase 2.
A première vue, il semble que les phases 3 des deux produits n'ont pas été
modifiées. En fait, elles furent supprimées lors de la panne et recalculées,
comme toutes les phases en aval à partir de la panne. Ceci nous permet de
remarquer qu'Optigam reste cohérent avec lui-même et replace au même endroit
les phases qui n'ont pas à être déplacées.
o Enfin, nous pouvons noter que, en dépit de deux pannes consécutives. la
production n a pas pris de retard. Le ré-agencement de I 'atel ier s'est déroulé cle
manière à combler les trous orésents.
De toutes ces remarques. nous pouvons dire que la re-configuration de I 'atel ier parait f iabte
et ne donne pas de résultats incohérents, bien au contraire. De plus, i l apparaît que la re-
configuration de I 'atel ier ne s'applique que et uniquement à ce qui est nécessaire : les autres
productions de I'atelier n'ont pas été touchées. Restait à nous assurer que cela ne prenne pas
trop de temps et reste assez rapide pour assurer une bonne réactivité du système.
La Figure IV-12. nous donne le temps global de traitement d'une panne. On peut noter que
la moyenne est de 32"02 ce qui est un temps parfaitement acceptable. Cependant, la valeur
maximale est de 51"08 et le résultat de [a moyenne moins l 'écart type (18"54) est inférieur à
la valeur minimum (22"13). Cela signifie que la distribution des valeurs est décalée vers le
maximum. Quoi qu' i l en soit, la valeur maximale de traitement d'une panne est inférieure à la
minute, I'application reste donc temps réel.
du
de
t J v
Chapitre [V : Exemple académique.
Figure IV-12 : Temps gLobal de traitement des pannes.
Une analyse plus poussée de ces temps (cf. Figure W-13) nous permet de dire qu'en
moyenne, le temps de calcul est plus important que le temps de remontée d'info. Dans ce cas,
c'est totalement normal. En effet, le temps de calcul recouvre un certain nombre d'opérations :
o Nettoyage de I'agenda afin de supprimer les phases en aval de(s) la production(s)
concernee(s ).
Interrogation, si nécessaire, des Cellules indirectemênt concernées. C'est-à-dire
des Cellules dont une phase sera perturbée par la panne, mais qui n'étaient pas en
train d'ut i l iser la ressource défectueuse.
Sauvegarde des f ichiers de données, afin de pouvoir relancer la production en cas
d'erreur.
Tempr Moyerure i E.art Type ; Minimum Maximum
; remontÉ panne, 00:00: l ! : I0
I ca lcu l pâme 00:00 '19:9? : 69.66;0T;08 : 00,00: lJ ; l l 00 00 '19:9{
Figure IV-13 : Analv-se des temps de panne.
Modification du temps d'usinage de la phase durant laquelle la panne est
apparue, afin de prendre en compte les pièces déjà réalisées.
Calcul du (des) nouveau(x) chemin(s) de gamme.
Relance de la production.
t40
Chapitre fV : Exemple académique.
En conclusion, nous pouvons dire que SYROCO se comporte bien comme une application
réactive en ce qui concerne le traitement des pannes. De plus, il apparaît que notre outil,
Optigam, bien que basique, donne des résultats fiables et non triviaux.
lV.4.2. Réactivité aux aléas de production.
Afin de tester la réactivité aux aléas de production, c'est-à-dire, par exemple, à I'arrivée
d'un nouveau produit dans la production, nous avons rajouté un quatorzième produit dont la
gamme est donnée par le Tableau [V-7.
Ressource Temps d'usinageFRAISEUSE 300TOUR 300FRAISEUSE 200RECTtrIEUSE 200
TabLeau IV-7 : Gamme Générique du PRODUITl4.
Puis, nous I'avons introduit dans la production à des instants différents. La Figure tV- l-l
montre le diagramme de GANTT de I'atelier avant I'une de ces introductions et la Figure [V-
15 après.
rxArsEùsErr, IæF-ErGtrra6- -- :
PERCEUSE? -@IIEG8
FRÀriEuaE --i'alEEË
FRAISEIISBxl
AIESEUSEIS
mre
I : :'rArsËuu1ru r@ËE
T@I@æTOURI
toÛmculT
rRAriErrsEItr4nrô"rmrBuirs-FERc:EuaÈi--
. - - - -- - - -
-æEI@E
Figure IV- l4 : Chronogramme de la production avant injection d'un nouveau produit.
t 4 l
Chapitre [V : Exemple académique.
FTAISIEI'SBII
FERCETTSd ËWEENCCEI'E
IRÀIS8UltE
rmiixusxuarrirrsErs- --ôffi-
I]ilAISEUSEIg
siirôuRi
r l lEEI:===:
rI-I -
f-I
- @
f lË - -- = E E - E- - - I - -
Figure IV- I5 : Chronogramme de la production après injection du PRODTJIT t4.
Comme à I 'accoutumée, i l apparaît que le système a placé ce produit au mieux. en uti l isant
les trous dans les f i les d'attentes. Ceci est part icul ièrement visible au niveau du TOUR l. En
effet, sur cette ressource, la nouvelle phase a été placée entre deux phases existantes. Le
PRODUIT14 aété introduit avec une priori té très faible, le système n'a donc pas été amené à
remanier d'autres productions. Pourtant, nous pouvons remarquer que le temps total de
fabrication de ce produit est au plus court et n'augmente le temps de fabrication total que d'une
seule minute.
Comme nous I'avons fait précédemment, après nous être assurés que les résultats sont bons
et fiables, il nous fallait vérifier que le temps de calcul nécessaire ne dépassait pas les limites
fixées.
LaFigure ry-16 nous donne une analyse de ces temps de calcul. Nous pouvons remarquer
que la moyenne n'est que de 35"06 et que le temps maximum est de 32"07. Ces temps,
inférieurs à la minute, nous permettent donc d'affirrner que SYROCO se comporte bien
comme une application temps réel, y compris au niveau des aléas de production.
t A 1
Chapitre [V : Exemple académique.
|M"r.re" t-M"l'.*r" i Ecart Î;çe I l!fi"i*"* Maximum
ts*ttt " loooortsre I00:00:01:96 i00:00:32:07 00:00:3?:08
Figure IV-16 : Analyse des temps de calculs pour une nouvelle gamme.
1V.5. Robustesse du système informatique.
Il ressort donc de nos différents tests que SYROCO présente une bonne réactivité et qu'il
traite les informations en temps réel. De plus, nous pouvons noter que les résultats fournis par
I'application sont fiables, stables et non triviaux. Reste à nous assurer que l'application
présente une bonne résistance aux erreurs. Dans cette partie, nous nous attacherons plus
particulièrement à définir la robustesse du système informatique vis-à-vis de problèmes
pouvant être causés par les ressources informatiques. C'est-à-dire les problèmes concernant le
réseau, les ordinateurs ou les messages échangés.
Au cours de nos tests, il nous est arrivé de rencontrer des erreurs et d'observer un
dysfonctionnement du système. Après recherche des causes de ces erreurs, il nous est apparu
qu'i l en existait trois.
La première cause d'erreurs est due aux sockets elles-mêmes. En effet, le type de sockets
que nous utilisons, à savoir les sockets "stream", assurent une anivée à bon port des messages,
mais pas la persistance des fins de chaîne. Il peut arriver que deux messages envoyés à [a suite
soient concaténés et lus, par le récepteur, comme n'étant qu'un seul. Bien évidemment, cela
perturbe le déroulement de I'application qui attend indéfiniment la suite du message. C'est un
cas de figure assez fréquent, puisque tous nos messages sont composés d'un identificateur
suivi de l'information utile. C'est un problème facilement soluble en émettant nos messages en
seule fois et en effectuant la séparation à I'anivée et non plus au départ.
Le deuxième problème rencontré, qui influe dans certains cas sur la fréquence du premier,
t + J
Chapitre fV : Exemple académique.
tient à la charge des ordinateurs. Il apparût, en effet, que si un ordinateur est trop chargé,
I'asynchronisme du système augmente et les messages mettent de plus en plus de temps à être
émis ou reçus. Sans provoquer véritablement une eneur, cet état de fait ralentit le système et
augmente Ie risque de concaténation des messages. Une augmentation des ordinateurs présents
dans I'application permet de contourner le problème. En effet, pour des raisons matérielles,
nous avons effectué nos tests sur seulement trois machines pour l3 Cellules, l3 produits et l7
Ressources, soit une cinquantaine de modules avec le Superviseur, le Méta-Obiet et les outils.
Il semble que pour pouvoir continuer à utiliser les machines normalement, il ne faille pas
dépasser une dizaine d'applications par ordinateur.
La troisième cause d'erreurs est totalement indépendante du système et de notre champ
d'action. En effet, il s agit des erreurs causées par le système physique de réseaux etlou les
systèmes de gestion d'UND( ou Windows 95. Contre cela nous ne pouvons rien, si ce n'est
Lrt i l iser un système d'alarme interne à SYROCO, nous permettant, au moins, de détecter la
panne et de se préparer à la reprise de la conduite dès que cela sera possible.
En conclusion, il apparaît que SYROCO est un système qui peut être qualifié de robuste.
Les erreurs rencontrées ne sont pas véritablement critiques etlou facilement évitables. En fait,
la robustesse du système est sensiblement égale à celle du réseau sur lequel elle s'appuie.
1V.6. Conclusion.
Les tests que nous avons réalisés avec cette application, sur un exemple académique mais
présentant de nombreux points critiques (goulots, pannes aléatoires, contraintes de réactivité
fortes) nous ont permis de vérifier que ce modèle semble parfaitement capable de gérer une
production manufacturière soumise à perturbation êt, a priori, inconnue. En effet,
I'ordonnancement s'est révélé fiable et parfaitement stable, la conduite se déroule sans
problème majeur et, surtout, la réactivité est efficace. Le traitement des informations
t44
Chapitre fV : Exemple académique.
courantes se fait dans des temps inférieurs à la minute et le traitement des aléas prend aux
alentours de deux minutes. En considérant ces temps par rapport aux temps d'une production
manufacturière, il apparaît que SYROCO devrait perïnettre de piloter une production en
temps réel. Le Tableau IV-8 récapitule les différents temps de réaction du système. Nous
pouvons vérifier qu'ils sont inférieurs à la minute (initialisation exceptée). En comparanr ces
temps avec les temps de phase (deux minutes au minimum dans notre exemple, beaucoup plus
dans une véritable production), nous pouvons affirmer que SYROCO peut être qualifiée
d'application réactive, temps-réel.
Evénement Temps Movenlnitialisation 3'54"59Création 0 ' 15"91Fin Phase 0 '18 "74Panne 0'32"02Nouvelle Gamme 0'35"06
Tableau IV-8 : Récapitulatif des temps de réaction.
Bien sûr, I 'exemple traité reste académique, mais en raison des contraintes que nous avons
imposées, i l est plus que probable que I 'on obtienne des résultats du même ordre sur une
oroduction réelle.
t45
CONCLUSION
146
Conclusion.
Conclusion.
Nous avons proposé dans ce mémoire un système hybride de pilotage réactif d'atelier basé
sur une plate-forme multi-agents. L'originalité de ce système tient donc au fait qu'il est basé
sur une architecture hybride, située entre les architectures hiérarchique et centralisée. D'autre
part, nous avons décidé d'utiliser un ordonnancement prévisionnel total mais pouvant être
remis en cause.
Une étude bibliographique nous a permis d'évaluer l'existant, de nous situer par rapport à
ce qui avait déjà été fait dans le domaine du pilotage réactif d'atelier via une plate-forme
multi-agents. La présentation théorique du système et sa spécification par les Statecharts, nous
a permis de présenter en détail les agents de SYROCO et de définir les interactions existantes
entre eux.
Nous avons, par la suite, vérif ié la théorie grâce à l ' implémentation du système et à son
application à un exemple académique mais non tr ivial. Ainsi, nous avons pu vérif ier que le
système, non seulement pouvait être réalisé, mais en plus qu' i l donnait des résultats
compatibles aux contraintes d'une production en temps-réel.
De tout cela, nous pouvons dire que :
o Une structure hiérarchisée quant à la conduite et centralisée quant à la commande
est viable et qu'il n'est pas nécessaire de recourir à la distribution et à la coopération
entre agents pour piloter un atelier.
. Il est possible de pratiquer un ordonnancement total de la production a priori. A
condition que I'on puisse pratiquer des ordonnancements partiels en cours de
production. Bien sûr, ces ordonnancements doivent remplacer en panie les résultats
de I'ordonnancement total prévisionnel.
o L'utilisation d'agents réactifs permet un développement relativement simple et une
plus grande flexibilité et réactivité de I'ensemble.
t47
Conclusion.
o Travailler en réseau local et partager les modules de I'application entre plusieurs
ordinateurs permet de faire fonctionner une application lourde sans pour autant
réserver les machines du réseau à cette seule fin.
o La communication entre modules de I'application est le point le plus délicat à régler,
mais une bonne formalisation des messages et I'emploi des techniques appropriées
(sockets, exécution paramètrée, mémoire partagée), aux bons moments, donnent de
bons résultats.
Cependant, i l est évident que le système, dans son état actuel, ne peut être appliqué
directement en entreprise : nous n'avons réalisé qu'une maquette de démonstration, juste
suffisante pour étayer et vérifier notre approche. La première des modifications à apporter à
SYROCO serait de remplacer les outils externes par des modules plus performants.
Ainsi, Optigam, qui donne tout de même de très bons résultats, devrait pouvoir gérer les
outi ls et les gammes de remplacement. En effet, à l 'heure actuelle, le système considère que
chaque ressource dispose automatiquement des outi ls dont el le aura besoin pour son usinage.
C'est, bien entendu, un précepte faux. I l faudrait donc alouter à Optigam la gestion des outi ls
et ne plus se contenter du trinôme Quoi"Où*Quand mais ajouter le paramètre "Outil" à
l 'équation lors des ordonnancements. De plus, I 'ut i l isation des gammes de remplacement
diminuerait considérablement les temps de fabrication globaux.
De même, le générateur d'agent pourrait être encore plus générique et être capable de
fournir un code source pour n'importe quel type d'agent, quelle que soit la fabrication traitée.
En effet, pour I'instant, le générateur ne fournit que le code d'agents Produits spécifiques à la
gestion d'un atelier manufacturier. Or, SYROCO devrait être en mesure de piloter tout type de
fabrication par lot (petites et moyennes séries), à condit ion que le générateur puisse fournir
des agents différents en fonction de la demande.
t48
Conclusion.
La gestion des données, enfin, pourrait être grandement améli orée gràce à I'utilisation d,une
base de données orientée objets (BDOO). Pour I'instant, les données utiles à I'application sont
gardées dans des fichiers binaires, une communication directe, sous forme de requêtes OeL
(Object Query Language), avec une BDOO augmenterait la flexibilité de SYROCO.
Les autres améliorations qui pounaient être apportées au système sont d'ordre
informatique. En effet, à I'usage, il nous est apparu qu'il n'est pas très bon de séparer les
messages véhiculés par les sockets. Or, nous étions partis sur le principe qu'une
communication devait s'établir par l 'émission d'un identif icateur, suivit du message
proprement dit ("panne" ; "produit, temps, ressource, date, durée, commentarre").
Malheureusement, les sockets, si el les assurent l 'arr ivée à bon port des messages, ne
garantissent pas le respect des fins de chaînes. Il arrive donc que les messages se concatènent
de façon anarchique. La solution, simple a posteriori , consiste à envoyer les deux part ies dlr
message en même temps et à faire la séparation à I 'arr ivée et non plus à l 'émission.
Enfin, i l apparaît que ie langage C, uti l isé pour la programmation de SYROCO, n'esr pas le
langage le plus adapté à ce genre d'application. n existe maintenant des langages
informatiques qui prennent en compte, de manière automatique ou presque, les problèmes de
communication. De plus, ces nouveaux langages sont part icul ièrement portables, et pour
certains, ne demandent même pas Llne re-compilat ion du code source en fonction de t 'OS. Ces
langages, Java, Perl et TCLÆK, n'existaient pas, ou n étaient que peu répandus, lorsque nous
avons commencé le développement. Aujourd'hui, nous penserions I 'application différemment
et en ferions une application purement Intranet, dont les données seraient accessibles et
modifiables directement via un navigateur web tel que Netscape, MS Explorer ou Mosaic, par
exemple. SYROCO deviendrait, ainsi. une application Web à part entière. L'avantage d'une
tel le modif ication serait qu' i l deviendrait possible aux responsables de I 'atel ier d' intervenir et
de surveiller la fabrication à distance et de manière plus ergonomique qu'actuellement.
149
Conclusion.
Enfin, il est bon de garder à I'esprit que tous les temps de réaction observés sont fortement
influencés par I'occupation du réseau. En effet, plus celui-ci est chargé, plus les informations
mettront de temps à remonter. Ainsi, une grande amélioration des perforrnances pourrait être
obtenue en utilisant un réseau dédié uniquement à cette application.
r50
ANNEXE 1
Exemples de svstèmes multi-aqents.
Annexe I : Exemple de systèmes multi-agents.
ANNEXE 1 : Exemples de systèmes multi-agents.
1 Le système ATOME.
ATOME [36] t40l [53] est un système multi-experts développé par une équipe du CRIN-
INRIA dirigé par le professeur Jean-Paul Haton à Nancy, C'est un système composé d'une
architecture à tableau noir et d'un contrôle hybride, c'esr-à-dire qu'il intègre à la fois un
contrôle hiérarchique et un contrôle à base de tableau noir. ATOME possède trois types de
connaissances: les spécialistes (Sources de connaissance C du domaine), les tâches
(renfermant une partie des connaissances liées au contrôle), et la statégie (chargée du
contrôle global du raisonnement).
Un spécialiste est une entité disposant de connaissances spécialisées et capable de résor-rdre
un prcrblème ; el le est définie par son nom et ses variables locales. Une tâche coordonne les
activités d'un ensemble de spécial istes grâce à une l iste d'événements oùr sonr stockés les
changements des Tableaux Noirs susceptibles de I ' intéresser ; el le est définie par son nom. son
fi l tre d'événements, ses variables locales, sa base de connaissances. son mode de
raisonnement et son mode de fonctionnement. Une stratésje coordonne les activités des tâches
en fonction des problèmes à résoudre et de la quali té de la solution courante ; el le est définie
par son nom, ses variables locales, sa base de connaissances et son mode de fonctionnement.
ATOME comprend plusieurs tableaux noirs tels que le tableau noir à long terme,
comprenant des hypothèses n'ayant pas servies depuis longtemps, et le tableau noir explicatif,
servant à rendre compte des raisonnements.
ATOME a déjà été uti l isé pour plusieurs applications, tel les que la compréhensron de
l 'écriture (1989), I 'aide à la décision pour la maintenance de voir ie urbaine (1990), la
planif ication de tâches (1990), I 'aide au commandement avec contraintes en temps réel (1990)
ou la télécommunication spatiale (1990).
Annexe I : Exemple de systèmes multi-agents.
Afin de palier au problème du temps réel, on fait évoluer ATOME vers ATOME-TR en
dotant d'un intégrateur. I s'agit d'un module chargé de s'occuper des interactions avec
monde extérieur.
2 HOPES (Hierarchically Organized Parallel Expert System).
HOPES [5a] a une structure adaptée à la résolution de problème par niveau (cf. Figure A l-
l). Les agents ont accès aux informations par I'intermédiaire d'un tableau noir partagé par les
agents à plusieurs niveaux. Dans I 'exemple de la Figure Al-1, on peut voir que I 'agent Ax est
responsable de la central isation des résultats de la coopération entre les agents Axl,. . . ,Axn
dans le tableau noir B. B est donc uti l isé par Ax mais aussi par Axl,. . .Axn qui communiquent
par son intermédiaire. Ax peut lui aussi col laborer avec d'autres agents du même niveau par
l ' intermédiaire d'un tableau noir de plus haut niveau. On peut, bien sûr, avoir autanr de
niveaux qu 'on Ie dés i re.
aT;5leâu-noillH de p l us
i hau t n i veau
iÀut les la gen t s
Tab leau no i rD
le
le
t t l
Ax1 | Ax2 i lAx i iAxn i
Figure AI-l : Modèle hiérarchique de HOPES.
Annexe I : Exemple de systèmes multi-agents.
3 HECODES (Heterogeneous Cooperating Distributed Expert System).
HECODES [54] est un système basé sur une coopération horizontale, hiérarchique et
récursive (cf. Figure Al-2). Il se compose d'un système de contrôle centralisé, d'un système à
tableau noir et de systèmes experts. Il permet une coopération d'agents hétérogènes par
rapport à leur stratégie de contrôle, leur méthode de représentation des connaissances et leur
langage de programmation.
Figure AI-2 : Architecture de HECODES.
Dans ce modèle d'architecture, le sous-système de tableau noir centralise les informations
partagées par les systèmes experts. Le sous-système de contrôle gère la coopération et la
communication entre les noeuds ainsi que le temps d'exécution de HECODES. Les interfaces
servent d'interface de communication, d'interface homme/machine et de gestion de systèmes
eKperts hétérogènes.
4 ARCHON (ARchitecture for Cooperating Heterogeneous ON-line sysfems/.
ARCHON aété développé par Roda, Jennings et Mamdani [40] [53]. n s'agit d'un système
uti l isé dans le contrôle de processus industriels (cf. Figure Al-3). I l permet de regrouper des
systèmes experts différents, initialement non-coopérants, en vue d'une coopération. C'est
S o u s - s y s t è m e d e i a b l e a u n o i r
S o u s - s v s t è m e d e c o n t r ô l e
I n t e r f a c e I n t e r f a c e
S v s t è m e e x p e r t
Annexe I : Exemple de systèmes multi-agents.
donc un système hétérogène possédant des éléments ayant des niveaux d'intelligence
variables.
L'architecture générale du système est représentée par la Figure Al-3. La "tête" d'un agent
comprend un gestionnaire de communications de haut niveau, un modèle des compétences des
autres et de soi et un système de planification et de coordination. Un moniteur fait I'interface
et la gestion entre la "tête" et le corps d'un agent composé d'un ensemble de tâches, chacune
correspondant à un module logiciel préexistant.
Le module de communication introduit plusieurs concepts :
. L'adressage intelligent : un agent peut envoyer un message à un groupe d'agents
intéressés par le message.
Le filtrage : un agent peut ne recevoir que des messages traitant d'un sujeta
a L'ordonnancement: permet de recevoir les messages dans un ordre précis.
t
1I
I
iL It l-
!
i
A g e n l
tR é s e a u d e c o m m u n i c a
III
r l
-r l
C e s t i o n n a i r ed ' acco in tancesm o d è l e d e s o i e t
d e s a u t r e s )
A g e n t
I I ITâches co r respondan t à
des modu les l og i c i e l sp réex ls tan ts
Figure Al-3 : Architecture générale du système ARCHON.
Annexe I : Exemple de systèmes multi-agents.
5 Modèle de Kouiss
Le modèle de Kouiss [50] est dédié au pilotage d'atelier et se base sur une architecture
distr ibuée supervisée dans un cadre sans ordonnancement prévisionnel. Le modèle uti l ise des
agents tels que les a définis Ferber [31] et le niveau de supervision est dédié aux règles
d'allocation utilisées par chaque agent. Dans chaque agent, on trouve trois sous-systèmes :
. un sous-système de connaissances,
o un sous-svstème d'exoert ise
o et un sous svstème de communication.
Le déroulement des tâches de la file d'attente de chaque agent se fait grâce aux règles de
décision. Cette opération se fait en deux étapes :
o analyse des symptômes,
. application d'r.rne règle de décision.
Cet a-sencement permet d'obtenir des décisions locales et en temps réel. Le superr, ' iseur a en
charge d'assurer le respect des objecti fs globaux. I l peut donc, dans ce but, imposer à un
ensemble d'agents I 'ut i l isation d'une règle part icul ière.
ANNEXE 2
Les îlots virtuels.
Annexe 2 : Les îlots virtuels.
ANNEXE 2 : Les îlots virtuels.
Le concept de technologie de groupe (TG) sous-entend une décomposition de I'entreprise
en sous-ensembles de tai l le plus faci lement gérable. Ainsi, I 'entreprise est divisée en usines
qui contiennent des ateliers, lesquels sont composés de cellules (cf. Figure A2-l),
Figure A2'l : Décomposition TG.
Cette décomposit ion introduit, defacto,le concept d'î lots ou cellules de fabrication. Un î lot
de fabrication est la plus petite unité de décomposit ion, ressources exceptées. En fait, i l s 'agit
Atelier A
Cellule A
Atelier B
llule B
Annexe 2 : Les îlots virtuels.
d'ensembles de ressources réunies par des contraintes :
Géographiques : l'îlot est composé de ressources proches géographiquement.
De production : l'îlot est composé des ressources intervenant dans la production en
cours.
o De similitudes : l'îlot est composé de ressources semblables.
Ces cellules peuvent être virtuelles ou non. Par cela, nous entendons que les cellules
peuvent être dédiées à une opération particulière (cellule de fraisage, cellule de métrologie,
etc.) ou bien n'être créées que et uniquement en fonction de la production à réaliser. Dans ce
cas, les î lots contiennent les ressources uti les à la fabrication du produit considéré, c'est-à-dire
les ressources qui interviennent dans la gamme technique du produit. Ce type de cellule
n'existe que pour le temps durant lequel le lot de pièces dont el le s'occupe soit usiné (cf.
Figure A2-2).
Figure A2-2 : Des îlots virtuels
Les îlots que nous utilisons sont de ce dernier type. Ils sont créés uniquement par rapport
un produit donné et n'existent que le temps nécessaire pour que ce produit soit obtenu.
Annexe 2 : Les îlots virtuels.
La Figure A2-2 montre un atelier quelconque dans lequel deux îlots virtuels ont été
définis : l'îlot I et l'îlot 2. Ces cellules peuvent partager des ressources à partir du moment où
elles ne les utilisent pas simultanément. Comme le montre les contours irréguliers des îlots, il
ne s'agit pas de dispositions physiques mais uniquement de vues de I'esprit : c'est le concept
d'îlots virtuels.
ANNEXE 3
L'outil Optiqam.
Annexe 3 : L'outil Optigam.
ANNEXE 3 : L'outi l: Optigam.
Pour obtenir les résultats escomptés et adapter la théorie aux réalités informatiques, nous
avons décidé d'utiliser une variante d'un algorithme assez vieux mais qui a fait ses preuves. En
effet, le but de ce projet n'étant pas l'ordonnancement et la planification, nul n'était besoin de
réinventer un algorithme performant. Par contre, comme il s'agissait de trouver un outil qui
puisse être adapté au système et qui donne des résultats acceptables, autant choisir quetque
chose qui ait déjà été utilisé et dont on connaisse parfaitement les points forts et les défauts.
L'algorithme que nous avons uti l isé, nommé Optigam, est donc:
It : Rectrercher les ressources l ibres aux temps t correspondants aux durées d'uti l isationI des ressources par le produit.
l2 : Construire la matrice des distances.l3 : Déterminer la température in i t ia le
3 l : t an tquek<10 .n31 I : Prendre au hasard une ressource de la solution et la remplacer Dar un
poste du même type, choisi au hasard lui aussi.312 : calculer le coût Cp correspondant313 : k€k+ l314 : Revenir à la confieuration init iale
32 : Calculer l'écart quadratique moyen:
o (c ) = , = [ ]
( c , ) ' - ( r , ) ' )
Déterminer les paramètres du recuit simulé: nombre d'acceptations (na), de refr,rs (nr),décroissance maximum de la température (D), et température minimum (Ti).Répéter :Si (n > na) ou (m > nr) faire
l t , ** , r = Dr.Trl s i T1ç*11 ) T . in
L
ln€0:m€0:Tç€T, r * ' ,lcharger la meil leure configuration obtenue Fp
l s inon. la l ler en 6
lS inon ,lPrendre au hasard une ressource i de Ia solution et Ia remplacer par un poste j
I du même type, choisi au hasard lui aussi.
lCa lcu le r l e coû t C rk+ r r
ls i C, r - r r (= Cr fa i re
ls i F,p*1r <> Fr fa i re
lF, . ê F,o*, ,In € n+ l
Annexe 3 : L'outil Optigam.
;,,nJi""'"n t
lrétablir i à la place de j
ls inon la l ler en 5
I calculer I'exponentielle de BoltzmanI
I l r r \ \
| ^- .*p(_((c,*. , , _cr)rr_))
Itirer un nombre R au hasard, compris dans I'intervalle [0, l]l s iR<=Afa i re
lF* e F1**,,ln € n+ l
l,,nJ;""' 'n t
lretaUtir i à la place de j
lo , nin a" p.o.eal"iler en 5
Cet algorithme, dit du "recuit simulé", étant basé sur le hasard, la solution obtenue n'est pas
forcément la meilleure possible. Cependant, elle fait partie des meilleures qui soient. Le coût
de la solution est calculé en fonction des distances euclidiennes inter-ressources et du flux de
matière. Ainsi, I'algorithme choisit comme préférable la solution qui regroupe un ensemble de
ressources les moins distantes possibles.
Après détermination de la solution, les données d'occupation des ressources sont
sauvegardées. Ceci afin qu'une prochaine détermination de chemin ne réutilise pas les mêmes
ressources aux mêmes moments.
La différence fondamentale entre cette version du recuit simulé et la version originale est
que nous ne nous attachons pas à déplacer les ressources en fonction des gammes, mais
déplaçons les gammes en fonction de la position des ressources.
En cours de réalisation, cet outil s'est révélé particulièrement flexible. En effet, il lui a été
possible d'absorber des ordonnancements partiels dont la phase de départ est différente de la
première. Cela s'est r€vélé particulièrement utile, surtout lors de re-routage d'une production
en raison d'aléas. En effet, dans ce cas, la production est déjà commencée et certaines de ses
phases sont déjà effectuées et, par conséquent, inutiles. Il est donc inutile de perdre du temps à
Annexe 3 : L'outil Optigam.
recalculer le chemin de gamme dans son intégralité : seules les phases courantes et futures
nous importent.
De même, bien que nous n'ayons pas pris le temps, dans la conception de cette maquette,
de I'implémenter, il serait simple de faire travailler Optigam avec des gammes de
remplacement. Cette innovation induirait une augmentation des temps de calcul dans certains
cas, mais permettrait la réduction des temps de fabrication. De plus, il est parfaitement
possible d'effectuer les calculs en parallèle. D'où une faible perte de temps due aux calculs
supplémentaires.
ANNEXE 4
Le tri rapide.
o
Annexe 4:Le tr i rapide.
ANNEXE 4 : Le tri rapide.
Le tri rapide s'effectue en deux étapes :
. la première étape consiste à découper la liste des éléments à trier en deux sous
listes de tai l les égales. Ces deux sous l istes seront à leur tour découpées de la
même manière. Le processus s'arrête dès que les sous listes ne contiennent plus
qu'un seul élément. On a ainsi obtenu une sorte d'arbre logique, dont les feuil les
représentent les éléments de la l iste init iale (cf. Figure A4-l).
Figure A4- L' Décomposition cle la liste à trier.
La deuxième étape consiste à recomposer la l iste de valeurs init iales
remontant I'arbre des feuilles vers la racine. A chaque noeud de l'arbre,
en
les
Liste in i t ia leI,l+
320
Annexe 4 : Le tri rapide.
valeurs seront groupées par ordre croissant ou décroissant suivant le type de tri
désiré (cf. Figure A4-2).
Figure A4-2 : Recomposition de La liste triée.
Comme son nom l ' indique, ce tr i est part icul ièrement rapide. Bien entendu, i l fait appet à
des notions de récursivité ( les procédures s'appellent el les-mêmes) et demande, par
conséquent, une mise au point fine et rigoureuse. Notons que la récursivité induit un
remplissage de la pile (dans la mémoire de l'ordinateur) qui peut provoquer des erreurs en cas
de listes très longues ou d'ordinateurs'très faiblement pourvus en RAM. Quoiqu'il en soit,
comparée aux tris à bulles, cette méthode donne des résultats sept à huit fois plus rapides.
Résumé
Le monde industriel est en constante évolution en raison des besoins.de liindustrie liés à la compétitivité. Le"tout automatique" n'ayant pas donné les résultats escomptés, une nouvelle approche doit être définie. Il'faut unsystème qui puisse être adapté lorsque: les métliodps de ptodirct{on;" les 'procédures de contrôle deI'ordonnancement etc. changent mais qui reste capdble de gérer la production en "temps-réel".
Certaines méthodologies tentent de répondre à ce pToblème.Cependant, il subsiste quelques défauts tels quela gestion des accidenm ou des aléas de production, la nécessitê;de rêctinfigurer I'installation si I'organisation deI'entreprise change et la concurrence totâlè'entre tous Jes agents intbryenant dans la processus. Le but de cetravail est de'proposèr une autre,appqocliê,'visant en.particulier, à résqudre les problèmes de gestion dynamiqueen temps réel de la production (postes dç tralail en pânne, coiiunandes urggntesi etc.), à automatiser autant quepossible le processus visant'à adapter !g système aux modifications de.lbnueprise et à rationaliser la prise ded é c i } i < i n p a r u n e h i é r a r c h i s a { i o n a c c r u e . . ' . . . ' . , . . ' : - '
Pour cela,'nous:,hous sommes âppgyés sur uRe plate.forme multi-agents doublement hybride. Premièrement,la conduite est hiérarchisée alors que la cpmmandé est centralisée ce qui.rtoqs'positionne entre les architecturescentralisée et hiérarchisée. La centralisation.nous ejpgrmi5 d'éviter la cqncurrence entres agents lorb.du traitementd'un problème et la-.hiérarchfsatidir, a'eontrariô' a permis, à chague agènt de ne s'occuper.que,de..la conduite dlunseul!'produit. Deuxièmemeflt;. nsrt-effêctuons,'uù ofdonnancêrnent prévisionnel total, maisrpouvant, être remispartiellenieni (voire totalèment)'sn cause du coun du piocessùs.'Ai.ngi, noqs ne perdons pas de,temps en cours deproductiotr, même si, dn cas d'aléas; il est nécessaire de refaire un ordonnancement partiel (voire total). Nousavons ainsi gagné en rapidité et en réactivité grâce à la doublè hybfidation du système. , r ,'
Mots.clés:
Pilotage, Temps-réel, Système Multi-agents, Systèmes hiérarchiques, Aide à la décision.
A,bstract : -'
For competitiveness.reasons; thc lndustrial world is in permanent ovolution. The first.stage of this evolution
was massive automation;,but because this solution did not rneet all expectations,ta new approach is required. In:others words,,it is: necossary to have a system which could be adapted when methods of ptodubtion, scheduling
procedures, etc. change butwhich rernain.able to manage the production in 'rcal tiinê". , , ' ,'
Some methods have been proposed to solve this problem. However,, sorne drawbackb subsist such as
accidents or production risk,management;.the necessity to re-configurê the instal.lation if the organization of the
.enterprise changes or total competition between agents. Our goal is to propose an alternate approach; especially,
aiming at solving dynamic .production rnanagement problems in real-time (workstatlon breakdowns, urgent
orders...), to automate as much,as possible the process in order to adapt the system to modifications of the.enterprise and to rationalize the decision-making by a strong hierarchical sEucture.
To achieve this, the system,is based on a twofold hybrid multi-agent platform. First,'the control is hierarchical
and the command is centralized, 'thus the system is positioned between the centralized and hierarchical
architectures. The centralization allows us to avoid the competition between agents to solve a Pfoblem and the
hierarchization allows each agent to lake care of'only one.product. Second, a complete scheduling is realizçd at-the start of the process, but it could be partially (or totally) modified during the ptocoss. Thus, no timç is waisted
during the pfoduction, evèn if, in case of prbblem, it is necessary,to make again a partially (or totally) scheduling.
So, we have gained in rapidity and reactivity thanks to the twofold hybridization.
Keywords:
Shop-Floor Control, Real-Time, Multi-Agent System, Hierarchical Systems, Decision Support.
iI