liens code de la propriété intellectuelle. articles l...

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).


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


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


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


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


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


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


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


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


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


è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 À


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


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


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


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


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


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.


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


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


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


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


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


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


/,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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


;--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


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


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


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


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


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,


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


(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


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


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 :


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


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


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


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


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.


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


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


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


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


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


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.


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.


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


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


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


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


( - 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


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


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


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


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


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


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


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


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


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


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 +


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


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


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


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-


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


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


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 +


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


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


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


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


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


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


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


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


|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


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


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).


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.


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


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.


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


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.


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


;,,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 à


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

liens code de la propriété intellectuelle. articles l...

Documents