Modelisation et simulation des systemes de production :

une approche orientee-objets

Xiaojun Ye

To cite this version:

Xiaojun Ye. Modelisation et simulation des systemes de production : une approche orientee-
objets. Modelisation et simulation. INSA de Lyon, 1994. Francais. <NNT : 1994ISAL0049>.
<tel-00821121>

HAL Id: tel-00821121

https://tel.archives-ouvertes.fr/tel-00821121
Submitted on 7 May 2013

HAL is a multi-disciplinary open access Larchive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
destinee au depot et a la diffusion de documents
scientifiques de niveau recherche, publies ou non,
emanant des etablissements denseignement et de
recherche francais ou etrangers, des laboratoires
publics ou prives.
No d'ordre 94 Anne 1994

THESE

prsente devant

L'INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON

pour obtenir

LE GRADE DE DOCTEUR

SPECIALITE: INGENIERIE INFORMATIQUE

par
Xiaojun YE

(Ingnieur en Mcanique Industrielle)

Modlisation et Simulation des Systmes de Production:

une Approche Oriente--Objets

Soutenue le 29 juin 1994 devant la Commission d'Examen

Jury MM. Grard BEL

JolFAVREL
Gia Toan NGUYEN Rapporteur
Georges JAVEL Rapporteur
Jean-Paul KIEFFER Rapporteur
Albert MATHON
No d'ordre 94 Anne 1994

THE SE

prsente devant

L'INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON

pour obtenir

LE GRADE DE DOCTEUR

SPECIALITE: INGENIERIE INFORMATIQUE

par
Xiaojun YE

(Ingnieur en Mcanique Industrielle)

Modlisation et Simulation des Systmes de Production:

une Approche Oriente-{)bjets

Soutenue le 29 juin 1994 devant la Commission d'Examen

Jury MM. Grard BEL

JolFAVREL
Gia Toan NGUYEN Rapporteur
Georges JAVEL Rapporteur
Jean-Paul KIEFFER Rapporteur
Albert MATHON
NOVEMBRE 1993

INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON

Directeur : J.ROCHAT

Professeurs :
S.AUDISIO PHYSICOCHIMIE INDUSTRIELLE
J.C.BABOUX TRAIT. SIGNAL ULTRASONS
J.BAHUAUD MECANIQUE DES SOLIDES
B.BALLAND PHYSIQUE DE LA MATIERE
G.BAYADA CENTRE DE MATHEMATIQUES
C.BERGER (Melle) PHYSIQUE INDUSTRIELLE
M.BETEMPS AUTOMATIQUE INDUSTRIELLE
C.BOISSON VIBRATIONS ACOUSTIQUES
M.BOIVIN MECANIQUE DES SOLIDES
H.BOTTA GENIE CIVIL ET URBANISME {METHODES)
G.BOULAYE INGENIERIE DES SYSTEMES D'INFORMATION
J.BRAU EQUIPEMENT DE L'HABITAT
M.BRUNET MECANIQUE DES SOLIDES
J.C.BUREAU THERMOCHIMIE MINERALE
J.P.CHANTE COMPOSANTS DE PUISSANCE ET APPLICATIONS
M.CHEVRETON ETUDE DES MATERIAUX
B. CHOCAT METHODES
B.CLAUDEL CHIMIE PHYSIQUE APPLIQUEE ET ENVIRONNEMENT
L.CRONENBERGER CHIMIE BIOLOGIQUE
M.DIOT THERMOCHIMIE MINERALE
A.DOUTHEAU CHIMIE ORGANIQUE
B.DUPERRAY CHIMIE BIOLOGIQUE
H.EMPTOZ MOD.SYST.ET REC.DES FORMES
C.ESNOUF GEMPPM*
L.EYRAUD GENIE ELECTRIQUE ET FERROELECTRICITE
G.FANTOZZI GEMPPM*
J.FAUCHON CONCEPTION ET ANALYSE SYSTEMES MECA.
J.FAVREL INFORMATIQUE DES SYST. DE PROD. INDUS.
Y.FETIVEAU GENIE ELECTRIQUE ET FERROELECTRICITE
L.FLAMAND MECANIQUE DES CONTACTS
P.FLEISCHMANN GEMPPM*
A.FLORY INGENIERIE DES SYSTEMES D'INFORMATION
R.FOUGERES GEMPPM*
L.FRECON DEVELOP. LANGAGES INFORMAT. AVANCES
R.GAUTHIER PHYSIQUE DE LA MATIERE
M. GERY GCU (EQUIPEMENT DE L'HABITAT)
G.GIMENEZ TRAITEMENT DU SIGNAL ET ULTRASONS
P.GOBIN GEMPPM*
P.GONNARD GENIE ELECTRIQUE ET FERROELECTRICITE
R.GOUTTE TRAITEMENT DU SIGNAL ET ULTRASONS
G.GRANGE GENIE ELECTRIQUE
G.GUENIN GEMPPM*
G.GUILLOT PHYSIQUE DE LA MATIERE
A.GUINET INFORMATIQUE DES SYST.DE PROD.INDUS.
C.GUITTARD DEVELOP.LANGAGES INFORMAT.A VANCES
J.L.GUYADER VIBRATIONS-ACOUSTIQUE
J.JOUBERT GENIE MECANIQUE
J.F.JULLIEN BETONS ET STRUCTURES
A.JUTARD AUTOMATIQUE INDUSTRIELLE
R.KASTNER GEOTECHNIQUE
H.KLEIMANN GENIE ELECTRIQUE ET FERROELECTRICITE
J.KOULOUMDJIAN INGENIERIE DES SYSTEMES D'INFORMATION
M.LAGARDE CHIMIE BIOLOGIQUE
M.LALANNE MECANIQUE DES STRUCTURES
A.LALLEMAND ENERGETIQUE ET AUTOMATIQUE
M.LALLEMAND (Mme) ENERGETIQUE ET AUTOMATIQUE
. 1.
(NOVEMBRE 1993)

P.LAREAL GENIE CIYIL ET URBANISME GOTECHNIQUE)

A.LAUGIER PHYSIQUE DE LA MATIERE
CH.LAUGIER PHYSIOLOGIE ET PHARMACODYNAMIE
P.LEJEUNE GENETIQUE MOLECULAIRE DES MICROORGANISMES
C.LESUEUR VIBRATIONS-ACOUSTIQUE
Y.MARTINEZ INFORMATIQUE DES SYST. DE PROD. INDUST.
C.MARTY CONCEPTION ET ANALYSE SYSTEMES MECA.
J. MERLIN GEMPPM*
H.MAZILLE PHYSICOCHIMIE INDUSTRIELLE
M.MIRAMOND METHODES
N.MONGEREAU GENIE CIVIL (GEOTECHNIQUE)
R.MOREL MECANIQUE DES FLUIDES ET THERMIQUES
P.NARDON BIOLOGIE
A.NAVARRO CHIMIE PHYSIQUE APPLIQUEE ET ENVIRON.
M.OTTERBEIN CHIMIE PHYSIQUE APPLIQUEE ET ENVIRON.
J.P.PASCAULT MATERIAUX MACROMOLECULAIRES
J.PERA SOLIDES ET MATERIAUX MINERAUX
G.PERACHON THERMOCHIMIE MINERALE
M.PERDRIX TRAITEMENT DU SIGNAL ET ULTRASONS
J.PEREZ GEMPPM*
P.PINARD PHYSIQUE DE LA MATIERE ET PHYSIQUE
INDUSTRIELLE
D.PLAY CONCEPTION ET ANALYSE SYSTEMES MECA.
P.PREVOT INFORMATIQUE DES SYST. DE PROD. INDUST.
R.REYNAUD ENERGETIQUE ET AUTOMATIQUE
J.M.REYNOUARD BETONS ET STRUCTURES
M.RICHARD ENERGETIQUE ET AUTOMATIQUE
E.RIEUTORD MECANIQUE DES FLUIDES ET THERMIQUE
J.ROBERT-BAUDOUY (Mme) GENETIQUE MOLECULAIRE DES
MICROORGANISMES
J.ROBIN PHYSICOCHIMIE INDUSTRIELLE
D.ROUBY GEMPPM*
J.F.SACADURA MECANIQUE DES FLUIDES ET THERMIQUE
H.SAUTEREAU MATERIAUX MACROMOLECULAIRES
S.SCAVARDA AUTOMATIQUE INDUSTRIELLE
F.STOEBER GENETIQUE MOLECULAIRE DES MICROORGANISMES
M.TROCCAZ GENIE ELECTRIQUE ET FERROELECTRICITE
J.TUSET SOLIDES ET MATERIAUX MINERAUX
R.UNTERREINER TRAITEMENT DU SIGNAL ET ULTRASONS
P.VERMANDE CHIMIE PHYSIQUE APPLIQUEE ET ENVIRON.
J.VERON CHIMIE PHYSIQUE APPLIQUEE ET ENVIRON.
A. VINCENT GEMPPM*
P.VUILLERMOZ PHYSIQUE DE LA MATIERE

Directeurs de recherche C.N.R.S. :

P.CLAUDY THERMOCHIMIE MINERALE
M.MURAT GEMPPM*
A.NOUAILHAT PHYSIQUE DE LA MATIERE
M.A.MANDRAND (Mme) GENETIQUE MOLECULAIRE DES
MICROORGANISMES

Directeurs de recherche I.N.R.A. :

G.BONNOT BIOLOGIE
S.GRENIER BIOLOGIE
Y.MENEZO BIOLOGIE

Directeurs de recherche I.N.S.E.R.M. :

A-F. PRIGENT (Mme) CHIMIE BIOLOGIQUE
N.SARDA (Mme) CHIMIE BIOLOGIQUE

* GROUPE D'ETUDE METALLURGIE PHYSIQUE ET PHYSIQUE DES MATERIAUX

 mes parents
 REMERCIEMENTS

Le travail prsent dans ce mmoire a t ralis au Dpartement Stratgie du

Dveloppement de l'Ecole Nationale Suprieure des Mines de Saint-Etienne.

Je tiens, tout d'abord, remercier Monsieur Albert MATHON, professeur et Directeur

des Etudes de l'Ecole Nationale Suprieure des Mines de Saint-Etienne, ancien Directeur du
Dpartement Stratgie du Dveloppement, qui m'a accueilli dans son quipe et qui a dirig
cette tude. Qu'il soit galement remerci pour la confiance dont il a bien voulu faire preuve
mon gard, sa disponibilit et son aide tant scientifique qu'administrative.

J'exprime toute ma gratitude Monsieur Jol FAVREL, professeur l'Institut National

des Sciences Appliques de Lyon, Directeur de l'Atelier Interuniversitaire Productique de
Lyon, de m'avoir accueilli dans son Groupe de Recherche en Analyse de Systme et
Productique pour mon DEA, et de sa disponibilit, sa caution scientifique, ainsi que son intrt
port aux travaux de ce mmoire qui ont constitu pour moi un soutien important.

Que Monsieur Gia Toan NGUYEN, directeur de recherche l'INRIA Rhne-Alpes,

soit vivement remerci pour avoir accept de rapporter sur ce travail et pour sa participation
au jury. Je profite de, cette occasion pour le remercier de l'attention que le Groupe de Travail
"Objets" du Ple Productique, qu'il anime, a port mon travail.

Je tiens exprimer ma gratitude Monsieur Jean-Paul KIEFFER, professeur

l'Universit d'Aix-Marseille, pour l'honneur qu'il me fait en acceptant de rapporter sur ce travail
en dpit des charges multiples qu'il assume.

A Monsieur Georges JAVEL, professeur l'IUT de Nantes, pour l'intrt qu'il a

manifest pour cette recherche en acceptant d'en tre rapporteur.

Je remercie galement Monsieur Grard BEL, Matre de Recherche l'ONERA-CERT

de Toulouse, pour l'honneur qu'il me fait en acceptant de participer mon jury de thse.

Je remercie les membres de l'quipe Etude et Modlisation des Systmes Industriels pour leur
aide diverse, en particulier Messieurs Bertrand IULLIEN, Lucien VINCENT et Sad :MIRY,
pour les discussions fructueuses qui m'ont permis de progresser dans ce travail. Je tiens
remercier galement Messieurs Redouane SENOUNE et Franois LAURENT et les membres
de l'quipe qui ont lu et corrig, sur le fond et la forme, tout ou partie de cette thse.

Mes remerciements s'adressent enfin tous ceux qui au sein de l'ex-Dpartement Stratgie du
Dveloppement ont su crer et entretenir une atmosphre de sympathie et de confiance dont
j'ai grandement bnfici. Je suis trs touch par la gentillesse de tous ceux, en particulier
Melle Bernadette ZOLD, Melle Zahia MAZER et Monsieur Andr LOUBET, qui m'ont donn
un coup de main, amicalement et gnreusement, pendant la prparation ou le jour de
soutenance de cette thse.

Et ce n'est pas cette occasion qui rendra faciles dcrire mes sentiments envers ma famille, ma
copine et mes copains l'Ecole et ailleurs!
 RESUME

L'approche objet permet des applications plus volues et plus fiables et des dveloppements
spcifiques moins coteux et volutifs. Les objectifs de ce travail sont, d'une part, de
contribuer la conceptualisation complte de modles de simulation objet et d'autre part, de
les implmenter en utilisant des techniques de programmation concurrente. Aprs une
prsentation, au chapitre I, des concepts des systmes de production et de leur gestion, nous
avons valu, au chapitre II, les diffrents modles de structure et de simulation pour les
systmes de production. Le chapitre ID propose une dmarche d'analyse pour identifier des
classes d'objets en cinq types du domaine: physiques, rles, incidents, interactions et
spcifications. Chacune de ces classes est spcifie par quatre modles: communication,
information, transition d'tat et processus. Dans le chapitre IV, nous avons conceptualis une
architecture gnrale des objets actifs, une plateforme de simulation objets concurrents et des
classes d'objets smantiques tels que les transactions, les moyens de production et les dcisions
pour l'tablissement des modles de simulation de production. Nous avons illustr, au chapitre
V, l'implmentation des cooprations spatiales et temporelles entre objets concurrents dans la
simulation avec des concepts processus "lgers" bass sur l'outil Meijin++.

MOTS-CL ES

Systme Production, Modlisation, Simulation, Orient Objet, Programmation Parallle,

Processus Communicants
 ABSTRACT

The object-oriented approach allows the development of complex and reliable applications
with less effort than with classical approaches. The objectives of this research are, on the one
hand, to propose a complete conceptualization of object-oriented simulation models and, on
the other hand, to implement them by using concurrent programming techniques. After the
presentation of the manufacturing systems and their management in chapter I, we classify the
different structure and simulation models for production systems in chapter n. In chapter rn,
we propose an analysis method to identify object classes by five domain types: physical, role,
incident, interaction and specification. Bach of these classes is specified by four models:
communication, information, state transition and process. A general architecture of active
objects and of simulation platform and the principal semantic object classes (like transactions,
production facilities and decision objects) to establish production simulation models are
presented in chapter N. In chapter V we illustrate the implementation of spatial and timing
coordination between concurrent objects in the simulation by using the concept of light-weight
processes based on the Meijin++ tool.

KEYWORDS

Production System, Modeling, Simulation, Object-Oriented, Parallel Programming,

Communicating Process
 Table Matire

Remerciements

Rsum

Introduction.......................................................................................................... 15

Chapitre 1 Systmes de Production et Gestion de Production

1 Systmes de Production......................................................................................... 19
ll Gestion de Production .......................................................................................... 21
ll.1 Classification des Dcisions .................................................................. 24
ll.2 Fonctions de Gestion .............................................................................. 26
ll.2.1 Phase de Planification ............................................................... 26
ll.2.2 Phase de Programmation ........................................................... 27
ll.2.3 Phase d'Excution ..................................................................... 28
Ill Mthodes de Gestion de Production .................................................................... 30
Ill.l La Mthode M.RP................................................................................ 31
Ill.l.l Plan Stratgique et Industriel de Production ............................. 33
Ill.l.2 Plan Directeur de Production ................................................... 33
Ill.1.3 Calcul des Besoins ................................................................... 33
Ill.1.4 Programme de Production ....................................................... 34
Ill.l.5 Conclusion sur la Mthode M.RP ........................................... 35
Ill.2 La Mthode Juste-A-Temps (J.A.T.) et la Mthode Kanban .................. 36
Ill.2.1 La Mthode Juste-A-Temps ..................................................... 36
Ill.2.2 La Mthode Kanban................................................................. 38
Ill.2.3 Conclusion sur la Mthode Juste-A-Temps et la Mthode
Kan.ban .................................................................................... 39
Ill.3 La Mthode O.P.T ................................................................................. 40
Ill.4 Conclusion sur les Mthodes de Gestion de Production......................... 44
IV Conclusion ......................................................................................................... 45
 10

Chapitre II Modlisation et Simulation des Systmes de Production

1 In.troduction........................................................... ;........................ ....................... 47

II La Mtb.ode SADT ............................................................................................... 49
II.l Les Concepts de la Mtb.ode ................................................................... 50
ll.2 Les Outils de Modlisation ..................................................................... 51
ll.3 La Dmarche de Modlisation ................................................................ 52
ll.4 Conclusion sur la Mtb.ode SADT .......................................................... 53
ill La Mtb.ode MERISE ......................................................................................... 54
lli.l Les Concepts de la Mtb.ode .................................................................. 54
ill.2 Les Outils de Modlisation .................................................................... 55
ill.3 La Dmarche de la Modlisation ........................................................... 56
ill.4 Conclusion sur la Mtb.ode MERISE ..................................................... 57
IV Les Mtb.odes GRAI et CIMOSA ....................................................................... 59
IV.l La Mtb.ode GRAI ................................................................................ 60
IV.2 La Mtb.ode CIMOSA ........................................................................... 64
IV.2.1 Le Cadre de Modlisation de CIMOSA .................................. 65
IV.2.2 L'Infrastructure Intgrante de CIMOSA .................................. 67
IV.2.3 La Mtb.odologie de Dveloppement ....................................... 68
IV.3 Conclusion sur les Mtb.odes GRAI et CIMOSA ........................ 69
IV.4 Conclusion sur les Mtb.odes d'Analyse et de Conception ........... 71
V La Simulation ...................................................................................................... 71
V.l Simulation Evnements Discrets .......................................................... 71
V.2 Modlisation de Simulation Evnements Discrets ............................... 73
V.3 Modlisation des Systmes Evnements Discrets ................................. 74
V.3.1 Approche par vnements ......................................................... 74
V.3.2 Approche par cycle d'activits ................................................... 75
V.3.3 Approche par processus ............................................................ 75
V.3.4 Approche par objets .................................................................. 75
V.4 Langages de Simulation. ......................................................................... 76
V.5 Etapes du Processus de Simulation ......................................................... 77
V.6 Conclusion sur la Simulation.................................................................. 79
VI Conclusion ........................................................................................................ 80
 11

Chapitre III Analyse des Systmes de Production par

l'Approche Objet

1 Introduction........................................................................................................... 83
TI Analyse du Domaine............................................................................................ 85
11.1 Dfinition du Domaine .......................................................................... 85
ll.2 Processus de l'Analyse du Domaine ....................................................... 88
ll.4 Identification des Classes d'Objets du Domaine ...................................... 93
rn Analyse de l'Application ..................................................................................... 97
rn.1 Spcification des Classes d'Objets pour l'Application ............................ 98
rn.1.1 Modles de Communication de Classes d'Objets ...................... 98
rn.1.2 Modles des Transitions d'Etat des Classes d'Objets ................ 103
rn.l.3 Modles Informationnels des Classes d'Objets ......................... 107
rn.2 Construction des Modles de l'Application ............................................ 112
IV Conclusion ......................................................................................................... 121

Chapitre IV Conception d'un Modle de Simulation des Systmes de

Production par l'Approche Objet

I Introduction........................................................................................................... 123
TI Conception du Comportement des Classes d'Objets ............................................. 126
ll.1 Dfinition du Script de Processus (Comportement) d'Objet Actif............ 127
ll.l.1 Perception et Acquisition .......................................................... 128
II.1.2 Cognition .................................................................................. 129
ll.1.3 Dcision .................................................................................... 130
ll.1.4 Action ....................................................................................... 130
ll.2 Conceptualisation des Processus de Production ...................................... 131
ll.2.1 Opration (Tche) ..................................................................... 131
ll.2.2 Processus .................................................................................. 131
rn Construction de Modles de Simulation .............................................................. 133
rn.1 Architecture de Modles ........................................................................ 133
rn.2 Modlisation de Production ................................................................... 135
rn.3 Intgration des Dcisions dans le Modle de Simulation ....................... 138
IV Construction des Hirarchies des Classes d'Objets Smantiques ......................... 139
IV.1 Trois Perspectives de la Reprsentation par Objets ............................... 139
IV.2 Les Points de Vue des Objets (Versions d'Objets) ................................. 140
IV.3 Les Relations des Classes D'Objets ....................................................... 142
 12

IV.3.1 Relations au Niveau de l'Application ........................ :.............. 142

IV.3.2 Relations au Niveau des Classes d'Objets ................................ 143
IV.4 Le Cycle de Vie des Classes d'Objets .................................................... 145
IV.5 Les Classes d'Objets dans la Simulation des Flux .................................. 146
IV.S.1 Dfinition des Classes d'Objets de Transactions ...................... 146
IV.5.2 Dfinition des Classes d'Objets des Moyens de Production...... 150
IV.5.2.1 Les Ressources ................................................................. 152
IV.5.2.2 Les Agents ........................................................................ 153
IV.5.2.2.1 Types des Mthodes .................................................. 154
IV.5.2.2.2 Dfinition des Processus d'une Machine .................... 156
IV.5.2.2.3 Dfinition des Processus d'une Station ....................... 159
IV.5.3 Dfinition des Classes d'Objets Dcisionnels ........................... 163
IV.5.3.1 Les rgles de Priorit (Dispatching) .................................. 163
IV.5.3.2 Les Rgles de Management .............................................. 165
IV.5.3.3 Les Rgles de Gestion de l'Allocation des Ressources ...... 166
V Construction des Classes d'Objets de Rsolution ................................................. 166
V.1 Classes d'Objets d'Application................................................................ 166
V.2 Classes d'Objets Auxiliaires/Utilitaires ................................................... 166
V.3 Classes d'Objets d'Interface .................................................................... 167
VI Conclusion ......................................................................................................... 168

Chapitre V Simulation Concurrente par l'Approche Objet

I Introduction........................................................................................................... 171
ll Dfinitions ........................................................................................................... 172
11.1 Processus ................................................................................................ 172
ll.1.1 Contexte de Processus ............................................................... 173
ll.1.2 Etats du Processus ..................................................................... 174
ll.l.3 Commutation de Contexte ......................................................... 176
ll.1.4 Descripteur de Processus .......................................................... 178
ll.l.5 Le "Scheduler" ou l'Ordonnanceur ........................................... 179
ll.2 Relations entre Processus ....................................................................... 182
ll.3 Communication et Synchronisation entre Processus ............................... 183
ll.3.1 Communication Interprocessus.................................................. l84
ll.3.1.1 Communication par zone de donnes commune ..................... 184
ll.3.1.2 Communication par messages (modle
producteur/consommateur) .................................................... 185
 13

TI.3.2 Synchronisation Interprocessus .................................... ;............ 186

rn Outils et Langages Orients Processus pour la Simulation Objets ..................... 188
rn.1 Langages avec des Primitives de Supports pour la Simulation ............... 188
rn.2 Extensions des Langages pour la Simulation ......................................... 191
rn.3 Librairies des Classes "Threads" pour la Simulation .............................. 193
IV Simulation Oriente-Objets ................................................................................ 199
IV.1 Environnement du Modle de Simulation.............................................. 199
IV.2 Hirarchie des Classes d'Objets des Systmes de Production................. 201
IV.2.1 Hirarchie des Classes d'Objets Actifs ..................................... 202
IV.2.2 Hirarchie des Classes d'Objets Passifs.................................... 206
IV.2.3 Utilisation des Classes d'Objets dans la Simulation
Concurrente ............................................................................. 208
V Conclusion .......................................................................................................... 210 .

Conclusions et Persperctives

1 Rsum du Travail ................................................................................................ 213

TI Contribution......................................................................................................... 215
rn Perspectives ........................................................................................................ 216

Rfrences ............................................................................................219

Annexe I: Objet, Simulation et Programmation Concurrente......... 231

Annexe II: Programmes en Ttes des Classes d'Objets et des Modles

d'application ....................................................................... 239
 INTRODUCTION

La conception, l'apprentissage ou le dveloppement des systmes de production industriels

impliquent des investissements humains et matriels souvent trs coteux. L'intgration de la
simulation dans le domaine industriel permet d'abaisser considrablement ces cots.

Dans la phase de conception d'un systme de production, la simulation permet de tester puis de
valider l'architecture de l'atelier et d'exprimenter moindre frais les diffrents systmes de
conduite envisageables pour une production donne. Lors de l'apprentissage d'un pilote de
conduite d'atelier, la simulation permet celui-ci d'acqurir une certaine exprience sans risque
d'accident ni de dgt matriel, toujours onreux et parfois catastrophiques. Enfin, dans les
phases de dveloppement ou de rorganisation du systme de production, les essais de
validation et de conception des commandes pourront tre entrepris sans nuire l'installation
actuelle ni son fonctionnement.

Or, le dveloppement d'un modle de simulation est une activit coteuse en temps. Dans
l'approche traditionnelle, le dveloppeur du modle doit faire appel son art et son
exprience pour produire une description algorithmique des activits et des vnements d'un
projet. Cela implique une grande partie d'efforts rptitifs consacrs au dveloppement de
logiciels spcifiques. Une fois implment et utilis, ce modle est trs rarement rutilisable ou
rexploitable. De nouvelles approches et de nouveaux types de modles sont donc ncessaires
pour rsoudre efficacement ce genre de problmes (rutilisabilit et flexibilit du modle).

L'enjeu informatique actuel des systmes de production est de trouver des approches
regroupant concepts, mthodes et outils, dans le domaine de l'intelligence artificielle ('t du
gnie logiciel, qui leur permettent d'adapter leurs activits et ainsi leurs applications aux
perptuelles fluctuations de leur environnement conomique.

En effet, si nous considrons le systme de production, non pas comme une organisation
monolithique, mais comme un ensemble d'units concurrentes de traitement et de
communication d'information, nous obtenons une organisation distribue, plus dynamique, d'un
caractre nouveau. Cette organisation est ncessaire l'adaptation des systmes- de production
la constante mutation de son environnement conomique. Ainsi les solutions des problmes
dpendent de la matrise des flux d'information manipuls par ces units de traitement et de
communication d'information.
 16

Une dmarche cohrente d'informatisation de la fonction production de l'entreprise

manufacturire se doit d'tre une dmarche globale. Aussi, le systme d'information du systme
de production ne peut tre "pens" que globalement. L'informatisation d'une activit ne doit
donc pas tre ralise indpendamment des autres activits, et en gnralisant,
indpendamment de la logique qui veut que le systme ne produise que pour rpondre aux
besoins des clients.

Une telle dmarche se heurte des problmes complexes et volutifs, qui ne peuvent tre
apprhends autrement que par une dmarche de modlisation et de simulation. Les diffrents
outils de modlisation pour la simulation jusqu' prsent utiliss, ont cependant t dvelopps
pour des applications spcifiques, illustrant surtout le cloisonnement qui existe entre les
activits du systme de production.

Cette voie n'est aujourd'hui plus acceptable et met en avant le besoin d'un outil de modlisation
plus gnral. C'est le concept objet, entit fondamentale des systmes objets, qui constitue la
premire partie du centre d'intrt de ce mmoire et qui peut raisonnablement prtendre
apporter cette gnralit. Le concept objet nous permet de faire du systme de production un
modle plus fidle la ralit et la pense humaine. Un modle de simulation est surtout
caractris par son aspect dynamique; un objet doit non seulement avoir une frontire
d'encapsulation, mais galement avoir une frontire d'interaction avec les autres processus. Le
concept de programmation concurrente pour la simulation constitue la seconde partie de ce
mmoire, il permet d'exprimer de manire plus commode et plus flexible la dynamique ou le
comportement temporel des systmes de production.

Avec le besoin d'intgrer, c'est au travers des tapes traditionnelles de conception, de

fabrication et de gestion que l'entreprise fixe un ple d'intgration. Nous nous sommes
intresss la gestion de production pour la raison principale que ce ple d'intgration prsente
aujourd'hui les rsultats les plus dcevants en matire de traitement et de communication
automatiss d'informatisation.

L'informatisation de la gestion de production tmoigne des enjeux de l'intgration. Mise en

oeuvre travers des logiciels de gestion de production assiste par ordinateur (GPAO), la
gestion de production ne contribue pas ou encore trs mal la comptitivit de l'entreprise,
ramenant ainsi l'outil informatique un simple outil d'excution. L'intgration de la simulation
la gestion nous permet d'valuer plus rapidement et plus prcisment les performances de
diffrents plans de production ou stratgies d'ordonnancement dans un systme de production
afin de mieux l'exploiter. Alors que les mthodes de gestion de production se compliquent,
rendant incontournable l'utilisation d'un outil informatique plus performant et plus puissant, il y
 17

a lieu de s'interroger sur l'opportunit de traiter les problmes lis la simulation des systms
de gestion de production avec des approches nouvelles, ce que nous avons fait avec l'approche
objet et l'approche de la programmation concurrente (ou programmation parallle).

Au mme titre que l'on parle de flexibilit de production, on peut parler de flexibilit de
gestion, et plus gnralement de flexibilit des applications qui contribuent la comptitivit de
l'entreprise. Le modle objets est notre sens le moyen d'obtenir la flexibilit et la fiabilit de
modle de production, et la programmation concurrente avec une interface conviviale est le
moyen d'obtenir la flexibilit et la dynamique de la gestion de production.

C'est en ce sens que nous avons effectu les travaux prsents dans ce mmoire et par l mme
que nous faisons des propositions. Nous avons en particulier organis ce mmoire en cinq
chapitres pour nous amener, problmes aprs problmes, proposer une approche objet ddie
l'analyse des systmes de production, une approche processus ddie la conception d'un
modle de simulation des flux, une approche programmation concurrente ddie
l'implmentation de modle de simulation, ainsi qu'une plate-forme qui va intgrer un module
de la simulation dans la gestion de production comme un outil d'aide la dcision.

Le premier chapitre est consacr une prsentation gnrale des systmes de production et de
leur gestion. Nous y prsentons les mthodes de gestion qui, notre avis, sont les plus
marquantes en planification et ordonnancement de la production. Cependant, ces mthodes ou
logiques de gestion de production, informatises dans les logiciels de GPAO, s'avrent d'une
utilisation rigide du fait de l'impossibilit de les adapter la spcificit, ce qui nous amnent
reconsidrer les modles de reprsentation des systmes de production.

Le chapitre TI prsente les mthodes reprsentatives d'analyse et de conception des systmes de

production: les modles de structure correspondant aux mthodes SADT, MERISE, GRAI et
CIMOSA et les modles de simulation. Nous dcrivons les principaux concepts sur lesquels
ces mthodes s'appuient, ainsi que les diffrentes tapes d'analyse et de conception des
systmes de production. Enfin, nous effectuons des analyses critiques de ces mthodes par
rapport la flexibilit du problme et la flexibilit de sa reprsentation pour introduire les
trois chapitres suivants: utilisation de l'approche objets pour analyser, concevoir et implmenter
les modles de simulation des systmes de production.

Les objets des systmes de production sont identifis et spcifis dans le chapitre m. Deux
tapes d'analyse sont proposes: une tape d'analyse du domaine qui tablit le contexte
principal dans lequel le systme sera construit et une tape d'analyse de l'application qui se
concentre sur le domaine d'intrt afin de construire un cahier des charges pour une application
 18

particulire. Les types d'objets et leurs modles correspondants: modles de Communication,

modles de transition d'tats et modles d'information sont prsents

Dans le chapitre IV, nous appuyant sur les concepts d'objets autonomes et actif et d'objet
passif, nous avons conceptualis une architecture gnrale d'un objet actif et conu une
architecture d'un modle ouvert et flexible et l'intgration des dcisions dans le modle de
simulation. Les classes d'objets smantiques pour les systmes de production, les classes
d'objets d'application et de rsolution sont construites et hirarchises. Nous avons aussi
dtaill les modles de processus d'objets pour la machine et la station dans le but d'illustrer
comment nous pouvons implmenter la dynamique du systme.

Le chapitre V est consacr l'implmentation des modles de simulation concurrente. Nous

avons commenc par les concepts de base de la programmation concurrente: la notion de
processus et les relations entre les processus en terme informatique. Ensuite, nous avons
prsent trois langages ou outils bass sur le langage de programmation C++ qui permettent
d'implmenter les modles de simulation. Enfin nous en avons choisi un pour illustrer comment
nous avons implment les classes d'objets des systmes de production.

La conclusion gnrale fournit un bilan des travaux que nous avons mens ainsi que les travaux
et objectifs futurs concernant la simulation oriente-objets.
 Chapitre 1 Systmes de Production et Gestion de Production

1 Systmes de Production

La production est une opration de transformation qui convertit des matires premires et/ou
des composants que l'on peut qualifier de "bruts" (au sens le plus gnral) en produits finis plus
labors et de valeur conomique plus leve.

Un systme de production est un ensemble de ressources qui permettent cette transformation.

Dans cet ensemble, on distingue essentiellement quatre types de ressources: des quipements
(machines, outils, moyens de transport, moyens informatiques, ... ), des moyens humains qui
permettent le bon droulement du processus de transformation, des produits diffrentes
tapes de fabrication (matires premires, produits semi-finis, produits finis, ... ), des entrepts
de matires ou des aires de stockage.

En ce qui concerne les quipements de production, on distingue trois sous-types: les machines
de production, permettant d'effectuer des oprations de transformation, les machines de
manutention, permettant de transporter des pices dans l'atelier (robots, chariots mobiles, tapis
roulant, transtockeurs, ... ), et les machines de contrle de qualit. Les deux dernires peuvent
tre considres comme des machines de production spciales ou fictives.

Un produit fini est gnralement obtenu par assemblage de plusieurs composants. Un

composant est son tour obtenu par assemblage d'autres pices ou par une succession de
transformations de matires premires. Les matires premires, les composants (produits semi-
finis) ainsi que les produits finis sont des articles, qui se distinguent les uns des autres par leur
tat de transformation. Un article qui subit une opration de transformation devient un article
l'tat diffrent. Un article (en cours de transformation) est souvent appel une ''pice" dans la
production.

La description complte du processus de fabrication d'un produit fini est donne par une
arborescence des composants, connue sous le nom de nomenclature, et la description du
processus de chaque composant est donne par sa gamme de fabrication. Une gamme de
fabrication est l'ensemble des oprations qui conduisent l'achvement d'un composant ou d'un
produit dans le cadre du systme de production.
 20

Face la complexit du processus de fabrication, les systmes de production sont organiss et

grs en fonction des demandes et des ressources disponibles. On trouve dans la littrature de
nombreuses typologies des systmes de production. Nous considrons que les deux typologies
intressantes proposes par Giard [GIARD 88] sont les plus naturelles et les plus synthtiques
bien qu'il y ait beaucoup de proposition dans les littratures.

La premire typologie est base sur le fait qu'un systme de production peut produire soit pour
rapprovisionner des stocks (production prvisionnelle) soit pour satisfaire une demande
(production la demande). Une production est prvisionnelle lorsqu'elle est dclenche par un
tat de stock. Un systme de production produit la demande lorsque la production est
dclenche par les demandes fermes des clients (voir section II.l ).

La production prvisionnelle conduit des modles dterministes ou stochastiques de gestion

de stocks. Parmi ces modles, on trouve en particulier les fameux modle de quantits
conomiques qui assurent un compromis optimal entre les cots de stockages et les cots
d'obtention de produits ou les cots d'approvisionnement [TERSINE 88].

On trouve galement la combinaison de ces deux modes de fabrication dans des systmes qui
comportent la fois la fabrication des composants et l'assemblage. On produit souvent les
composants de manire prvisionnelle et l'assemblage se fait la demande des clients. Ceci
permet de fournir une grande varit de produits assembls partir d'un nombre limit de types
de composants.

La deuxime typologie est lie au mode d'organisation de la production ([MULKENS 93],

[JAVEL 93]). On peut distinguer les quatre modes d'organisation suivants:

- Organisation en ligne de fabrication. Dans les systmes organiss en ligne de fabrication,

les quipements sont agencs de telle faon que les produits sont fabriqus en passant
successivement et dans le mme ordre par les postes de travail de la ligne. Ce mode
d'organisation ncessite la spcialisation des quipements. n repose sur la parfaite
standardisation des gammes de fabrication et la rgularit de la circulation du flux de
matires. Ce mode d'organisation permet une trs bonne utilisation des quipements. Les
temps d'attente des pices pour la fabrication sont faibles. Un autre avantage de ce mode
d'organisation est la simplicit de sa gestion. TI n'est pratiquement pas ncessaire
d'ordonnancer la production. La rigidit de ce mode est justifie lorsque la quantit de
produits fabriqus est suffisamment grande. C'est le cas dans les productions de masse.
 21

- Organisation en ateliers spcialiss (cellules f/exib_les). Dans ce type d'organisation, on

runit en un mme lieu les quipements qui assurent une mme fonction technique. Ce
mode d'organisation est la consquence de la diversit des articles transformer. Chacun
de ces ateliers fait l'objet d'une production limite.. Dans ce mode d'organisation, les
machines ne sont gnralement pas spcifiques et peuvent effectuer plusieurs types
d'oprations. L'avantage de ce mode d'organisation est la flexibilit du systme. Le
principal inconvnient est l'inefficacit de la fabrication par rapport une organisation en
ligne. En effet, le cot et le temps de manutention des articles entre les ateliers et les
machines sont souvent importants. De plus, la diversit des gammes de fabrication
(produits) dans chaque atelier pose un problme d'ordonnancement difficile. Les temps
d'attente des articles pour la fabrication sont souvent plus importants que dans
l'organisation en ligne. En mme temps, les machines ne sont pas aussi bien utilises que
dans l'organisation en ligne de fabrication.

- Organisation en production unitaire. TI s'agit de la ralisation de quelques produits sur des

priodes assez longues, par exemple la fabrication des prototypes. TI est ncessaire de
planifier la succession des diffrentes tches. Un diagramme de type PERT, par exemple,
est souvent utilis pour la planification des tches et de son suivi.

- Industrie de processus ou production continue. Les produits fabriqus subissent des

transformations pratiquement continues. On rencontre, par exemple, ce mode
d'organisation dans l'industrie chimique ou sidrurgique.

Dans ce travail, nous nous intressons aux systmes de production fonctionnant en prvisionnel
et organiss en ateliers spcialiss. C'est le cas le plus gnral dans l'industrie.

II Gestion de Production

L'objectif d'un systme de production est de fournir aux clients des produits de bonne qualit,
. un prix comptitif et en respectant les dlais. L'entreprise doit chercher en permanence
amliorer ses produits et ses dlais de livraison, elle doit en outre diminuer constamment le
cot de production.

Le systme de gestion a pour rle d'assurer en permanence la bonne utilisation de l'ensemble

des moyens de production. Pour bien grer la production, les dcisions prises par le systme de
gestion doivent tre bases sur des informations actualises (tat du systme de producton,
ressources disponibles, situation des clients et des fournisseurs). Un bon systme de gestion est
 22

caractris par sa capacit d'acquisi~ion des informations ncessaires et par sa capacit de prise
de dcisions en cas ncessaire.

Si l'on suit le mouvement des matires dans un systme de production, on peut dcomposer
son fonctionnement en trois tapes:

- Etape de rapprovisionnement qui consiste commander aux fournisseurs les matires

premires et les composants requis pour la fabrication.

- Etape de fabrication qui transforme les matires premires et les composants en produits
finis.

- Etape de distribution qui assure la livraison des produits finis aux clients.

Le mauvais fonctionnement d'une tape quelconque perturbe le fonctionnement de l'ensemble.

Le systme de gestion doit coordonner le fonctionnement de ces tapes.

La figure suivante (figure 1-l) schmatise les interactions des sous-systmes dans un systme
de production. En terme d'automatique, c'est une gestion avec retour d'information en boucle
ferme.

Rapprovisionnement Fabrication Distribution

Figure 1-1 Interactions des Sous-Systmes dans l'Entreprise .

Le systme d'information collecte les informations sur la capacit actuelle de fabrication, les
fournisseurs, les demandes, les prvisions, etc. n permet galement d'valuer les dcisions
prises par le systme de gestion et de suivre l'volution du march et de la technologie. n met
 23

le systme de gestion au courant de tout changement du systme de production et du monde

extrieur ce qui permet une adaptation rapide des dcisions.

Les dcisions sont prises en fonction des informations coll~ctes par le systme d'information.
Pour un systme de production, il y a en permanence de nombreuses dcisions prendre. De
plus, il existe souvent des alas qui perturbent le fonctionnement du systme. Cette instabilit
de l'tat du systme rend naturellement la prise de dcision plus difficile.

Une autre difficult de la gestion est due au fait que les objectifs ne sont pas clairement dfinis.
Souvent, on a une liste d'objectifs souhaits qui peuvent tre contradictoires, par exemple:

- minimiser les en-cours et les stocks;

- livrer les produits aux clients dans le plus court dlai;
- utiliser au mieux la capacit des moyens de production et les personnels disponibles;
- minimiser les heures supplmentaires;
- minimiser le cot de production;
- etc.

Pour atteindre ces objectifs, il faut tout d'abord abandonner la mise en oeuvre de la gestion de
production technique par technique, au profit d'activits concomitantes et surtout cohrentes.
Donnons un exemple pour le prouver.

Une technique de gestion de stocks a pour objectif le calcul de quantits conomiques de

stockage pour chaque produit rfrenc dans l'entreprise. Ce calcul s'inspire souvent de la
formule de Wilson, qui dtermine cette quantit par un compromis entre le cot de stockage et
le cot d'approvisionnement. Le cot d'approvisionnement est d'autant faible que la quantit
approvisionne (donc en stock) est leve (cot d'approvisionnement, cot de rglage d'une
machine, etc.).

Une autre technique: le contrle de qualit a souvent pour objectif la mesure statistique de la
qualit des produits. Les indicateurs de qualit issus de ces calculs prconisent d'agir sur les
procds de fabrication ou sur les moyens de production l'origine de la non-conformit des
produits. La mesure statistique d'une caractristique d'un produit s'effectue sur plusieurs
chantillons. Ces chantillons sont extraits du stock du produit, dont la quantit est dtermine
par ailleurs, comme nous l'avons dcrit dans la technique de gestion de stockS. Remarquons
que la mesure statistique est d'autant plus reprsentative de la qualit du produit que la quantit
en stock est faible (reprsentativit des chantillons par rapport la population en stock).
 24

Dans l'application de la premire technique, on tend augmenter le stock, lors que dans
l'application de la seconde, on souhaite qu'il diminue. La contradiction qui apparat ici, montre
la dpendance entre deux problmes de la production: adopter une politique de qualit efficace
oblige une gestion diffrente de stocks. Le systme de gestion doit aboutir un bon
compromis entre ces objectifs contradictoires.

ll.l Classification des Dcisions

Afin de rduire la difficult de la prise de dcisions, on adopte une approche progressive. Les
dcisions sont souvent prises en trois tapes successives caractrises par l'horizon sur lequel
les dcisions s'appliquent [XIE 89]:

- Les dcisions stratgiques qui concernent la politique gnrale de l'entreprise long terme
(horizon de plus de deux ans, en gnral). A partir de l'analyse de la tendance du march, de la
prvision de l'volution des technologies et de l'analyse de la concurrence, les dcisions
stratgiques cherchent faire voluer l'ensemble des produits et ajuster le mode
d'organisation et la capacit de la production aux besoins du march. Les dcisions
stratgiques se traduisent par:

- investissement en quipements, recrutement et formation du personnel;

- arrt de fabrication de certains produits et lancement en fabrication de nouveaux
produits;
- conception de nouveaux produits;
- adaptation de nouveaux modes de production, par exemple Juste-A-Temps;
- programme publicitaire;
-etc.

- Les dcisions tactiques qui correspondent un ensemble de dcisions moyen terme

(horizon variant entre 3 mois et 2 ans, en gnral). La capacit de production a t fixe par le
niveau suprieur (dcisions stratgiques). A partir du carnet de commandes fermes des clients
et de la prvision des demandes, les dcisions tactiques dfinissent un plan de fabrication. Elles
se traduisent par un calendrier de production (programme de production).

- Les dcisions oprationnelles qui contrlent le droulement quotidien du processus de

production dans le respect des dcisions tactiques. Les dcisions oprationnelles assurent
l'ordonnancement des oprations sur les machines, l'affectation des oprateurs aux machines, la
livraison des produits finis aux clients, etc. Elles tiennent compte de tous les dtails du
fonctionnement du systme de production.
 25

La figure suivante (figure 1-2) schmatise les interactions entre ces trois niveaux de dcisions.
A chaque classe de dcision correspond un horizon diffrent. Les informations ncessaires sont
d'autant plus agrges que l'horizon loigne. De plus, les c,icisions prises concernent d'autant
plus d'lments que le niveau de dcision est lev.

commandes dtailles

Figure 1-2 Interactions entre les Dcisions en Gestion de Production

Au niveau des dcisions stratgiques, seules les prvisions sur l'valuation du march et de la
technologie sont prises en compte. Les dcisions stratgiques ont des effets globaux et
profonds sur le fonctionnement du systme. C'est uniquement ce niveau que l'on effectue les
prises des dcisions importantes sur l'volution du systme physique (organisation du systme).

Au niveau des dcisions tactiques, on considre les commandes fermes, les prvisions de
demande regroupes en familles de produits, et les capacits agrges des sous-systmes de
production. Les dcisions sont les productions globales sur des priodes lmentaires
relativement importantes (le mois ou le trimestre, par exemple).

Les dcisions oprationnelles concernent le dtail du fonctionnement du systme en temps rel.

Toute dcision prise un niveau devient une contrainte pour les dcisions du niveau
immdiatement infrieur. Un retour d'information vers les niveaux suprieurs est ncessaire afin
de prendre en compte les changements d'tats rsultant de l'application des dcisions (suivi).
 26

Un problme important est de dfinir l'information fournir chaque nivea, sa forme, sa

priodicit, son niveau d'agrgation, etc.

Dans ce mmoire, nous nous intressons aux dcisions taetiques et oprationnelles, c'est--dire
la planification de la production et son ordonnancement.

II.2 Fonctions de Gestion

Nous tudierons ici les diffrentes fonctions de gestion court et moyen terme qui
correspondent aux dcisions tactiques et oprationnelles dcrites dans le paragraphe prcdent.
La prise de ces dcisions peut, dans la pratique industrielle, tre divise en trois phases:
planification, programmation et excution.

II.2.1 Phase de Planification

Dans la phase de planification, il s'agit d'tablir un plan directeur de production. On a un

carnet de commandes fermes et la prvision des demandes futures. Les dcisions portent
essentiellement sur la production de familles de produits finis sur un intervalle de temps appel
horizon de planification. L'objectif est de satisfaire la demande en minimisant les stocks, les
retards, le cot de production, etc. Cette phase correspond au niveau des dcisions tactiques.
En planification de la production, on distingue deux approches fondamentalement diffrentes:
l'approche globale et l'approche hirarchise [XIE 89].

L'approche globale utilise un modle monolithique qui dcrit l'ensemble du problme de

planification de manire dtaille. Elle fournit toutes les dcisions sur l'horizon complet. Mais
l'utilisation de cette approche, base essentiellement sur la programmation linaire en variables
mixtes, conduit des programmes de grandes tailles et des temps de calcul exponentiels
[GERSHWIN 89]. A notre connaissance, il n'y a pas de mthodes qui puissent fournir en un
temps raisonnable le plan de production d'un systme rel par une approche globale. D'autre
part, beaucoup de donnes sont prvisionnelles. La grande quantit de donnes ncessite un
n
systme de prvision complexe. est sans intrt de considrer les donnes de faon dtaille
sur l'horizon complet.

L'approche hirarchique est propose par de nombreux auteurs. On trouve l'tat de l'art dans
Hax et Meal [HAX et al. 75] et Giard [GIARD 88]. Cette approche dcompose le problme de
planification en sous-problmes. Chaque sous-problme est li un niveau dans une hirarchie.
A chaque niveau, les entits sont des agrgats des entits du niveau immdiatement infrieur.
 27

L'horizon de planification dcrot en descendant dans la hirarchie. Les dcisions

correspondant ces agrgats sont dsagrges au niveau immdiatement infrieur.

Les travaux de Hax et Meal sont bass sur une agrgation logique des produits: articles,
familles, types, et ont conduit l'laboration d'une planification en trois tapes:

- La premire tape dtermine un plan de production des types de produits sur l'horizon
complet de la production. Le modle utilis est un modle linaire, qui prend en compte la
capacit du systme, les heures de travail rgulires et supplmentaires, le cot de
stockage et le cot de fabrication, pour minimiser un cot de gestion et satisfaire la
demande de chaque type de produits sur la priode considre.

- La deuxime tape correspond une dsagrgation de la programmation par type de

produits en une programmation par famille de produits. Cette dsagrgation est faite
uniquement pour la premire priode de l'horizon. Pour la priode suivante, la
programmation sera faite en tenant compte des rsultats rels du droulement de la
premire priode afin que des ajustements puissent tre effectus. L'objectif retenu est de
minimiser la somme des cots de lancement de la production des familles qui constituent
ce type.

- La troisime tape est une dsagrgation de la programmation par famille de rfrences en

programmation par article de rfrences.

Cette approche hirarchise prsente l'avantage de ne comporter qu'un type de prvision, celui
de la demande des types de produits et de tenir compte du droulement du processus de
fabrication en appliquant une programmation priode par priode.

ll.2.2 Phase de Programmation

La phase de programmation consiste calculer les besoins en composants et les besoins en

capacit en fonction du plan directeur de production. La planification des besoins en
composants (Material Requirement Planning ou M.R.P.) dtermine quels composants et
matires premires il faut approvisionner ou fabriquer, en quelles quantits et quelles dates.
Ces calculs sont bass sur l'laboration des gammes de fabrication (ou nomenclatures) des
produits finis. A l'issue de la planification des besoins en composants, la pltmiftcation des
besoins en capacit quantifie les ressources ncessaires de fabrication. Ces informations
permettent de dterminer le nombre de postes de travail utiliser, la rpartition des oprateurs
et le nombre d'heures supplmentaires. Cette phase est largement tudie dans la littrature et
 28

de nombreux logiciels de type MRP sont implants dans les entreprises [ORLICKY 75]. Elle
se situe galement au niveau des dcisions tactiques.

II.2.3 Phase d'Excution

Dans cette phase, on aflfonte les dtails du droulement de la production. Dans les activits de
production proprement dite, la fonction d'ordonnancement d'atelier a pour objectif d'tablir un
agenda de production pour chaque machine afin de fabriquer les pices en temps voulu. Cet
agenda est sujet aux modifications dues aux alas du systme de production. Une fonction de
suivi de production a pour rle l'acquisition des informations sur le droulement de la
production, ce qui permet la modification des agendas de production en cas de perturbations.
Cette dernire phase se situe au niveau des dcisions oprationnelles.

L'ordonnancement de la production a pour rle d'organiser l'excution des oprations sur les
machines dans chaque atelier. TI doit ragir tout changement non prvu tel que les pannes des
machines, les ruptures (manques) de matires premires, l'absence de personnel, etc.

Les mthodes de rsolution des problmes d'ordonnancement puisent dans toutes les
techniques de l'optimisation combinatoire (programmation linaire ou dynamique, procdures
par sparation et valuation, thorie des graphes, etc.). Ces mthodes garantissent en gnral
l'optimalit de la solution fournie. Mais les algorithmes dont la complexit n'est pas
polynomiale ne peuvent pas tre utiliss pour des problmes de grande taille, d'o la ncessit
de construire des mthodes de rsolution approche, efficaces pour ces problmes souvent NP-
difficiles [CARLIER et al. 88]. Diffrentes approches de rsolution sont proposes dans la
littrature; on distingue les cinq mthodes suivantes: par construction progressive, par
voisinage, par dcomposition, par relaxation et enfin celles lies l'intelligence artificielle. On
trouve l'tat de l'art dans l'article de GOTHA [GOTHA 93].

Les mthodes par construction progressive sont des mthodes itratives o, chaque itration,
on complte une solution partielle. Contrairement aux mthodes par construction qui
travaillent sur des solutions partielles, les mthodes par voisinage travaillent sur des solutions
compltes. Chaque itration de la mthode par voisinage ayant pour objectif (pas toujours
atteint) de passer d'une solution complte une autre solution complte meilleure par rapport
au critre considr.

En ce qui concerne les mthodes par dcomposition, il existe de nombreuses faons de les
construire:
 29

- la dcomposition hirarchique [ERSCHLER et al. 85] consiste dcomposer les

problmes en plusieurs niveaux, par exemple un niveau suprieur o on travaille sur des
donnes agrges et o on dcide d'un nombre de paramtres globaux et un niveau
infrieur dtaill o les dcisions prises sur ces paramtres globaux deviennent des
contraintes pour le niveau infrieur, ce qui limite le domaine des solutions explorer.

- la dcomposition structurelle [ROY 70] utilise la modlisation du problme et ses

grandes familles d'inconnues; elle considre que les moyens sont illimits et rsout le
problme temporel. Les dates tant fixes, on cherche la meilleure affectation possible
des moyens, puis on revient au problme temporel en ajoutant de nouvelles contraintes
lies l'utilisation de ces moyens, etc.

- la dcomposition de l'ensemble des solutions du problme conduit, si l'on veut obtenir la

solution optimale, des procdures par sparation et valuation. Toutefois, ces
mthodes exactes peuvent tre transformes en heuristiques de diffrentes faons, par
exemple, dans le cas du recuit simul, en les arrtant lorsque pendant Q itrations on n'a
pas strictement amlior la meilleure solution trouve ou encore, lors des sparations, en
n'essayant pas toutes les valeurs possibles pour l'inconnue sur laquelle on affecte la
sparation, mais seulement un chantillon de valeurs possibles.

- la dcomposition temporelle [PORTMANN 87], dans le cas des ordonnancements

dynamiques o les travaux arrivent des dates diffrentes et disperses dans le temps,
rsout lors de la premire itration un problme rduit en ignorant les travaux qui
arrivent au-del d'une date choisie, puis retient dfinitivement cet ordonnancement partiel
jusqu' une autre date dtermine. A l'itration suivante, on dcalera ces deux dates de
manire construire la portion suivante de l'ordonnancement.

- la dcomposition spatiale [PORTMANN 87] dcompose l'atelier en sous-ateliers avec le

moins possible de dplacements de produits entre les sous-ateliers grce des outils de
technologie de groupe et construit une mthode itrative dans laquelle chaque itration
ordonnance un sous-atelier.

Les mthodes par modification des contraintes essaient de changer le modle des problmes
que l'on a rsoudre. Ce peut tre, par exemple, de transformer un flow-shop normal en un
flow-shop de permutation de manire avoir moins de solutions explorer, mais on trouve
surtout ici toutes les mthodes dites de "relaxation": relaxation de contraintes d'intgrit,
relaxation lagrangienne, relaxation "surrogate", etc.
 30

Les mthodes lies l'intelligence artificielle utilisent des techniques de reprsentation des
connaissances et de rsolution de problmes issues de l'intelligence artificielle. De nombreux
travaux ont abord les problmes d'ordonnancement l'aide de ces outils. L'utilisation des
techniques de l'intelligence artificielle, en particulier les systmes experts d'ordonnancement
d'atelier, permet de manipuler avec souplesse des ensembles d'heuristiques plus nombreux et
plus prcis [BEL 88]. Certains systmes ont t implants avec succs dans l'industrie [BEL et
al. 88] tels que ISIS (Intelligent Scheduling and Information Systems), OPIS (Opportunistic
Intelligent Schedules), SOJA (Systme d'Ordonnancement Journalier d'Atelier), PLANNEX et
OPAL, etc. L'intgration de la simulation dans la rsolution de problmes d'ordonnancement
[JAIN et al. 90] [YE et al. 92a] permet d'ordonnancer en temps rel ("on-line") un atelier en
amliorant les performances des mthodes d'ordonnancement.

En conclusion, l'ordonnancement est un domaine o les problmes rsoudre sont difficiles. La

difficult est la fois thorique et pratique. Thorique parce que la plupart des noncs
correspondent des problmes combinatoires de complexit exponentielle (NP-difficiles).
Pratique parce que les particularits de chaque atelier font que la solution obtenue grand frais
n'est pas toujours utilisable: on a souvent nglig des aspects technologiques ou humains
difficilement modlisables par les mthodes classiques de recherche oprationnelle. Les
problmes rels sont donc mal rsolus et paraissent a priori trs complexes; on peut cependant
souvent trouver des mthodes de rsolution trs satisfaisantes. Ces problmes sont distincts les
uns des autres et ne peuvent pas tre traits efficacement l'aide d'un outil standard. Une partie
au moins de la recherche thorique est proche des cas rels. Les outils thoriques permettent
l'heure actuelle de rsoudre certains problmes de grande taille (par exemple le job-shop). Les
bonnes heuristiques, suffisantes le plus souvent, sont des sous-produits d'tudes thoriques
fines [GOTHA 93].

III Mthodes de Gestion de Production

Les mthodes de gestion de production ont l'origine privilgi une logique de gestion plutt
qu'une autre. Parmi les plus clbres outils de gestion de production assiste par ordinateur
(GPAO), citons: "grer par une planification" pour la mthode M.R.P. II, "grer en juste--
temps" pour la mthode Kanban, et "grer par les moyens de production signifis pour leurs
goulots d'tranglement" pour la mthode O.P.T.

Rien ne prouve cependant qu'il faille se limiter ces logiques. Plus gnralement, un reproche
que l'on peut faire ces mthodes, est de figer les rgles de gestion, a fortiori lorsqu'elles sont
dcrites dans un logiciel de GPAO, qui sont difficiles adapter chaque entreprise, voire
appliquer, compte tenu des diffrents types de production rencontrs. Nous nous intressons
 31

dans ces travaux, pour l'essentiel, aux outils logiciels ou modles qui permettent la mise en
oeuvre des mthodes, et cette occasion, la manire de ne plus figer les rgles de gestion au
sein de ces outils. Nous nous proccupons de la gestion de production sous cet angle, et
pensons que la gestion de production n'est donc pas qu'un problme de mthode. Nous
prsentons dans la suite les mthodes les plus connues.

ID.l La Mthode M.R.P.

La mthode de gestion de production M.R.P. (Manufacturing Resource Planning ou Material

Requirement Planning) [ORLICKY 75] est traditionnellement associe la logique de gestion
par planification. Elle trouve son origine sur la base des deux analyses suivantes :

1) Les produits appartenant au flux matire circulant dans l'entreprise, sont l'objet de
deux types de besoins [BELT et al. 86]. D'une part, les besoins indpendants de la volont
directe de l'entreprise, c'est--dire les besoins qui s'expriment d'une faon externe et alatoire
par rapport l'entreprise: ce sont les commandes que l'on n'est jamais sr d'obtenir ou encore
les besoins de pices de rechange pour l'aprs-vente. D'autre part, les besoins dpendants de
l'entreprise elle-mme, c'est--dire les besoins qui peuvent tre exprims d'une faon
dterministe partir de ceux qui ne peuvent tre qu'estims, concernant tous les composants
d'assemblage ou de fabrication. Les besoins indpendants ne peuvent donc qu'tre exprims
(commandes fermes) ou prvus (demandes et commandes prvisionnelles), par contre, les
besoins dpendants sont calculs grce aux nomenclatures des besoins indpendants qui
dcrivent la dpendance structurelle de fabrication des produits.

2) La planification de tous ces besoins est ncessaire. Une planification a pour but de
dcrire, pour une chelle temporelle dfinie par un horizon de planification (i.e. une limite de
validit) et une priode de ractualisation, un plan de production. Un plan de production
rpond entre autres aux questions :

- que produire ?
- quand produire ?
- quelle quantit produire ?

Un plan de production est une "photographie" de la production pour un horizon dtermin et

regroupe de ce fait des informations de nature expliquer l'volution de la production. On
trouve donc parfois dans un plan de production des informations sur les ventes, les stocks et
les activits de production.
 32

La planification vise dgager une capacit d'adaptation accrue de l'entreprise: rpondre aux
besoins des clients en temps voulu est en effet obtenu ici par anticipation. Pour cette raison, la
mthode M.R.P. ll propose le schma de gestion de la figure suivante (figure 1-3).

La logique de gestion par planification apparat dans la mthode M.R.P. ll, au travers de
l'enchanement de plans de production, o figurent des informations cohrentes d'un niveau
un autre. Nous proposons d'expliquer cet enchanement pour comprendre ce qu'est un systme
de planification.

Horizon de
planification
Plan Stratgique
et Industriel
de Production

Plan Directeur
de Production
Planification
...,n...,.,.., terme

Calcul des Besoins

Expression des
besoins nets

Programme de Production

Ordres de

Matires premires
Produits semi-finis Produits finis

Figure 1-3 Mthode M.R.P. ll

 33

ill.l.l Plan Stratgique et Industriel de Production

Le plan stratgique et industriel de production (PSIP) exprime les ventes connues et espres
des familles de produits, ainsi que la production et les ~tocks, rels et prvisionnels de ces
familles. Son utilit est justifie par le fait que les prvisions de vente par familles de produits
sont plus faciles tablir que celles sur les produits eux-mmes. On se base essentiellement sur
une analyse de l'historique du pass: on cherche dfinir le modle des commandes passes le
plus proche de la ralit. Ce modle va nous servir faire des prvisions sur les demandes
futures. Ce plan confront aux capacits de production, aux capacits de financement et aux
capacits techniques permet de dterminer, en raisonnant sur les familles de produits, le niveau
de production mensuel acceptable fixant l'objectif stratgique de l'entreprise. Son horizon de
planification est gnralement l'anne et est dcoup par priodes de ractualisation d'un mois.

ill.1.2 Plan Directeur de Production

A partir des prvisions de tendances du march et de comportement du systme de production

et de la stratgie suivre, le plan directeur de production (PDP) traduit les objectifs de ces
prvisions exprimes en familles de produits. En effet, on ne fabrique pas une famille de
produits mais un produit, et on n'approvisionne pas des familles de composants ou des familles
de matires premires, d'o la ncessit d'une traduction de cette stratgie. Les paramtres de
prvisions sont dtaills pour chaque produit et ne sont plus relatifs des familles de produits
comme c'tait le cas pour le PDP. Son horizon de planification est en gnral de quelques mois
et est dcoup par priodes de ractualisation d'une semaine. Notons que cet horizon de
planification est dpendant des types de produits fabriqus par l'entreprise. On prfre ainsi
fixer cet horizon en fonction du cycle technique de production. Le cycle technique de
production est le temps entre la date de mise en fabrication d'un produit et sa date d'entre en
stock ou sa date de livraison. TI est calcul par la somme des temps opratoires sur la gamme
de fabrication ( travers sa nomenclature) et inter-opratoires (temps de transport et temps
d'attente) du produit. Contrairement au PSIP, le PDP est excutoire, en ce sens qu'il fixe le
niveau d'activit de la production de l'entreprise.

ill.1.3 Calcul des Besoins

Le but est de dterminer, pour une priode donne, les besoins en articles fabriquer
(composants ou produits finis) ou approvisionner (composants ou matires premires). Ces
besoins expriment les fabrications (ordres de fabrication) et les approvisionnements (ordres
d'achat) raliser en quantit et date. n y a deux types de calcul des besoins: calcul des
besoins bruts et calcul des besoins nets. Le calcul des besoins bruts est ralis partir des
nomenclatures des produits. Une nomenclature donne les produits dont on doit disposer en
 34

stock et les composants dont il faut disposer (achets ou fabriqus). Les dates des besoins
exprimes par le calcul des besoins bruts sont compares aux stocks prvisionnels. Ceci permet
de dduire des ordres de fabrication (O.F.) ou des ordres d'achat (O.A).

La quantit des besoins est une quantit conomique et/ou technique, qui satisfait des
contraintes de cot de production et/ou des contraintes techniques de fabrication, en donnant
lieu des regroupements en lots de fabrication. La date de mise en fabrication est calcule en
fonction de la date de mise disposition des quantits, en tenant compte des dlais de
fabrication. Cette date de mise en fabrication est en gnral calcule au plus tard (date limite).
Toute quantit tient aussi compte des stocks rsiduels de fabrication d'un produit.

ID.1.4 Programme de Production

Le rsultat du calcul des besoins nets est un ensemble d'ordres de fabrication. Chaque ordre est
caractris par une quantit et une date. Ces 0 .F. (prvisionnels) ont t labors sans tenir
compte de la capacit relle du systme de production. On parle alors d'ordonnancement
capacit infinie.

Le programme de production a pour but d'ajuster les capacits aux charges. La capacit d'un
moyen de production mesure la production maximale en units de produits par units de
temps. La charge d'un moyen de production mesure elle, l'utilisation sur une priode d'un
nombre d'units de capacit. En outre, l'ajustement a pour but d'assurer que :

- la charge est infrieure la capacit. C'est une contrainte matrielle vidente.

- la charge tend vers la capacit. C'est une contrainte conomique importante, car elle
permet de rentabiliser l'usage des moyens de production.

La mthode M.R.P. ll traite grossirement les problmes d'ajustement des capacits aux
charges avant la constitution du programme de production. Cet ajustement, qui peut dgager
des capacits suplmentaires si ncessaire et si possible, est fait par groupe de moyens de
production, et non par moyen de production.

Le programme de production tablit la transition dans la mthode M.R.P. entre la planification

et l'ordonnancement des tches de fabrication. Son horizon est d'environ une, voire deux
semaines. Le rsultat du calcul des besoins qui dtermine un ordre de ralisation des 0 .F. est
qualifi d'ordonnancement capacit infinie. L'objet essentiel du programme de fabrication est
de substituer cet ordre, un ordre de passage des tches associes aux O.F.. Une tche est le
travail rsultant d'une opration d'une gamme de fabrication associe un O.F.. A une tche
 35

correspond donc une charge dtaille pour chaque moyen de production utilis par l'opration.
Le rsultat du calcul de l'ordre est appel dans ce cas, un ordonnancement capacit finie,
puisqu'il est tenu compte des limites de la capacit de chaque moyen.

La constitution du programme de production ncessite galement le choix des O.F. raliser.

Ce choix est appel le lancement. ll dpend principalement du suivi de production, c'est--dire
de l'tat de la production tout instant connu comme, par exemple, la disponibilit des moyens
de production, l'tat d'avancement des O.F. dj lancs, etc.

Ainsi, la constitution du programme de production dans la mthode M.R.P. TI a un caractre

plus heuristique que mthodique. Les causes majeures en sont:

- la mauvaise qualit du systme d'information mis en place: le volume, la localisation, la

cohrence et la communication de l'information rendent difficile la mise jour du
programme de production.

- le caractre volutif du programme de production. Les alas de fabrication provoquent

sans cesse sa ractualisation. Cependant le temps imparti pour calculer nouveau ce
programme empche souvent sa mise jour. La technique de l'ordonnancement,
lorsqu'elle existe, a donc ici un rle important jouer.

m.t.S Conclusion sur la Mthode M.R.P.

La mthode M.R.P. TI peut tre qualifie de mthode de planification. En effet, elle ne traite
que les niveaux long et moyen termes et ignore la gestion du court terme, alors qu'il est difficile
d'appliquer des stratgies de gestion, mme trs labores, un systme si on n'tudie pas
l'application de ces stratgies et les ractions du systme dans le court terme. Ceci ne veut pas
dire que M.R.P. est abandonner, d'autant plus que la majorit des logiciels de gestion de
production actuels sont bass sur cette mthode, mais complter pour couvrir efficacement le
court terme. En tout tat de cause, il est difficile d'ignorer la spcificit de la production dans
l'entreprise, lorsque l'on cherche la grer. Une approche possible pour apprhender est de
considrer certaines proprits de la production et en tenir en compte dans la mthode de
gestion. La mthode juste--temps propose dans la section suivante suit cette approche.
 36

ill.2 La Mthode Juste-A-Temps (J.A.T.) et la Mthode Kanban

m.2.1 La Mthode Juste-A-Temps

Le juste--temps est une logique de production. Utiliser le juste--temps c'est acheter ou

produire juste ce qu'il faut la date exacte du besoin. Le but principal du juste--temps est la
rduction des cots et non pas l'optimisation de l'utilisation des moyens de production. La
rduction des cots est obtenue par la rduction des stocks elle mme rsultat d'une bonne
synchronisation entre la demande et la production. En effet, la production d'un produit ou d'un
composant est dclenche par la demande (production flux tirs) et non plus partir de
prvisions (production flux pousss) comme c'tait le cas pour la mthode MRP.

Le concept juste--temps est l'origine du concept de "flux tendu". D est li trs troitement
aux dmarches de "qualit totale" et d"' amlioration permanente". Le concept de flux tendu
rsulte des concepts des cinq zros (figure 1-4 [MILLE 93]): zro dfaut, zro panne, zro
campagne de production, zro stock et zro dlai. Les deux premiers zros essaient d'liminer
tous les alas de production et le troisime de supprimer tous les processus de production en
campagnes (secondaires). Ce n'est qu'aprs avoir atteint ces trois zros que le juste--temps
pourra tre mis en oeuvre pour conduire les deux derniers zros: zro gaspillage et zro stock.

:>IZro GaJgillaill
Productivit

Figure 1-4 Des Cinq Zros au Flux Tendu

En effet, le juste--temps ne remet pas en cause l'organisation traditionnelle qes systmes de

programmation qui, sur la base d'hypothses moyennes concernant les temps de cycle de
production, les taux de pannes des moyens de production, les rebuts et retouches, calculent des
programmes excuter chaque jour et dans chaque quipe... En consquence, des suivis de
production sont ncessaires pour comparer les ralisations par rapport la thorie. L
 37

commencent les diffrences. ll va falloir grer une organisation d'atelier o les hommes vont
courir aprs les carts, le plus souvent sans utilit relle. La principale diffrence entre la
mthode M.R.P. et la mthode juste--temps est rsume sur le tableau 1-1.

Dans le cas de M.R.P., on court aprs les carts, on les constate et on les actualise a posteriori
lorsque le programme est respect, l'cart est pay dans les cots d'exploitation de l'atelier. On
subit une augmentation des cots non prvus, c'est la fatalit des carts, et on rflchit.

Dans le deuxime cas, on va scuriser et surveiller a priori le fonctionnement par rapport au

rfrentiel: taux de pannes, rebuts-retouches, temps cycles techniques, etc. ll en rsultera une
rduction des cots non prvus et un refus de la fatalit de dysfonctionnements durables.

LOGIQUE M.R.P. LOGIQUE JUSTE-A-TEMPS

- calculs d'ordres "moyens" - gnration des ordres par flux physiques et
commandes
-course permanente entre "ralis" et -pas de course entre "ralis" et "prvu":
"prvu" visibilit permanente l'atelier
- les variations de programme sont amplifies - lissage des variations quantitatives
par des ajustements de stocks
- les ajustements de stocks gnrent des - lissage des fluctuations perturbatrices
fluctuations perturbatrices sur plusieurs ultrieures
priodes
~ ~
CALCULSCOUTEUX CALCULS REDUITS et
et GASPILLAGES SUPPRESSION DES GASPILLAGES
On constate A POSTERIORI les carts et On surveille A PRIORI le fonctionnement
on actualise les donnes par rapport au rfrentiel
~ ~
DYSFONCTIONNEMENT et SURVEILLANCE et
ACTION CURATIVE ACTION PREVENTIVE
Rduction des cots "non prvus" signifie la Rduction des cots "non prvus" signifie le
fatalit des carts que l'on se justifie et l'on refus de la fatalit que l'on scurise et l'on
rflchit surveille

Tableau 1-1 Comparaison des Mthodes M.R.P. et Juste-A-Temps

 38

ID.2.2 La Mthode Kanban

La mthode Kanban (Kanban veut dire tiquette en japonais) est gnralement confondue avec
la logique juste--temps. Le juste--temps concerne tous les chelons de l'entreprise, c'est une
chasse au gaspillage [BERANGER 87] alors que le Kanban est une mthode de gestion des
flux uniquement issue de la logique juste--temps.

Un Kanban est un ordre de fabrication implicite correspondant une opration:

- dfinie du processus de fabrication, pour une rfrence prcise du produit;

- effectue sur un poste de travail dtermin;
- pour une quantit de pices fixe, contenue gnralement dans un conteneur.

Outre les Kanbans de fabrication qui circulent entre les centres de fabrication et l'aire de
stockage situ en aval de ce centre, les Kanbans de transfert sont des tiquettes qui circulent
entre l'aire de stockage et les centres demandeurs (figure 1-5).

KANBAN monocarte
Flux physique
Stock aval
Poste 1
DDD ~ ~ooo
Poste2

1
KANBAN de fabrication

KANBAN double fiches

Aire de stockage

D
Poste 1
D Stock aval
Pos2l
DDD D ~~DO 1

KANBAN de fabrication KANBAN de transfert

Figure 1-5 Mthode Kanban

La mthode Kanban a pour effet d'assurer une circulation de l'information de l'aval vers
l'amont. Les mises en oeuvre de fabrication en amont se trouvent pilotes par les fabrications
 39

relles de l'aval. Le flux de production se trouve plus ou moins tendu suivant le nombre de
Kanbans prsents dans le systme. En effet, puisque aucun conteneur ne peut tre produit en
l'absence de Kanban, le nombre de conteneurs d'une rfrence en attente un poste ne peut
dpasser le nombre de Kanbans. Le volume du flux est .donc rgularis par le nombre de
Kanbans. En diminuant le nombre de Kanbans, on diminue automatiquement le niveau des en-
cours de la rfrence.

En rsum, la mthode Kanban vise en priorit augmenter la ractivit (flux tendu) du

systme de production de la manire suivante:

- la circulation simplifie du flux matire est obtenue par une rimplanttion des moyens de
production (i.e. lot de fabrication, cellule flexible). Cette implantation suppose une
bonne standardisation des produits, et plus gnralement une application de la
technologie de groupe.

- le faible dbit du flux matire est obtenu par la rduction de la taille des lots de
fabrication, et la livraison des matires premires et composants en quantits variables et
juste--temps. Ceci suppose une forte adaptabilit des lments qui concourent la
production, sous-traitants, fournisseurs inclus.

- l'homognit de la nature du flux matire est obtenue par la standardisation des produits
et leurs fabrications en grande srie. La mthode Kanban encourage la rduction de la
taille des lots en supposant une forte adaptabilit des moyens de production: rglages
rapides, changements rapides d'outillages, polyvalence, etc.

- le suivi et le pilotage de la production sont dcentraliss et simplifis. Les flux

d'information qui assurent la rgulation du flux matire sont constitus des Kanbans.

ll.2.3 Conclusion sur la Mthode Juste-A-Temps et la Mthode Kanban

Les rsultats obtenus par la mthode juste--temps et par la mthode Kanban sont toujours
particulirement spectaculaires et rapides [MILLE 93]:

- Suppression des systmes de calculs de programmes court terme et de toute

l'organisation qui distnbue les programmes et court aprs les carts quotidiens et leurs
justifications.

- Suppression des perturbations par une meilleure utilisation des moyens industriels.
 40

- Rduction des stocks et en-cours par la gestion des priorits de ralisation ou rgles de
pilotages (et non plus des quantits-dates).

- Amlioration de la visibilit dans l'atelier des ordres raliser, ce qui va accrotre la

ractivit de l'organisation face aux problmes rencontrs (Les ordres n'iront plus se
perdre sur des tats informatiques dans des bureaux).

- Rduction drastique et rapide des anomalies de fonctionnement de l'atelier et une

amlioration permanente de la qualit du fonctionnement du systme (qualit totale).

Cependant, les conditions d'utilisation de cette mthode font qu'elle ne peut tre applique
tous les systmes de production. Une bonne circulation du flux ncessite une organisation du
systme par lignes de produits et une demande suffisamment rgulire. Puisque la mthode
dclenche la fabrication sur la base de consommations passes (historiques). Cela implique une
consommation rgulire et connue. Sinon, la constitution ou l'accroissement de stocks de
scurit serait ncessaire, d'o une perte de l'intrt de la mthode [WALDNER 90].

ffi.3 La Mthode O.P.T.

La mthode O.P.T. (Optimized Production Technology) est due la socit CREATIVE

OUTPUT fonde principalement par Goldratt. Elle est ne d'une rflexion critique sur de
nouveaux objectifs pour la gestion de production [BENASSY 90]:

- augmenter le produit des ventes, c'est--dire l'argent gnr par les ventes;
- diminuer les dpenses d'exploitation, c'est--dire l'argent dpens pour produire;
- et augmenter la trsorerie, c'est--dire retarder l'engagement d'argent pour produire
(retarder le temps d'achat de matires premires), acclrer le retour sur engagement.

A l'heure actuelle, l'valuation conomique en gestion de production est en pleine mutation. La

mthode 0 .P. T. est une illustration de cette mutation. En effet, si les mthodes de gestion de
production ont volu vers des logiques plus aptes rpondre au nouvel environnement
conomique, elles n'ont peu ou pas chang d'indicateurs conomiques. La plupart des outils
comptables actuellement disponibles ont t mis au point avant 1925 des fins de planification
et de contrle dans de grandes entreprises amricaines [BRODIER 88]. Le calcul des cots des
produits, des cots de production, la comptabilit analytique en gnral, n'ont ainsi pas volu
depuis l'poque du taylorisme o les mthodes de travail taient totalement diffrentes.
 41

Goldratt, l'origine de la mthode O.P.T., et Kaplan spcialiste reconnu de l'valuation

conomique en gestion de production, affirment respectivement que la comptabilit est
l'ennemi numro 1 de la productivit, la comptabilit d'hier sape la production [GIARD 88].

La mthode O.P. T. est pour cela une mthode de gestion de production proposant de
nouveaux indicateurs conomiques. Elle considre en premier lieu que l'laboration d'un plan
de production consiste satisfaire simultanment des contraintes de nature diffrente. Ces
contraintes sont d'ordre technique (la capacit d'un moyen de production par exemple), d'ordre
conomique (la valeur ajoute un produit par exemple) et d'ordre externe (la commande d'un
client par exemple). Cependant, deux ides toffent cette logique:

- Toutes ces contraintes ne sont pas indpendantes parce que les vnements de la
production ne sont eux-mmes pas indpendants. Ainsi par exemple, la contrainte de
capacit d'un moyen de production ne pose pas globalement un problme dans
l'laboration du plan de production, si les vnements de la production montrent que le
moyen de production n'est jamais satur. Satisfaire cette contrainte localement (saturer
le moyen de production en vue de l'employer pleinement) revient augmenter le dbit
matire du moyen de production amont qui l'alimente.

- Une minorit de ces contraintes conditionne l'obtention d'un plan de production

optimis. L'exprience montre que ce sont celles induites par les moyens de production
goulots d'tranglement. On peut dfinir un moyen de production goulot comme un
moyen dont le rapport charge/capacit sur une priode est souvent suprieur 1.

C'est sur la base de ces deux ides fondamentales que l'application de la mthode O.P.T. trouve
un sens. Les principes de cette mthode relativement rcente (noncs en 1979) sont rsums
dans le tableaul-2. Ces rgles ont t trs bien dcrites dans [GOLDRATT 86].

Les rgles 1 et 2 sont parmi les rgles qui allaient l'encontre de l'ide qui tait gnralement
admise et qui consistait considrer que la maximisation des taux d'utilisation de toutes les
ressources est un objectif en soi. La mthode O.P.T diffrencie nettement les ressources
goulots des ressources non-goulots et suggre de maximiser le taux d'utilisation des ressources
goulots seulement. Optimiser les ressources non-goulots conduirait une surproduction et
donc des stocks inutiles. La mthode O.P.T. favorise l'quilibrage du flux matire qui
consiste fixer un dbit du flux matire en respectant les contraintes de capacit de chaque
moyen de production. Car quilibrer la capacit de production court terme est une tche
difficile, voire impossible:
 42

NO Rgles O.P.T. Rgles classiaues

1 Equilibrer les flux, non les capacits Equilibrer les capacits puis essayer
d'Quilibrer les flux
Le niveau d'utilisation d'une ressource non Le niveau d'utilisation d'une ressource est
2 goulot n'est pas dtennin par son propre dtennin par sa propre capacit
potentiel mais par d'autres contraintes du
systme
3 Utilisation et activation d'une ressource Utilisation et activation d'une ressource
sont distinguer sont synonymes
Une heure perdue sur un goulot est une Une heure perdue sur un goulot est
4 heure perdue sur l'ensemble du systme seulement une heure perdue sur cette
ressource
5 Une heure gagne sur une ressource non Une heure gagne sur une ressource est une
goulot ne rapporte rien heure gagne auelle aue soit la ressource
Les goulots dtenninent la fois le dbit Les goulots limitent temporairement le
6 de sortie et le niveau des stocks dbit de sortie mais ont peu d'effet sur les
niveaux des stocks
7 Le lot de transfert peut, et souvent doit, ne n faut viter l'clatement et le
pas tre gal au lot de fabrication chevauchement des lots lancs
8 Les lots de fabrication peuvent varier selon Un lot lanc doit rester entier
les oprations
Les ordonnancements doivent tre faits en Les ordonnancements doivent tre effectus
considrant l'ensemble des contraintes du par la suite d'actions suivantes: 1)
systme. Les temps d'attente sont des dtennination de la taille des lots, 2) calcul
9 variables dynamiques et non des donnes des dlais, 3) dsignation des priorits en
fonction des dlais, 4) ajustement des
ordonnancements successifs aux contraintes
apparentes de capacit
La somme des optimums locaux n'est pas La seule manire d'atteindre un optimum
10 l'optimum global global est de rechercher les optimums
locaux

Tableau 1-2 Comparaison des Rgles de la Mthode O.P.T et Classiques.

- La capacit est sujette aux alas de fabrication, donc est en permanence dstabilise;
 43

- la capacit varie gnralement par valeurs discrtes qui ne rpondent pas ncessairement
avec exactitude aux besoins rels de l'quilibrage;

- la demande varie selon un ordre de grandeur temporel incompatible avec l'intervalle de

variation de la capacit.

Les rgles 4, 5 et 6 signifient que la productivit du systme est dtermine par les ressources
goulots et non pas par toutes les ressources prises indpendamment.

Les rgles 7 et 8 remettent en cause le principe de quantit conomique qui :fixe la mme taille
pour les lots fabriquer et transfrer. Le transfert de quantits plus faibles que celles des lots
de fabrication permet d'acclrer la mise disposition des produits devant les moyens de
production goulots, alors que la taille des lots de fabrication est plus grande pour les moyens
de production goulots afin d'en diminuer les rglages, les changements d'outillages, etc. Cela
n'est pas ncessaire pour un moyen de production non-goulot, car par nature, son niveau
d'utilisation lui assure une certaine disponibilit. Son plein emploi n'est donc pas un objectif
majeur, et son utilisation peut s'accommoder d'une taille de lots de fabrication plus petite. n
faut donc distinguer l'utilisation des ressources non-goulots et le plein emploi des ressources
goulots (rgle 3).

La rgle 9 prconise de prendre en compte les contraintes matires (ordres de fabrication

raliser) et les contraintes de capacits de moyens de production simultanment. Les dlais de
fabrication sont le rsultat d'un programme et ne peuvent donc pas tre prdtermins.

La devise de la mthode 0 .P. T. rsumant ainsi l'ensemble des 9 rgles nonces, est que la
somme des optimums locaux n'est pas l'optimum global du systme (rgle 10).

Conclusion sur la Mthode O.P.T.

La mthode O.P.T. est un systme de gestion par contraintes qui met l'accent sur la prise en
compte simultane de contraintes de natures diffrentes. Les rgles de la mthode 0 .P. T.
paraissent premire vue videntes, pourtant c'est bien souvent le contraire qui est mis en
pratique et mme enseign.

La mthode O.P.T. dpasse le cadre d'une mthode de gestion de prodution classique

puisqu'elle fournit une technique de reprsentation du systme de production. Cette technique,
malheureusement mal connue, consiste dcrire un rseau en y intgrant des contraintes de
 44

toute nature. L'objectif de cette reprsentation est de dissocier les moyenS de production
goulots des non-goulots en vue de l'application des rgles de la mthode.

Le secret qui entoure l'algorithme d'ordonnancement fourni avec la mthode ne permet pas une
comparaison directe avec les autres mthodes. Quant son utilisation en France, elle reste trs
limite. En 1989, on ne dnombrait, d'aprs [BENASSY 90], qu'un seul utilisateur qui en est
d'ailleurs satisfait (mme il n'y a plus maintenant).

ill.4 Conclusion sur les Mthodes de Gestion de Production

La mthode M.R.P. privilgie la gestion des articles dans le temps: les produits finis rsultent
de l'assemblage de composants, fabriqus par l'entreprise ou par des sous-traitants. C'est la
"nomenclature de production". L'atelier est dcompos en postes de charge, c'est--dire, une
ou plusieurs machines qui ralisent le produit selon sa gamme de fabrication dfinissant la suite
des oprations. Cette mthode propose donc de partir de prvisions de production sur les
produits finaux pour calculer les besoins en composants.

La mthode 0 .P. T. remet en cause les approches classiques de gestion de la production.

Fonde sur une planification au plus serr des moyens de production goulots d'tranglement
(anti-flux) et sur une simulation conomique des choix d'ordonnancement rsultants, cette
mthode quilibre les flux de matires et non les capacits de moyens de la production. Son
logiciel, trs cher, reste pour la plupart des spcialistes assez mystrieux et peu utilis dans
l'industrie.

Le concept juste--temps cherche, grce une organisation adapte de la production,

fabriquer et livrer les produits au bon moment. Le systme utilise des fiches Kanban,
plaques sur les flux physiques de production. Trs rpandue au Japon, cette mthode trouve
ses limites dans le cas d'une production en petite srie.

Pour le plus grand bien des utilisateurs potentiels la recherche du moyen idal pour grer leur
production, ces trois approches, souvent mises en concurrence, apparaissent aujourd'hui
complmentaires et convergentes. La mthode M.R.P., par exemple, est base sur une
production hebdomadaire; elle n'est donc pas adapte au contrle de production ( moins
qu'elle soit trs stable, ce qui est rare) ni l'amlioration des flux de produits .sur les lignes de
fabrication. Par contre, le juste--temps s'applique une production quotidienne, voire horaire
par la parfaite synchronisation des diffrentes oprations concernes. Or comme Goldratt l'a
constat [SCHERER 90]: "synchroniser les diffrentes oprations comme le fait le J.AT., ce
n'est pas suffisant: il faut auparavant dtecter et liminer les goulots dans le flux de
 45

production." Selon lui, les chanes de production comportent toujours des maillons faibles. ll
suffit donc de dtecter les faiblesses du systme de production pour l'amliorer. Alors, M.RP .,
J.AT. ou O.P.T., quel systme choisir? Pas facile de dcider, on trouve souvent dans les trois
mthodes le tout et son contraire. n ne faut donc pas I).Otre sens chercher comparer les
logiques et les mthodes, mais chercher une manire de les intgrer. Pour bien russir une
GPAO, il suffit de prendre le meilleur de chaque concept et d'carter l'inutile? Facile--dire...

IV Conclusion

Ce chapitre a eu pour objectif de prsenter en gnral les systmes de production et leur

gestion. Diffrentes dcisions prendre au sein de la gestion sont dcrites et hirarchises. Les
mthodes de gestion de production les plus utilises sont prsentes et analyses.

La prsentation de ces diffrents points a pour but de fixer le cadre gnral de notre travail et
de dcrire les diffrentes approches ou mthodes de modlisation que nous serons amens
utiliser pour construire des modles de simulation. Avant d'aborder les problmes de
modlisation et simulation des systmes de production dans le chapitre ll (un moyen pour
comprendre et matriser la complexit des systmes de production et de sa gestion), on peut
dire qu'il y a deux fortes tendances dans le domaine de la gestion de production: l'intgration
des systmes de production et l'application des concepts d'ingnierie simultane dans la
gestion.

Actuellement, plusieurs auteurs mettent l'accent sur le concept d'intgration ou d'entreprise

communicante et intgre ([COMMI 90], [WALDNER 90]). L'intgration aboutit au
concept d'entreprise globale dans laquelle toutes les fonctions sont couples et interconnectes
sur un mme systme de communication; elle ragit en temps rel (sans dlai, sans inertie); elle
gre de l'information, et les processus de dcision tendent l'optimiser comme un systme
global et non comme une juxtaposition de fonctions autonomes.

Le concept d'entreprise intgre a pour but de procurer l'ensemble des acteurs de l'entreprise
une vision pertinente du systme dans lequel ils voluent: une vision synthtique et globale
pour les dirigeants; une vision spcialise et dtaille pour les personnels oprationnels. Depuis
quelques annes, une dmarche d'ingnierie simultane est prconise. Cette dmarche
consiste intgrer les activits de conception et d'industrialisation des produits en prise en
compte de la maintenance sur la totalit du cycle de vie afin d'amliorer la qualit et la
ractivit dans l'entreprise et de diminuer les cots et les dlais de production, etc. [MORIN et
al. 1993].
 46

L'ingnierie simultane est une approche systmique qui intgre le dveloppement simultan
des produits et des processus associs, incluant la fabrication et le soutien logistique. Cette
approche prend en considration le dmarrage, le cycle de vie du produit depuis sa conception
jusqu' son exploitation, incluant la qualit, les cots, la planification et les besoins utilisateurs.
Cette dmarche, notre sens, va certainement remettre en cause ou modifier les mthodes de
gestion traditionnelles: organisation des systmes de production (squentiel --->
paralllisation), communication entre les partenaires dans l'entrepise (travail en groupe
pluridisciplinaire), tendance du march ou exigences clients (satisfaction du besoin, qualit
globale), dveloppement et innovation du produit (centralisation des donnes techniques), etc.
[BOURDICHON 93].
 Chapitre II Modlisation et Simulation des Systmes de
Production

1 Introduction

Le problme de la modlisation des systmes de production consiste trouver une

correspondance entre le monde rel et un modle informatique. Dans le domaine de la
productique, ce problme est d'autant plus difficile apprhender que les systmes de
production et de gestion reprsenter ne sont pas formels. La complexit et la diversit de ces
systmes rendent d'autant plus difficile la dtermination d'un modle idal.

TI y a trois composants dans le processus de modlisation des systmes de production: le

systme de production, le modlisateur et le modle. Le modle est une reprsentation du
systme conue par le modlisateur pour certains objectifs. Le systme reprsenter est donc
la rfrence du modle. Un modlisateur construit son modle en s'appuyant sur sa perception
partielle de la rfrence et l'aide d'une bote outils (un ensemble de types de modle appel
couramment plus brivement modle) (figure 2-1). Une dfinition descriptive du modle est
donc [EVAN 88]:

Type de Modle

MODELE

Figure 2-1 Modlisation (Reprsentation) du Problme

Un modle est une structuration simplifie qui reprsente censment des caractristiques
et des relations signifiantes de la ralit sous une forme gnralise. Les modles sont des
approximations subjectives de haut niveau qui n'incluent pas toutes les observations ou
 48

mesures associes, mais font apparatre les aspects fondamentaux de l ralit tout en
ignorant certains dtails scondaires.

Le mot "modle" comporte deux aspects essentiels: un modle peut reflter la ralit et prdire
les vnements et les phnomnes rels qui se heurtent nos ides, ou il peut servir comme
une forme (rfrence) idale ou un phnix (parangon) avec lequel nous voulons agir sur la
ralit (figure 2-2) [EVAN 88].

Reflexion ~
Matire ~..<,_________ Concepts
Projection
le monde rel le monde virtuel
Figure 2-2 Vues Idales et Matrialistes des Modles

L'application des techniques de modlisation peut donc tre effectue de deux faons. Nous
pouvons dcrire ou "reflter" un aspect particulier du monde rel; dans ce cas, la modlisation
joue un rle explicatif fondamental dans la comprhension des systmes de production.
Alternativement, nous sommes en prsum d'un genre de modle quand les modlisateurs
essaient de dmontrer comment le monde rel doit tre. La vision artistique et la conviction
politique tombent dans cette catgorie normative de modles. Dans toute modlisation, un
aspect en domine habituellement un autre mais jamais exclusivement. Nous nous proccupons
dans ce travail essentiellement du premier aspect: essayer de modliser les systmes de
production avec des modles et des mthodes adquats.

De nombreux types de modles sont utilisables dans la modlisation des systmes de

production. lls peuvent tre classs de plusieurs faons: ils peuvent tre statiques ou
dynamiques; ils peuvent tre dcrits en fonction des matriaux qui les constituent ou en
fonction de la nature abstraite qu'ils transforment: thoriques ou symboliques, mentaux ou
conceptuels. Les modles physiques peuvent tre iconiques ou analogiques; les modles
mathmatiques peuvent tre dterministes ou stochastiques. La simulation des systmes de
production est un processus ou une technique de modlisation dans lequel le dynamisme de la
ralit, soit actuel soit projet du systme, est imit par un modle stochastique et dterministe.
Diffrents types de modle existent autant dans le domaine informatique que dans le domaine
productique, par exemple, rseau de PETRI [BRAMS 83], modle mathmatique et
GRAFCET [BLANCHARD 79] dans l'automatique, modles SA, SD SADT, SART,
REMORA et MERISE [JAULENT 92] dans l'informatique et la productique, modles IDEF,
 49

GRAI [PIERREVAL 90], OLYMPIOS ([BRAESCH 89], [MAIRE 91]), AMS [MELESE 79]
et modle CIMOSA [AMICE 89] dans la gestion de production, etc.

Pour mettre en oeuvre un modle, on a besoin d'une mthode ou d'une dmarche d'analyse et
de conception de modle. Deux grandes classes de mthodes existent [ROLLAND 86]:

- les mthodes et modles s'appuyant sur une approche fonctionnelle, qui consistent
considrer le systme d'information par les traitements qu'il doit excuter plutt que par
les donnes qu'il doit grer (SADT, IDEFO, GRAI, PETRI, etc.).

- les mthodes s'appuyant sur une dmarche systmique, qui consistent considrer le
systme d'information comme un modle de la ralit organisationnelle (MERISE,
REMORA, OLYMPIOS, AMS, etc.).

II La Mthode SADT

SADT [IGL 89] (Structured Analysis and Design Technique est une mthode ou un langage
pluridisciplinaire de spcification fonctionnelle de systmes. Elle n'est pas proprement parler
une mthode de conception puisqu'elle se limite une spcification d'un systme en ignorant
les aspects lis la ralisation de ce systme. Cette mthode est souvent employe au pralable
la ralisation du schma directeur, pour mieux connatre la situation existante et dgager les
fonctions souhaites du systme concevoir. C'est une mthode gnrale. La varit de ses
domaines d'application en tmoigne: gnie logiciel, productique, systme de gestion,
aronautique, etc.

La mthode SADT fournit plusieurs reprsentations graphiques formalises pour analyser et

comprendre un systme construire:

- le modle SADT du systme existant,

- le modle SADT du systme idal,
- le modle SADT du systme tel qu'il est ralisable,
- le modle SADT du systme futur (tel qu'il sera ralis).

Lors de la ralisation de ces modles, l'accent est port sur la spcification des fonctions que le
systme remplit actuellement (systme existant), devrait remplir (systme idal), serait
effectivement capable de remplir (systme tel qu'il est ralisable) et remplira (systme futur).
Ces fonctions sont dcrites indpendamment de la manire dont elles sont, devraient tre,
pourraient tre ou seront ralises [LIS SANDRE 90].
 50

ll.l Les Concepts de la Mthode

Conue partir de concepts simples et base sur un fonnalisme graphique et textuel facile
apprendre, la mthode SADT permet d'une part de modliser le problme avant de chercher
en exposer une solution et, d'autre part, d'assurer une communication efficace entre les
diffrentes personnes concernes par le systme construire. Sept concepts fondamentaux sont
la base de la mthode SADT [JAULENT 92]:

1. SADT analyse un systme en construisant un modle de celui-ci, dans le but d'en exprimer
une comprhension complte et de la situer dans son contexte, c'est--dire d'en prciser le
sujet. Plusieurs modles exprimant diffrents points de vue (utilisateur, constructeur,
gestionnaire, responsable de maintenance... ) sur le systme peuvent se rvler ncessaires.

2. SADT analyse un systme de manire descendante, modulaire, hirarchique et structure.

3. SADT distingue la description fonctionnelle du systme (quoi faire?), domaine o elle est
particulirement efficace, de la description des diffrentes solutions envisages pour sa
ralisation (comment faire?).

4. SADT privilgie deux aspects dans la modlisation du systme dcrire. Le premier aspect
est relatif aux transformations, fonctions, activits, tches, traitements, etc., qui s'effectuent
n
dans le systme. est pris en compte par SADT dans la notion d'activit. Le second aspect
concerne les objets manipuls par les activits. On parle plus gnralement de donnes dans
la mthode SADT.

5. SADT est bas sur des principes de reprsentation graphique (un langage pluridisciplinaire
semi-formel) destins faciliter la comprhension du systme spcifi. Pour cela, les
modles SADT sont reprsents graphiquement par des boites inter-relies.

6. SADT favorise un travail d'quipe (auteurs, lecteurs, experts) disciplin et coordonn. Elle
permet de mettre en vidence les rsultats qui refltent le mieux la qualit du travail.

7. SADT oblige consigner sous forme crite tous les choix et dcisions faits pendant
l'analyse. Les documents crs sont accessibles tous pour tre revus et corrigs.
 51

11.2 Les Outils de Modlisation

SADT adopte deux types de reprsentations duales (figure 2-3). Dans la premire, les activits
sont reprsentes graphiquement dans un modle par de~ boites, dsignes par des verbes,
ventuellement munies de complments. Les donnes seront, quant elles, reprsentes par
des flches, dsignes par des noms. Les diagrammes obtenus sont appels des actigrammes.
Dans la seconde reprsentation, les botes reprsentent des donnes et les flches des activits.
Les diagrammes obtenus sont des datagrammes. Bien qu'ils permettent d'effectuer des
"rfrences croises" avec les actigrammes, les datagrammes semblent moins utiliss. C'est
pourquoi, par la suite, nous ne nous intresserons qu'aux actigrammes, seuls retenus par la
mthode IDEF. Les datagrammes sont reprsents par des modles MERISE que nous
proposerons dans le prochain paragraphe.

Figure 2-3 Actigramme et Datagramme du Modle SADT

Les entres sont des donnes consommes ou converties par l'activit pour produire des
sorties. Les donnes de contrle expriment les conditions et/ou les circonstances qui
gouvernent, orientent, ou contraignent l'activit. Ce sont, en gnral, soit des donnes qui
dclenchent ou inhibent la transformation, soit des paramtres ou des valeurs de consigne qui
la rgissent. Les donnes mcanismes prcisent la personne, le service, la ressource ou tout
autre lment qui supporte ou effectue la fonction. Ces donnes expriment en gnral le
comment ou le qui.

Un modle SADT est compos d'un ensemble de diagrammes ordonns hirarchiquement. Au

niveau le plus gnral, nous trouvons le diagramme de contexte, de niveau -1 (schma AO dans
 52

la figure 2-4), qui montre les sources et les destinations des diffrentes informations arrivant ou
sortant de la "bote analyser". La bote analyser correspond quant elle, au diagramme de
niveau infrieur not: niveau -0 (schma Al dans la figure 3-26), elle mme dcomposable en
niveau 0, 1, 2... Chacun de ces diagrammes peut tre considr, soit comme un diagramme-
pre, synthse de ses diagrammes-enfants, soit comme un diagramme-enfant, analyse d'une
partie de son diagramme-pre.

oncurrence, Clientle, March

Environnement matriel, Fournisseurs
Contraintes systmes et budgtaires
Librairie des objets du domaine
1 Critres de conception

Modles du domaine .} ~ Modle(s) de simulation

Concevoir un Scnarios de simulation
Description de l'application Systme de
> Production Modles de configuration
Donnes techniques (produits, !Simuler
ressources, or anisation, Modles d'analyse de rsultats
rgles de fonctionnement, ... )
tils et mthodes

Savoir-faire, Expriences
veloppeurs

Figure 2-4 Schma SADT Contexte de Dveloppement

11.3 La Dmarche de Modlisation

Recherchant avant tout la rigueur, la mthode SADT fournit de faon trs dtaille, par
l'intermdiaire de ses concepts, l'ensemble des dmarches ncessaires la mise en pratique
d'une analyse et d'une conception. La dmarche de modlisation permet un ou plusieurs
auteurs de construire le modle d'un systme suivant 7 tapes.

Etape 1: Prparation du modle. Cette tape vise dfinir le sujet, le but et le point de vue
du modle construire.
Etape 2: Construction de la liste de donnes. Dans cette tape, l'auteur collecte le maximum
de donnes sur le sujet du modle. Ces donnes correspondent aux besoins, aux
caractristiques et aux contraintes du sujet du modle.
 53

Etape 3: Construction de la liste d'activits. Pour chaque donne de la liste prcdemment

tablie, l'auteur identifie les activits crant, utilisant ou modifiant cette donne.
L'ensemble des activits obtenu constitue la liste des activits.

Etape 4: Construction du diagramme d'activits.

Etape 5: Vrification de la qualit des diagrammes d'activits. La qualit se juge par son
facteur d'amplification, son respect du point de vue, son but, l'quilibre de ses
niveaux de dtail et sa compltude.

Etape 6: Elaboration de documents complmentaires aux diagrammes d'activits.

Etape 7: Couplage des diagrammes d'activits un modle entit-association.

ll.4 Conclusion sur la Mthode SADT

Malgr quelques lacunes (absence de spcification du point de vue des performances et des
contraintes temporelles, cohrence entre actigrammes et datagrammes douteuse, point de vue
dynamique trs limit...), la mthode dispose de nombreuses qualits telles que:

- sa trs bonne lisibilit grce la clart de ses graphiques,

- le nombre restreint de ces concepts de base, assurant un apprentissage facile,
- son aptitude communiquer dans un langage non "informatique",
- l'organisation de l'quipe qui ralise la modlisation,
- sa structure hirarchique et modulaire du modle obtenu.

La mthode SADT, cre l'origine "pour communiquer des ides" doit tre utilise pour
exprimer des besoins (pas ncessairement informatiques), aborder l'aspect fonctionnel d'un
cahier des charges, communiquer entre les diffrents membres d'une quipe, mais ne peut pas
servir en tant q'une mthode d'analyse fonctionnelle de logiciel (et encore moins pour de
logiciel temps rel), car les rsultats obtenus dpendent plus de la comptence de l'analyste que
de la rigueur de la mthode. Pour cela, des extensions ont t dfinies, d'une part pour lever les
ambiguts qui subsistent au niveau des donnes: un passage au modle entit-association dont
nous parlerons dans la mthode MERISE, d'autre part pour modliser la dynamique d'un
logiciel fortes contraintes temps rel: un passage au modle SART [HATLEY et al. 91] qui
permet l'laboration d'un modle en pensant "rponse des vnements", provenant de
!"'espace action-perception" du systme. Malgr que la mthode SART soit adapte la
spcification fonctionnelle et dynamique de systme, elle est difficile de construire un modle
 54

correspondant. Nous ne prsenterons donc pas la mthode SART, mais la mthode SADT est
bien utilise dans la phase "analyse de l'application" (chapitre ID).

III La Mthode MERISE

La mthode :MERISE s'appuie sur de nombreux principes issus de la systmique. Son objectif
est de fournir la fois une philosophie, une dmarche, des modles, des formalismes et des
normes, pour concevoir et raliser un systme d'information. Cette mthode couvre l'ensemble
des phases du cycle de vie du systme d'information: de l'analyse des besoins jusqu' la
maintenance.

ill.l Les Concepts de la Mthode

Une vision globale

La mthode :MERISE met en vidence la ncessit d'une conception globale du systme

d'information pour viter les problmes lis la redondance des donnes dans l'entreprise,
l'absence de cohrence dans leur mise jour et la difficult de maintenir de faon convenable le
systme d'information. Le systme d'information conu par cette mthode s'inscrit parfaitement
dans le schma de l'approche systmique de l'entreprise [MELESE 79] propose par Le
Moigne [MOIGNE 90]. Ce schma illustre une dcomposition du systme-entreprise en trois
sous-systmes: le systme oprant, le systme de dcision et le systme d'information.

La sparation des donnes et des traitements

La mthode MERISE propose deux reprsentations du systme d'information. L'une, fournie

par les donnes, donne une vision statique du systme-entreprise. L'autre, fournie par les
traitements sur ces donnes, donne une vision dynamique de ce systme. Cette distinction entre
les aspects statique et dynamique doit permettre entre autres une meilleure adaptation du
systme d'information lors de l'volution des besoins [PIERREVAL 90].

Une approche par niveaux

La mthode 'MERISE met en vidence trois mveaux dans la conception du systme

d'information: niveau conceptuel, niveau organisationnel et niveau technique. Ces trois niveaux
sont successivement abords aussi bien dans la description des donnes que dans celle des
traitements.
 55

ill.2 Les Outils de Modlisation

La mthode :MERISE fournit six modles (tableau 2-1) permettant de reprsenter les donnes
et les traitements sur les trois niveaux d'abstractions.

NIVEAUX MODELES
DONNEES TRAITE:MENTS
Niveau Conceptuel Conceptuel MCD Conceptuel MCT
Niveau Organisationnel Logique MLD Organisationnel MLT
Niveau Physique Physique MPD Oprationnel MPT

Tableau 2-1 Modles de la Mthode :MERISE

Le niveau conceptuel permet la description des finalits de l'entreprise (objectifs gnraux et

contraintes). TI apporte la rponse la question "quoi?" (aspect fonctionnel) et reprsente le
niveau le plus stable du systme-entreprise.

Le niveau organisationnel rpond aux questions "qui, o et quand?". TI dcrit la structure

mettre en place pour satisfaire les objectifs dcrits au niveau prcdent, et reprsente un
deuxime niveau de variabilit du systme.

Le niveau technique dfinit les moyens techniques mettre en oeuvre pour raliser le systme
d'information. TI rpond la question "comment?". Parce qu'il subit les volutions :frquentes
des matriels et logiciels, il correspond au niveau le moins stable du systme-entreprise.

La mthode :MERISE possde diffrents outils pour la construction des modles. Le

formalisme le plus utilis est le type entit-association. Dcrit avec ce formalisme, les modles
se composent d'entits (ou classes d'entits) qui caractrisent un certain type d'objets (que l'on
appelle aussi: individus, lments ou constituants de la base de donnes). Les entits sont
repres par leurs identiflants. Elles possdent un certain nombre de proprits. Une proprit
est une donne lmentaire (un attribut en terme d'objet) dcrivant l'entit.

Les entits sont relies par des relations. Les relations peuvent tre binaires ou n-aires selon
qu'elles relient deux ou plusieurs entits. TI existe des relations internes une mme classe
d'entit. Des cardinalits sont associes aux relations. On les dfinit comine le nombre
d'occurrences de la relation pouvant exister pour une occurrence de l'objet (nombre minimum
et maximum d'occurrences). Figure 2-6 illustre un modle entit-association tendu de
traitement de commande selon la logique gestion par prvision.
 56

CLIENT ~~command par PRODUIT PRODUIT

............ EN STOCK _.....est un FABRIQUE
......
Client ID
Nom ![\ >> Produit ID
......
/ Identificateur
Addresse a command Prix de vente est un Fabriquant
Quantit en stock Prix de fabrication
Quantit prvisionnen Cycle defabrication
Dlai de livraison
~~
COMMANDE ~... ~a. fabrique

Identificateur
Client ID PRODUIT est fabrique~~
Produit ID Idenficateur
Quantit Nom de produit FABRIQUANT
Prix d'achat Nomenclature
Date de commande Identificateur
Dlai d'obtention Nom
Addresse

Figure 2-6 Modle Entit-Association de Traitement de Commande

ID.3 La Dmarche de la Modlisation

La dmarche est base la fois sur le cycle de vie des systmes, les niveaux d'abstractions et le
cycle des dcisions qui doivent tre prises. Elle peut tre illustre par le schma de la figure
suivante (figure 2-7).

Le schma directeur couvre l'ensemble de l'organisme du systme-entreprise. Son objectif est

la planification moyen terme du systme d'information. A l'issue du schma directeur
oprationnel, le champ d'investigation a t dcoup en domaines cohrents.

L'tude pralable doit donner aux responsables des lments pour dcider. Pour cela, elle doit
notamment permettre d'valuer: la faisabilit fonctionnelle et technique du systme, la
cohrence du planning et du budget de dveloppement et de mise en place, ainsi que les cots
prvisionnels. L'tude pralable droule le cycle d'abstraction sur les trois niveaux (conceptuel,
organisationnel et physique).

L'tude dtaille permet de spcifier de faon dtaille et exhaustive la solution conceptuelle et

organisationnelle retenue l'issue de l'tude pralable. D'autre part, l'tude dtaille complte
et valide la solution technique globale. Elle gnre un dossier de spcifications fonctionnelles
comportant: les vnements et rsultats traits, les processus de gestion mis en jeu, les
procdures de traitement associes et les tches.
 57

L'tude technique est l'tape o l'on passe des spcifications dtailles et des contraintes qui
constituent une expression de besoins, la dfinition d'une solution en tennes de traitements au
niveau oprationnel et de donnes au niveau physique.

La ralisation couvre la production des logiciels et la mise en oeuvre; elle pennet d'tudier
l'ensemble des problmes lis l'utilisation efficace de nouvelles fonctions automatises.

dossier de choix

description
2ime
application

Figure 2-7 Dmarche par Etapes de la Mthode :MERISE

ffi.4 Conclusion sur la Mthode MERISE

La mthode :MERISE est une dmarche structure qui s'applique la conception de systmes
d'infonnation. Cette dmarche s'appuie sur des modles de donnes et de traitements qui
s'affinent au fur et mesure de la progression du projet, partant de modles conceptuels, pour
aboutir, par l'intenndiaire de modles logiques et organisationnels, aux modles physiques
selon la ralisation des programmes et la mise en place des bases de donnes entreprises.
 58

Par rapport la mthode SADT, MERISE est une mthode cohrente et assez complte. D est
vrai qu'elles ont plus de similitudes que de diffrences [QUANG 89], les plus importantes de
ces diffrences sont les suivantes:

- La mthode SADT est avant tout une mthode d'analyse plutt que de traitement, ce qui
s'explique par la prsence prdominante des actigranunes. Le tableau 2-2 montre les
diffrents niveaux de traitements de SADT et de MERISE.

- La mthode de dcomposition est diffrente: dans la mthode SADT, le choix et le

nombre des diffrents niveaux d'abstraction sont du ressort de l'utilisateur; par contre la
mthode MERISE intgre les diffrents niveaux d'abstraction et les fige.

- La mthode SADT est particulirement bien adapte aux tapes de spcification

prliminaire et dtaille d'un systme; la mthode MERISE privilgie un dcoupage sur les
diffrentes catgories de dcideurs (direction gnrale, utilisateurs, organisateurs,
informaticiens, etc.).

~ .
n
SADT MERISE

CONCEPrUEL LOGIQUE CONCEPI'UEL

LOGIQUE ORGAJITSATIONNEL
PHYSIQUE
PHYSIQUE PHYSIQUE

Tableau 2-2 Les Niveaux de Traitements des Mthodes MERISE et SADT

- La mthode SADT est une mthode pour communiquer des ides qui ne ncessite aucune
connaissance informatique. Elle est facile lire et comprendre. La mthode MERISE est
une mthode informatique. Elle est beaucoup plus complexe que la mthode SADT.

La mthode MERISE a t constanunent amliore au cours de ses dix annes d'existence: la

reprsentativit des modles s'est affine (vers les modles objets [ROCHELD 93]) et les
domaines d'emploi se sont tendus vers [PIERREVAL 90]: les systmes de gestion de
production, les systmes de communication, la planification et le suivi des projets et l'tude
 59

technique. TI existe quand mme des limites ces extensions dans l'informatique caractre
technique [TARDIEU 89].

- Le cycle de vie des systmes est diffrent en informatique de gestion et en informatique

technique.

- Les modles de traitements et de flux d'information de l'informatique de gestion sont

inadapts la reprsentation des traitements hautement parallles que l'on trouve en
informatique technique.

- La conception en informatique de gestion dbouche sur des environnements base de

donnes et/ou base de connaissances qui ne sont pas ceux que l'on rencontre en
informatique technique.

Une approche nouvelle est donc ncessaire pour aborder correctement le domaine de
l'informatique technique. En ce qui concerne les systmes de production, deux modles
(mthodes) mritent d'tre prsents dans la section suivante: modles GRAI et CIMOSA.

IV Les Mthodes GRAI et CIMOSA

Pendant trs longtemps, l'automatisation des systmes de gestion de production s'est faite sur
le modle des mthodes informatiques (SADT, MERISE, SA/SD) ou de certains modles de
rseaux (rseau de Ptri, rseaux de files d'attente) dcrivant le systme physique de
production. Or un systme de gestion de production comprend trois sous-systmes: un sous-
systme physique, un sous-systme d'information et un sous-systme de dcision. De par leur
nature et leur diversit, ces systmes relvent d la plus grande complexit [MOIGNE 90].

Comprendre le fonctionnement des systmes du monde rel ncessite des mthodes et outils
appropris. L'insuffisance des mthodes informatiques "pour traiter" le systme de gestion de
production dans sa totalit a contribu au dveloppement de mthodes et outils d'analyse
propres la gestion de production [ADAMA 84]. La figure 2-8 montre la spcificit des
principales mthodes d'analyse/conception, par rapport au systme de gestion de production et
ses sous-systmes. Nous ne prsentons ici que deux mthodes qui sont, notre connaissance,
les plus utilises en France: la mthode GRAI et la mthode CIMOSA.
 60

SYSTEME D'INFORMATION SYSTEME DE DECISION

YOURDAN (SA/SD)
ora SADT ~IDEFRiodle Analytique
IDEFl T IDEF2
GRAI
MERISE

CORIG

Modle Analytique
SYSTEME PHYSIQUE

Figure 2-8 Les Mthodes d'Analyse par Rapport au Systme de Gestion de Production

IV.l La Mthode GRAI

La mthode GRAI (Graphes Rsultats et Activits Inter-relis) [ADAMA 84] s'appuie sur
deux descriptions conceptuelles du systme de gestion de production (SGP), labores partir
des thories sur les systmes hirarchiss et des systmes d'organisation. Cette mthode
comprend:

- un modle conceptuel global labor d'une part partir des thories des systmes
d'organisation et d'autre part partir des systmes hirarchiss.

-un modle conceptuel du centre de dcision qui est une approche "micro" du modle
conceptuel global.

- deux outils de reprsentation graphique des deux modles: la grille et les rseaux GRAf.

Le modle conceptuel du systme de gestion de production (figure 2-9) exprime la

dcomposition des systmes de production, introduite plus haut, en trois composantes: le sous-
systme physique, le sous-systme d'information et le sous-systme de dcision. Le systme de
gestion de production se dfinit comme la runion du systme de dcision et du systme
d'information.

Le modle conceptuel du centre de dcision exprime plus explicitement le mcanisme de

fonctionnement d'un centre de dcision. Un centre de dcision (figure 2-10) est un ensemble
 61

d'activits de dcision (ou activits dcisionnelles) que l'on isole des autres activits partir
des critres suivants.

SYSTEME MODELE CONCEPTUEL

DU SYSTEME DE
L-----..--_)n:~~rr,rnli.T DE PRODUCTION

Produit

Figure 2-9 Modle Conceptuel Global du Systme de Gestion de Production (SGP)

- Les critres fonctionnels qui permettent de distinguer les activits selon les fonctions de
base auxquelles elles appartiennent. Le plus souvent ces fonctions sont: planifier,
approvisionner, grer les ressources, fabriquer, contrler et livrer.

- Les critres temporels exprims en termes d'horizon de temps concern par une prise de
dcision et de priode relative l'intervalle de temps sparant la remise en cause des
dcisions. Ces critres permettent de placer les activits, et donc les centres de dcision,
sur des niveaux de dision caractriss par un couple (horizon, priode).

La mthode GRAI dispose de deux outils graphiques pour reprsenter les deux modles
prcdents: la grille et le rseau GRAI. La grille GRAf se prsente comme un tableau dont:

- les colonnes sont les fonctions lmentaires du systme de gestion de production,

- les lignes, les diffrents horizons de prise de dcision; chaque horizon tant associ une
priode de remise en cause de la dcision.
 62

SYSTEME DE DECISION
SYSTEME
D'INFORMATION CADRE DE DECI~ION
ce qu'il faut faire
sur quoi il est possible d'agir
et jusqu'o et comment agir (dans quelles limites)

AGREfTION DEMANDER
un AJUSTAGE

DONNEES
TECHNIQUES

ADr MODELES

RESULTA: CADRE
ATTEim---+---~ DE
DECISION

AGREGATION

Figure 2-10 Modle Conceptuel d'un Centre de Dcision

Cette dcomposition en fonctions et niveaux de dcision dfinit une matrice, reprsente

graphiquement par une grille dont les cases sont les centres de dcision. La grille couvre la
totalit de la structure du systme sans entrer dans le dtail, pour cela on peut considrer que
la grille constitue une macro-modlisation du systme de gestion de production (SGP).

Chaque centre de dcision, dtermin par la grille, peut tre analys par les rseaux GRAf,
activit par activit. Deux types d'activits sont reprsents dans les rseaux: les activits
d'excution et les activits de dcision.
 63

-En phase d'analyse, ces rseaux expriment les activits excutes dans le SGP, et servent
lever l'ambigut sur l'excution de certaines tches ou sur les mcanismes de prise de
dcision. lls permettent d'tudier la synchronisation des activits et le fonctionnement du
systme en rgime perturb. Cette tude s'effectue. au niveau mme d'un centre de
dcision, mais elle concerne galement les relations entre diffrents centres.

- En phase de conception, les macro-GRAI permettent une meilleure comprhension de

l'architecture propose par la grille de conception. Notamment pour la description du
contenu des liens dcisionnels. Les rseaux permettent de dfinir les spcifications
fonctionnelles du systme raliser qui serviront, entre autres, l'laboration du cahier des
charges de nouveaux systmes et ventuellement la recherche d'un progiciel de GPAO.

La mthode GRAI fournit galement une dmarche d'application en permettant diffrents

intervenants d'y participer. La figure 2-11 schmatise la mthodologie d'application. Bien que
la mthode fournisse des outils d'aide, l'exprience d'un spcialiste reste prpondrante
[PIERREVAL 90]. Cette dernire est ncessaire la fois pour la pratique de la mthode GRAI
(notamment pour la construction des grilles et des rseaux) et pour les connaissances en
gestion de production qui restent indispensables lors des phases d'expression de
dysfonctionnements et de conception.

INITIALISATION

..}
ANALYSE DE
L'EXISTANT CONTEXTE ET
Analyse descendante OBJECTIFS DU
Analyse ascendante
Bilan de l'analyse FUTUR SYSTEME
./
~
'
CONCEPTION DU
FUTUR SYSTEME
Initialisation ,..... PLAN DE MISE EN OEUVRE
Conception globale CAHIER DES CHARGES
Conception dtaille
Synthse de la conception

Figure 2-11 Mthodologie d'Application de la Mthode GRAI

Des extensions de la mthode sont en cours [DOUMEING et al. 90]: l'intgration de

l'valuation conomique (mthode ECO-GRAI), la dfinition d'approches mthodologiques du
 64

systme physique et la dfinition de "modles de rfrences" destins faciliter le diagnostic et

la conception (modle NBS). Bass sur cette mthode, diffrents projets europens sont en-
cours [DOUMEING 91]: l'architecture :MMCS (Manufacturing Management Control System),
l'architecture GIM (GRAI Integrated Method), le projet IMPACS (lntegrated Manufacturing
Planning And Control System), etc. Nous prsentons ici une mthode europenne: la mthode
CIMOSA qui est une architecture de systme ouvert pour la productique.

IV.2 La Mthode CIMOSA

CIMOSA (Open Systems Architecture for Computer Integrated Manufacturing) est une
architecture de systmes ouverts pour la productique dveloppe par le Consortium AMICE
dans le cadre du programme ESPRIT (Projets No. 688, 5288 et 7110). L'architecture est
articule autour de trois composants fondamentaux (figure 2-12) [AMICE 89].

Cycle de Vie d'un Systme CIMOSA

Expression des Besoins, Conception, Description 1
Opration
de l'Implantation, Installation, Maintenance

~ Cycle de Vie
ff de
l'Implantation des Produits
Analyse de March/
/ ~ Installation
des Besoins

Cration Conception/
Dveloppement

Architecture de Modle Particulier Mise en Production

Rfrence CIMOSA de l'Entreprise
Production
Infrastructure Intgrante de CIMOSA
Distribution/
Ressources en ReBBOurc:es Ressources Ventes

t -. ,_ . _ . - " ---
Ingnierie Ncessaires Oprationnelles

Utilisation
.....__,_--YI bd kd-9-- Maintenance/
Service Aprs-Vente

Environnement d'Ingnierie Environnement

de l'Entreprise Oprationnel

Figure 2-12 L'Architecture CIMOSA

 65

- Un cadre de modlisation d'entreprise (incluant une Architecture de Rfrence qui

fournit une intgration conceptuelle par unification smantique);

- Une infrastructure intgrante (permettant l'intgration physique et l'intgration des

applications);

- Un cadre mthodologique (couvrant le cycle de vie du systme de production et

assurant la cohrence de l'ensemble).

IV.2.1 Le Cadre de Modlisation de CIMOSA

Le but du cadre de modlisation de CIMOSA ou du cube CIMOSA (en anglais, Modeling

Framework) est de fournir un cadre conceptue~ une mthode et des outils de modlisation
pour assister l'utilisateur dans le dveloppement du modle particulier de son entreprise. Ce
cadre est donc compos de deux parties essentielles (figure 2-13): l'une appele Architecture
de Rfrence (fournie par AMICE) et une autre appele Architecture Particulire (propre
l'entreprise). Ce cadre s'articule autour de trois axes de modlisation orthogonaux:

- l'axe de gnricit qui suggre de construire le modle particulier de l'entreprise partir

de modles partiels, s'il en existe, eux-mmes exprims en termes de concepts de base
gnriques (Generic Building Blocks) ou de leurs types et sous-types. Les concepts de
base gnriques et les types de concepts de base (Building Block Types) forment le
"langage de modlisation de CIMOSA". Seul le Consortium AMICE ou les organes de
normalisation sont susceptibles de modifier ou enrichir ce langage;

- l'axe des modles qui invite modliser d'abord les besoins prcis de l'entreprise
(dfinition des objectifs, laboration du cahier des charges), puis concevoir les
spcifications du systme CIM (analyse conceptuelle, analyse dtaille, conception du
systme d'information, valuation des performances, choix des ressources) et enfin
dcrire l'implantation (ressources installes, distribution des fonctions, distribution des
informations, gestion des alas, etc.);

- l'axe des vues qui propose de grer le modle intgr (conception, manipulation, accs)
suivant quatre points de vue (fonctions, informations, ressources et orgnisation) pour
faire face la complexit du systme et de son modle.
 66

Niveau Niveau Niveau

Gnrique Partiel Particulier
Gnration par Etapes
;f Vue Vue Vue
_ _ _~rl!~~~O,!l _ _ _ _ _ _ QIJS,!li,!lllP,~n_ _ _ _0_rg8JlII11;Ot,l _ _
, Particularisation
~----)!>- Vue des Vue des Vue des
Ressources Ressources Ressources
Vue des
_ _ _IDJ"o~o_nl! _ _
v Dduction Fonctions Vue des Vue des Vue des
Fonctions Fonctions Fonctions

Concepts de Base Modles Modle

Niveau de Modlisation de Gnriques Partiels Particulier
l'Expression des Besoins Expression Expression Expression
des Besoins des Besoins des Besoins

Concepts de Base Modles Modle

Niveau de Modlisation des
Spcifications de Conception Gnriques Partiels Particulier
Spcifications Spcifications Spcifications
de Conception de Conception de Conception
Concepts de Base Modles Modle
Niveau de Modlisation de 1a Gnriques Partiels Particulier
Description de l'Implantation Description de Description de Description de
l'Implantation l'Implantation l'Implantation

, - - - - - - - - - J ''-------, ,..------'(
Architecture de Rfrence
v
Architecture Particulire

Figure 2-13 Le Cadre de Modlisation de CIMOSA

Du point de vue fonctionnel, une entreprise est vue dans CIMOSA comme un ensemble de..
domaines (parties disjointes de l'entreprise) forms de processus qui interagissent entre eux
(traitement des commandes-clients, planification de la production, traitement de nomenclature,
etc.). Ces processus d'entreprise sont dclenchs par des vnements provenant du modle lui-
mme ou du monde extrieur (pannes de machines, ordres de gestion, etc.). Un processus est
form de sous-processus et d'activits. C'est en fait une chane d'activits spcifie au moyen
de rgles procdurales qui dcrivent le comportement de l'entreprise en fonction des
vnements reus et de l'tat du systme. Une activit (figure 2-14) dcrit une tche ralise
dans l'entreprise au moyen de ressources (entre ressource) au cours du temps et consistant
transformer des intrants (entre fonctionnelle) en extrants (sortie fonctionnelle) sous certaines
contraintes (entre de contrle) et produisant des informations de sortie (sortie de contrle et
sortie ressource). Les activits dcrivent la fonctionnalit de l'entreprise. Une activit consiste
excuter une squence d'oprations suivant une logique donne. Les oprations reprsentent le
plus bas niveau de granularit dans la vue des fonctions. Toute activit produit en sortie un tat
de fin indiquant comment s'est termine l'activit. Cet tat de fin est utilis par les rgles
procdurales des processus pour enchaner les activits au cours du temps.
 67

Activit
Entre Fonctionnelle Sortie Fonctionnelle
Entre de Sortie de
Ressource Ressource

Figure 2-14 Diagramme de l'Activit

Du point de vue informationnel, la plupart des entres/sorties des activits sont des vues
d'objet. Une vue d'objet est une manifestation d'un objet tel qu'il est peru par un utilisateur ou
une application. Elle peut tre de nature physique ou de nature informationnelle. Dans le cas de
vue d'objet de nature informationnelle, la vue d'objet est dfinie par un nom et un type de
donnes (types de base usuels en informatique). Derrire la description des vues d'objets se
cache un objet d'entreprise qui est une reprsentation abstraite (ou informatique) d'une entit
relle de l'entreprise et qui est dfinie par tous les lments d'information relatifs cet objet
complexe de l'entreprise (fait d'autres objets) dont on peut produire des contraintes de copies
(ou occurrences) mais dont on ne peroit que des vues d'objet.

Du point de vue de la gestion des ressources, les activits ont besoin de ressources pour leur
excution. CIM:OSA distingue deux classes de ressources: les ressources actives, appeles
entits fonctionnelles et les ressources passives (outils, palettes, etc.), appeles composants.
Les entits fonctionnelles jouent un rle important dans un systme CIM car ce sont celles qui
excutent les oprations des activits de la vue des fonctions. On distingue dans CIMOSA trois
grandes classes d'entits fonctionnelles: les machines (machines outils, systmes de transport,
robots, etc.), les applications (systmes de CAO, de M.R.P., logiciels d'ordonnancement, etc.)
et les hommes (oprateurs, dcideurs, gestionnaires, concepteurs... ). Ces entits fonctionnelles
sont connectes l'architecture par les services de prsentation de l'infrastructure intgrante.

Du point de vue organisationnel, CIMOSA fournit des concepts de base gnriques pour
dcrire les responsabilits dans l'entreprise, les niveaux organisationnels (unit d'organisation
et cellule d'organisation) et les cadres de dcision.

IV.2.2 L'Infrastructure Intgrante de CIMOSA

L'infrastructure intgrante de CIMOSA (en anglais Integrating Infrastructure ou US) est

constitue de cinq grands groupes de services, appels entits (figure 2-15). Leur but est de
fournir un ensemble commun de services informatiques de base rpartis formant une plate-
 68

forme d'intgration unifie pour les diffrents composants du systme CIM (fonctions, centres
d'informations, ressources et entits d'organisation) et devant servir de support l'excution
des activits de l'entreprise. En d'autres termes, l'US vise transformer un environnement
htrogne en un environnement homogne et donc plus facilement grable.

Entit des Entit des Entit des Entit des

Services de Services Services Services
Gestion du Systme d'Information de Prsentation d'Excution

Entit des Services Communs

1 1

Service des Technologies de l'Information (Systmes d'Exploitation, Rseaux, etc.) 1

1

Figure 2-15 Services de l'Infrastructure Intgrante

IV.2.3 La Mthodologie de Dveloppement

CIMOSA o:ffie une mthodologie d'intervention en accompagnment du cycle de vie du

systme CIM. Les phases du cycle de vie du systme sont illustres dans la figure 2-16. est n
apparu dans le projet AMICE que ce ne sont pas les trois premires phases qui sont les plus
difficiles raliser comme on aurait pu le croire, mais la phase de maintenance/modification.
On peut toujours raliser un systme base de technologie de l'information d'une faon ou
d'une autre, mais changer dynamiquement un tel modle en cours d'exploitation reste un
problme entier pour lequel il n'y a pas de solution ce jour [GACHES et al. 93].

CIMOSA a pour but de fournir un support tout au long du cycle de vie du systme CIM, en
particulier:

- pour la dfinition prcise des objectifs de l'entreprise et des stratgies manufacturires;

- pour permettre de configurer et de grer l'exploitation du systme en rponse ses
objectifs;
- pour permettre de grer le systme dans un contexte en changement perptuel.

Les avantages de CIMOSA concernent, entre autres choses, une modlisation cohrente de
l'entreprise depuis l'expression prcise des besoins jusqu' une description conforme de
 69

l'implantation, une vritable intgration des divers composants du systme CIM et

l'interoprabilit avec des composants provenant de vendeurs diffrents.

Modles Cycle de Vie Monde Rel

du Systme
Architecture
de Rfrence ,...... Expression """ Objects!Contraintes
Modle Particulier
~
r"
des Besoins ' de l'Entreprise
d'Expression
des Besoins ,....... Conception Entits Fonctionnelles
~ du Systme Spcifies
Modle Particulier '
des Spcifications
de Conception ,...... Installation et
Mise en Oeuvre

Construction! Entits Fonctionnelles

,. Achat Installes
Modle Particulier
de Description '
de l'Implantation ,"" Vrification Entits Fonctionnelles
Vrifies

,. Mise en Oeuvre 1
Entits Fonctionnelles
Modle Particulier ' Oprationnelles
Implant ,...... Exploitation .... Entits Fonctionnelles
~
duSvstme Affectes

Modle Particulier ~
Maintenance Entits Fonctionnelles
Modifi l' du Systme Modifies

Figure 2-16 Cycle de Vie d'un Systme CIM

IV.3 Conclusion sur les Mthodes GRAI et CIMOSA

Pour conclure sur ces deux mthodes relatives la gestion des systmes de production, nous
pouvons nous appuyer sur leurs champs d'application.

La mthode GRAI s'applique essentiellement dans le domaine de la gestion de production en

utilisant une connaissance a priori du systme de dcision et du systme d'information.
 70

La mthode CIMOSA fournit une architecture des systmes ouverts de productique qui pennet
de modliser intgralement une entreprise en se basant sur le cadre de modlisation et sur
l'infrastructure intgrante de CIMOSA (figure 2-17). Par exemple, pour intgrer deux systmes
htrognes (Systme A et Systme B), l'infrastructure de CIMOSA pennet de relier
physiquement les deux systmes et d'assurer les changes de matires (flux physique) et
d'infonnation (flux d'infonnations). Le cadre de modlisation sert de rfrentiel et ralise
l'unification des concepts entre les systmes. Les deux systmes "parlent" le mme langage et
ont une vision commune du systme global, mme si intrieurement ils utilisent des langages
spcialiss et des technologies diffrentes.

concepts

flux physique

Figure 2-17 Intgration des Systmes CIM par la Mthode CIMOSA

Evidemment, des amliorations de ces deux mthodes sont envisages. Dans la mthode
GRAI, les donnes ne sont pas traites en parallle avec les traitements. Elle s'intresse plutt
la modlisation de la structure dcisionnelle. Le fait de prsenter une structure thorique du
systme de production (galement dans le modle CIMOSA) facilite l'approche mais peut dans
certains cas tre restrictif. En ce qui concerne la mthode CIMOSA, elle offre un cadre
innovateur et intressant pour l'intgration des systmes manufacturiers. Cependant, un effort
important reste encore ncessaire ce jour pour faire de CIMOSA une ralit dans le monde
industriel (cohrence des informations dans les diffrents modles de CIMOSA, l'volution du
modle en suivant la modification du systme rel, etc.).
 71

IV.4 Conclusion sur les Mthodes d'Analyse et de Conception

Dans le cadre de la modlisation des systmes de production, nous distinguons deux types de
modles: les modles de structure et les modles de simulation. Les mthodes ou les modles
prsents prcdemment correspondent aux modles de structure. lls dfinissent les concepts
de base, les lments et les relations entre ces lments d'un point de vue statique. Les modles
de simulation reprennent les concepts dfinis dans les modles de structure et introduisent le
facteur "temps": ils prennent en compte la dynamique du systme.

Nous avons vu que toutes les mthodes prcdentes dfinissent un ensemble de concepts,
d'outils et d'tapes suivre pour construire un modle structur d'entreprise qui reprsentent
les lments invariants de l'ensemble du systme productique. Cependant, un systme de
production modliser est par nature complexe, et ce d'autant plus qu'il s'agit d'un systme
stochastique soumis perturbations et alas. Un modle de simulation est ncessaire pour
valider ou valuer les performances du systme tudi.

V La Simulation

La simulation est une technique de modlisation qui consiste reproduire le comportement

dynamique d'un systme sur ordinateur afin de mieux le connatre, de mieux matriser son
volution dans le temps dans un environnement donn; et d'valuer ses performances.

J La modlisation, et plus particulirement la conceptualisation du problme est l'tape la plus

importante d'un processus de simulation. La difficult est de traduire un problme qui
s'exprime en termes rels et concrets au moyen d'un vocabulaire industriel en un modle
constitu de primitives relativement abstraites (vocabulaire de simulation). Nous nous
intressons dans ce mmoire la modlisation des systmes vnements discrets comme c'est
le cas de la plupart des systmes manufacturiers.

V.l Simulation Evnements Discrets

Simuler un systme, c'est chercher reproduire son volution dans le temps, dans un
environnement donn; cette volution est caractrise par celle de variables reprsentatives du
systme appeles variables d'tat.

Dans une simulation vnements discrets, les variables d'tat que l'on dsire connatre tout
instant sont discrtes [LEROUDIER 80]. L'ensemble des valeurs que ces variables peuvent
prendre constitue l'espace d'tat du systme. n s'ensuit que l'espace d'tat est dnombrable ou
 72

fini. Du fait de sa dfinition, on remarque que chaque changement d'tat o vnement se

produit d'une manire discrte dans le temps des instants que l'on appelle des dates
d'vnement. En gnral les vnements sont contingents, c'est--dire que leur occurrence
dpend de l'volution du systme et donc d'autres vnements antrieurs. Nanmoins, il peut
exister des vnements dits dtermins qui ont lieu certains instants prdfinis par une
horloge du systme.

Pendant tout intervalle de temps o l'tat d'un objet du systme ne change pas on dit que l'objet
est engag dans une certaine activit. Un vnement est donc un changement d'tat qui
initialise une activit qui n'tait pas en cours auparavant. L'tat du systme global un instant
donn peut tre caractris par l'ensemble des activits en cours. Le recensement de ces
activits peut tre effectu partir des valeurs des variables (attributs de tous les objets) du
systme et rciproquement.

D'aprs les dfinitions ci-dessus, on constate la dualit entre vnement et activit: toute
activit est limite son dbut et sa fin (dbut d'une autre activit) par un vnement. Tout
vnement marque le dbut d'une activit (qui peut tre de dure nulle).

Quand, dans le modle, on rencontre souvent des squences d'vnements ou d'activits

similaires pour un type d'objet, on peut dfinir ce qu'on appelle un processus. Un processus est
la succession d'un nombre fini d'tats d'un objet ou de faon quivalente la succession d'une ou
plusieurs activits qui concernent cet objet. ll permet de faciliter la description d'un systme.

Pour que la simulation soit possible, il faut tre capable de dcrire les changements d'tat ou
vnements par des algorithmes. Pour chaque vnement on doit dfinir dans quelles activits
vont s'engager les diffrents objets librs par cet vnement (fin de l'activit prcdente). On
dfinit ainsi des contraintes de prcdence entre les diffrentes activits. Les traits
caractristiques de la dynamique de ces modles sont les suivants [BEL et al. 85]:

- Paralllisme des activits et phnomnes de synchronisation. Plusieurs activits peuvent

avoir lieu en mme temps. Une activit ne peut commencer que quand les objets
concerns sont libres.
- Non dterminisme au sens o certains changements d'tat ne peuvent se faire qu'en
surajoutant des rgles de dcision au modle.

En ce qui concerne les systmes de production, les changements d'tat sont dcrits par deux
types de rgles. D'une part ils sont dicts par des contraintes technologiques (gammes
d'usinage, par exemple) qui ne peuvent pas tre modifies dans le modle, ce sont des rgles
 73

opratoires. D'autre part ils sont dtennins par des rgles de gestion et de pilotage qui ne
sont pas connues a priori. Le choix des rgles va dtenniner les performances du systme grce
un meilleur contrle du flux de production.

V.2 Modlisation de Simulation Evnements Discrets

Les vnements arrivant d'une manire discrte, ils peuvent tre ordonnancs dans le temps
(ordre chronologique) et donc simuls sur une machine squentielle l'un aprs l'autre. Le
paralllisme qui peut apparatre l'utilisateur au niveau du fonctionnement logique du systme,
n'existe pas, en ralit, au niveau des changements d'tat. Par la manire de grer le temps dans
une simulation vnements discrets, on distingue les simulations diriges par une horloge et
les simulations diriges par vnements [LEROUDIER 80].

- Simulation dirige par une horloge. On dfinit une unit de temps approprie au problme
et on dispose d'une horloge centrale qui progresse par pas d'une unit de temps. A chaque
incrmentation de l'horloge, on explore la liste des vnements pour voir si l'un d'eux
apparat cette date ou si les conditions pour commencer ou tenniner une activit sont
remplies. Ce mcanisme est souvent utilis dans l'approche par activits. L'inconvnient de
cette approche vient du fait qu'il faut tester toutes les activits ou ordonnancer tous les
vnements chaque pas d'avance du temps et qu'elle risque ainsi de demander un trop
grand temps de calcul.

- Simulation dirige par vnements. Les seuls temps accessibles lors de la simulation sont
des dates d'vnements et l'incrmentation du temps se fait d'une date d'vnement
l'autre. Le temps de la simulation est alors gr partir d'un chancier que l'on peut
prsenter conceptuellement comme une .liste linaire d'vnements ou de processus
([PRITSKER 86], [PEGDEN et al. 90]. La tte de la liste est l'vnement (processus)
courant (prsent) et la fin de la liste l'vnement (processus) le plus loign dans le futur. n
faut remarquer qu' part l'vnement (processus) courant, les autres vnements
(processus) sont purement potentiels car leurs apparitions peuvent tre remises en cause
lors du traitement des vnements (processus) qui les prcdent.

Nous nous intressons dans ce mmoire aux simulations diriges par vnements. Pour pouvoir
raliser une simulation, en plus de l'chancier, il faut des procdures qui permettent de
l'entretenir et de le manipuler. L'ensemble de ces programmes et de ces structures de donnes
s'appelle un noyau de synchronisation (scheduler). Un tel noyau de synchronisation existe sous
une forme ou sous une autre dans toute simulation vnements discrets et en particulier dans
 74

tout langage de simulation (SIMULA, SIM:SCRIPT, SIMAN, SLAM, GPSS~ etc.). ll existe
deux approches pour raliser ce mcanisme.

- Le noyau de synchronisation fournit des fonctions lmentaires permettant d'ordonnancer

les vnements dans le temps. Lorsque l'vnement considr arrivera en tte de
l'chancier, on excutera alors le sous-programme associ l'vnement qui dcrit le
changement d'tat considr dans le systme (une activit). Bien entendu, ce sous-
programme peut ordonnancer l'vnement qui a provoqu son appel ou d'autres
vnements. On dit que la simulation est base sur la notion d'vnement.

- Chaque activit de la simulation qui demeure toujours la description d'un changement

d'tat, donc d'un vnement, est vue un niveau logique comme l'activit d'un processus.
Le modle simul est alors dcrit comme un ensemble de processus progressant
paralllement dans le temps. Chaque processus reprsente une entit active (un objet
actif) qui peut voluer dans le temps au contraire des autres entits de la simulation qui
demeurent passives. Du fait que les diffrentes entits sont excutes en parallles, elles ne
peuvent plus tre dcrites par des sous-programmes (elles seraient alors purement
squentielles) mais elles le sont par des coroutines qui leur assurent une excution en
quasi-paralllisme que nous dtaillerons dans le chapitre V. Le noyau de synchronisation
fournit alors des ordres du type "activer le processus X heure absolue T". Dans une telle
mise en oeuvre, on dit que la simulation est base sur la notion de processus. Cette
approche permet une dualit dans la description du systme simuler en permettant un
change entre entits passives et entits actives (processus). Cette dualit est intressante
et permet de faire un choix sur le cot et les performances de la simulation projete. Ce
qui cote dans une telle simulation, ce sont, bien entendu, les entits actives (processus);
on visera donc faire un choix qui en minimise le nombre.

V.3 Modlisation des Systmes Evnements Discrets.

Bas sur les concepts et les mcanismes de simulation vnements discrets, on distingue
plusieurs approches pour modliser les systmes vnements discrets [CAVILLE et al. 87].

V.3.1 Approche par vnements

Dans cette approche, on commence par rpertorier tous les vnements ou changements d'tat
susceptibles d'tre rencontrs au cours de l'volution du systme. Puis on modlise la logique
de changements d'tat sous une forme d'algorithmes en dfinissant, pour chaque type
d'vnement, les conditions sur l'tat conduisant l'occurrence de l'vnement ainsi que les
 75

changements d'tat correspondants. La simulation du systme est obtenue par l'excution des
logiques de changements d'tat associe chaque vnement la date laquelle celui-ci se
produit.

V.3.2 Approche par cycle d'activits

Au lieu de rpertorier des vnements, dans cette approche on rpertorie les types d'activits.
La logique de changement d'tat se fait alors en prcisant les conditions ncessaires au dbut et
la fin d'une activit. Le droulement de la simulation se fait l'aide d'une horloge. A chaque
pas, on teste, pour chaque activit, si les conditions ncessaires son dbut ou sa fin sont
remplies.

V.3.3 Approche par processus

Dans cette approche, la logique de changement d'tat est relative une squence d'vnements
prdtermins ou processus. On choisira comme processus des squences d'vnements
parfaitement dtermins pour lesquels la logique de changement d'tat sera toujours la mme.
La modlisation d'un systme ncessite donc:

- la dfinition des diffrents processus composant le systme, et pour chacun d'eux, la

logique de changement d'tat dcrivant le cheminement, vnement par vnement, de
l'entre la sortie du processus;
- la connexion des diffrents processus et la spcification de leurs interactions. Ceci
conduit la description complte du systme.

Cette approche combine la simplicit de la description de l'approche par cycle d'activits et

l'efficacit de l'approche par vnements. La plupart des langages de simulation, SLAM,
SIMAN, QNAP2, etc. proposent des processus pr-programms sous forme de primitives
standard facilitant la modlisation. Par contre, la modlisation par cette approche est limite
par la dfinition de processus pr-programms en nombre limit. On aura, dans tous les cas,
recours la programmation, dans des langages comme FORTRAN ou C, de sous programmes
pour modliser des rgles ou des algorithmes de gestion et des fonctionnements particuliers.

V.3.4 Approche par objets

Les trois approches prcdentes sont bases sur la notion d'vnement. La modlisation d'un
systme de production, mme s'il n'est pas complexe, ne peut raisonnablement pas se faire en
juxtaposant simplement toutes les logiques de changements d'tat du systme. L'approche par
objets consiste modliser le systme par un ensemble d'objets qui dialoguent entre eux par
 76

envoi de messages. Elle est base essentiellement sur la notion de processus (certains
simulateurs objets sont bass sur la notion d'vnements comme dans OASYS [BEL 90] et
CADENCE). Cette approche permet de sparer trs nettement les rles respectifs du
concepteur et de l'utilisateur. Le concepteur s'occupe de dfinir les diffrentes classes, tandis
que l'utilisateur n'a plus qu' crer des instances de ces classes pour son application. En effet
l'tape de programmation qui suit normalement celle de modlisation n'a plus sa raison d'tre.
Le processus se trouve rduit et se rsume : modlisation, simulation, analyse des rsultats.

V.4 Langages de Simulation

Pour simuler, on peut utiliser des langages volus, des langages ddis, des langages gnraux
de simulation ou des langages objets.

L'utilisation d'un langage volu (FORTRAN, PASCAL, C, etc.) prsente l'avantage d'une
grande souplesse. Nous programmons notre modle notre faon, avec des entres/sorties
interactives, etc. Mais les inconvnients de l'utilisation de tels langages dans des systmes
complexes font que l'emploi de cette approche est impossible: programmation ncessitant une
analyse trs fine, temps de programmation et surtout de validation importants et impossibilit
de rutilisation d'un programme conu pour un projet auparavant.

Les langages ddis sont conus pour un domaine d'application particulier; par exemple,
l'usinage (MAP/1), le convoyage (SAME/AGVS), l'ordonnancement (PARSIFAL), les cellules
flexibles (SIMUFLEX) [CAVAILLE et al. 87]. Ces langages permettent de dcrire la structure
d'un systme de faon interactive sans avoir connatre les langages de programmation. Les
lments de base d'un langage ddi sont trs marqus smantiquement (poste de montage ou
d'usinage, convoyeur, navette, etc.). L'utilisation de tels langages n'est pas trs rpandue pour
des raisons de non portabilit des modles et des limites de la modlisation dues la nature et
au nombre des lments de base contenus dans la bibliothque d'un langage donn.

Les langages gnraux de simulation ont un vocabulaire plus abstrait que les langages ddis
(files d'attente, ressources, stations, etc.), de faon ne pas dpendre d'un domaine
d'application. Ceci conduit une grande souplesse de modlisation et de modification des
modles. Par contre, la phase d'apprentissage de tels langages peut tre longue et la
modlisation de rgles de gestion complexes n'est modlisable qu' travers l'utilisation des
procdures crites dans un langage volu.

Les langages orients-objets permettent d'unifier les donnes et les fonctions ou procdures en
une seule entit: l'objet. Le premier langage orient-objets est un langage de simulation:
 77

SIMULA; mais la russite de cette approche est due au langage Smalltalk pour ses qualits au
point de we du gnie logiciel: convivialit, rutilisabilit, modularit, etc. ([BAllLY et al. 87]
et [MASINI et al. 89]). La modularit de l'objet et sa spcialisation favorisent la flexibilit et la
maintenabilit du modle [AMAR 90]. Le polymorphisme. et la liaison dynamique (rsolution
tardive) permettent de dcrire les systmes de production de faon volutive et de l'exploiter
avec des strotypes de conduite [BEL 90]. L'objet peut tre spcialis comme on le dsire
sans toucher aux autres objets grce la stabilit des interfaces (encapsulation). En outre,
l'hritage et l'abstraction de donnes supportent les diffrents niveaux d'abstraction et facilitent
la rutilisation des composants du logiciel [YE et al. 92a].

La plupart des langages orients-objets sont squentiels ([CAROMEL 93] et [MEYER 93]).
Pourtant, les activits du systme de production sont concurrentielles (parallles). Un grand
effort d'extension des langages objets vers la programmation concurrente est en cours
([NELSON 91] et [WYAT et al. 92]). Ces langages facilitent l'implmentation des logiciels de
simulation ([AKERBAEK 93], [NICOLAS 93] et [YE et al 94d]).

V.5 Etapes du Processus de Simulation

Plusieurs propositions existent dans la littrature. Un exemple de dmarche, propos par

Du:ffau [DUFFAU et al. 84], se passe en quatre phases:

- analyse du problme et collecte des donnes;

- modlisation, programmation, vrification, validation;
- dfinition des expriences, excution du modle;
- exploitation des rsultats.

L'application de ces tapes ne se droule pas selon un processus strictement squentiel. La

dmarche est au contraire de caractre trs itratif.

Balci [BALCI 90] a propos une autre dmarche en dix tapes qui nous semble plus complte
et plus naturelle (figure 2-18):

- formulation du problme;
- recherche de solutions techniques;
- description du systme;
- formulation du modle;
- reprsentation du modle;
- programmation;
 78

- laboration d'expriences;
- exprimentation;
- redfinition;
- prsentation des rsultats.

Problme
initial

Formulati , Vrification de la
du problme V formulation du problme

Problme
formul
Dcideurs
,. l '
Recherche de ' Estimation de faisabilit
'
solutions teehni~ ..... ~ de la simulation
Analyse des rsultats
Solution technique
propose (simulation)
,.
Rsultats sous forme Analysedu ''
~'vrification de dfinition
d'aide la dcision systme V -... ~ dusystme et objectifs

:Formulation
, dumodle

conceptuel

V et V du modle :Reprsentation
de communication , dumodle

Rsultats de Validation du Validation des Modle de

la simulation modle donnes communication

Vrification du ', Programmation

modle programm

Exprimentation : Modle
programm

Vrification des ' Elaboration

expriences : d'expriences

Figure 2-18 Etapes d'un Processus de Simulation

 79

A chacune de ces phases est associe une procdure de vrification et/ou de validation. La
vrification consiste examiner si le modle de simulation est bien construit. La validation
consiste tester si on a construit le bon modle de simulation.

L'application des tapes du processus de simulation demande la rsolution de diffrents

problmes pour lesquels on ne dispose pas ou peu d'outils d'aide. Les principaux problmes se
situent au niveau de la modlisation, la validation statistique et l'interprtation des rsultats.
Dans ce mmoire, nous mettrons en vidence l'tape de modlisation et simulation en utilisant
l'approche objets et nous proposerons les tapes de modlisation suivantes [YB et al. 94c].

Etape 1: Identification des classes d'objets et de leurs services en utilisant des mthodes
traditionnelles d'analyse et de conception par objets.
Etape 2: Sparation des objets actifs et passifs. Les objets actifs sont des entits dont
l'activit est autonome.
Etape 3: Dfinition de diagramme de transition d'tats et de diagramme de communication
de processus pour les objets actifs.
Etape 4: Dfinition d'activit (comportement) d'objets actifs et adaptation des contraintes de
pilotage (en intgrant des rgles de conduite et de gestion).
Etape 5: Raffinement des attributs et des services d'objets de l'application et construction de
modles de simulation.

V.6 Conclusion sur la Simulation

Les modles de simulation sont capables de dcrire le systme avec le degr de dtail et de
prcision ncessaire qui convient la rsolution du problme pos. Cette description inclut la
partie physique de l'atelier mais aussi certains aspects du systme de gestion de production.

Les logiciels de simulation tendent se multiplier aujourd'hui. lls ont pour objectif d'tre plus
proches des besoins des utilisateurs, plus faciles utiliser et plus puissants. Les recherches
menes actuellement s'orientent dans de nombreuses directions. Notons en particulier que
plusieurs tudes sont conduites actuellement pour appliquer la technologie objets, la
programmation concurrente et distribue dans la construction des modles de simulation.
L'utilisation des approches objets devrait permettre une avance importante dans le domaine
de la simulation, en permettant la mise au point d'un outil de modlisation la fois modulare,
flexible et convivial [BEL 90]. La programmation concurrente permettra d'implmenter
facilement la coopration (communication et synchronisation) entre les objets dans un modle
de simulation oriente-objets.
 80

VI Conclusion

Dans ce chapitre, nous avons survol les principales mthodes d'analyse et de conception des
systmes de production. On peut les regrouper en termes des mthodologies informatiques en
trois catgories: mthodes bases sur la dcomposition fonctionnelle, mthodes bases sur les
"data-flow diagrams" et mthodes bases sur l'approche objets [COAD et al. 90].

La dcomposition fonctionnelle conduit les concepteurs commencer par la description du

systme la plus abstraite du point de vue de sa fonction puis de raffiner cette vue par des tapes
successives (mthodes SADT, GRAI et CIM:OSA). Chaque sous-systme est dcompos dans
chaque tape en un petit nombre de sous-systmes plus simples que leurs anctres, jusqu' ce
que tous les lments dduits soient de nouveau d'un niveau d'abstraction suffisamment bas afin
de les implmenter directement. C'est une dmarche d'analyse et de conception descendante,
c'est--dire que l'on part de la description (fonctionnelle) la plus gnrale du systme et que
l'on incorpore les dtails au fur et mesure de l'avancement de l'analyse et de la conception.

Cette dmarche est trs difficile construire et trs volatile. Du point de vue du gnie logiciel,
elle est fiable, efficace, etc., mais non rutilisable, non volutive, non maintenable. Du point de
vue de l'approche objets, cette mthode:

- est gnralement inadquate pour les problmes de simultanit (concurrency nature);

- n'utilise pas le principe de type abstrait et d'encapsulation;
-est souvent difficile modifier (non-volutive) suivant le changement de la spcification
correspondante;
- ne permet pas le partage du code (hritage);
- manque la flexibilit;
-etc.

L'approche de data flow diagram, souvent nomme une mthode d'analyse et de conception
structure (mthodes SA/SD, MERISE), est une autre mthode de transformation d'un
problme rel en une reprsentation technique. Cette transformation exige des analystes (et
plus significativement des clients), un suivi des flux de donnes chaque fois qu'ils observent le
monde rel et traduisent ce flux en sous-squence analyse et spcification. Bien que "follow the
flow of data" ne soit pas l'une des mthodes essentielles que les concepteurs (analystes)
utilisent pour rsoudre la complexit du problme, ce flux dcrit plus en dtailles processus-
tapes et ils sont trs utiles pour identifier les mthodes et les attributs d'objets dans l'approche
objets. La problmatique de cette approche est:

- la difficult de slectionner les attributs appropris et leur nombre;

 81

- la taille de son "data dictionary";

- les interfaces volatiles de donnes;
- la difficult transformer le data flow diagram en programme;
-etc.

L'approche objets, issue du gnie logicieL permet de dcrire concrtement un systme de

production. Les concepts et les processus de mise en oeuvre de cette approche seront discuts
dans les deux chapitres suivants. Nous prsentons ici seulement pourquoi nous avons adopt
l'approche par objet pour la simulation [YE 93].

- Exigence du gnie logiciel: abstraction de donnes, modularit, encapsulation,

rutilisabilit, comprhensibilit, ... ;

- Description concrte du systme simuler: Possibilit de one-to-one-mapping

entre les objets modliser dans l'industrie manufacturire et leurs abstractions dans un
modle de simulation;

- Structuration du systme de conduite [BEL 90]: Le dveloppement des classes

d'objets du systme de production manufacturire implique que ces objets modliss
maintiennent une quantit importante de donnes de management de production et de rgles
choisir (mthodes) dans les systmes comme M.RP., O.P.T., J.A.T., etc.

- Description volutive de l'atelier: Si les classes d'objets essentielles du domaine sont

construites, la tche de construction du modle rel est allge, c'est--dire que le temps de
construction ou composition (model setup time) du modle est rduit; puis, en fonction de
l'volution de la conception, les objets de base sont spcialiss ou remplacs progressivement
par des objets plus dtaills, introduisant ventuellement de nouvelles donnes dfinir et de
nouvelles mthodes (ou de mthodes surcharges).

- Stockage de strotypes de composants et de systmes de conduite [BEL 90]: La

disponibilit de ces classes du domaine permet de modliser rapidement et prcisment un
systme dans diffrents niveaux d'abstraction (atelier, poste de travail, machine).

- Ds que ces classes d'objets hirarchises sont dveloppes, les rgles ou mthodes
de management appliques sur ces objets peuvent tre encapsules comme des mthodes
d'objets. Par exemple, les concepts de J.A.T. telles que des rgles "tirer" ou "pousser" le flux,
rduire le temps de prparation, minimiser les en-cours, etc. peuvent tre cods comme des
mthodes dans les objets machines et stations.
 82

- Modlisation facilite des systmes de management de production complexes grce

aux concepts d'hritage, de mthodes surcharges, de liaison dynamique, etc.
 Chapitre III Analyse des Systmes de Production par
l'Approche Objet

1 Introduction

L'analyse, premire tape du dveloppement d'une application, consiste dfinir et modliser

les problmes d'un systme [MCGREGOR 92] dans le but de fournir une description du
comportement externe observable. La mthode d'analyse procdurale ou fonctionnelle produit
un cahier des charges qui spcifie les fonctionnalits du systme dsires par les clients ou par
les utilisateurs.

L'analyse par objet est une mthode utilise pour identifier les entits significatives relles ou
conceptuelles d'un systme, et pour comprendre et expliquer comment ces entits inter-
ragissent afin de raliser les objectifs viss par les utilisateurs [SID..AER et al. 92]. Le rsultat
d'analyse est un document qui dcrit une caractrisation essentielle de l'espace du problme (un
ensemble d'entits relles ou conceptuelles) et leurs fonctionnalits.

Le processus d'analyse est subdivis en deux tapes: l'analyse du domaine et l'analyse de

l'application. L'analyse du domaine tablit le contexte principal dans lequel ce systme sera
construit. L'analyse de l'application se concentre sur le domaine d'intrt afin de construire un
cahier des charges pour une application particulire. L'analyse par objet se distingue de la
mthode procdurale par deux aspects: le centre d'intrt et le point de vue.

L'analyse par objet fournit une possibilit de modliser plus profondment et plus naturellement
l'espace de problmes en considrant une plus grande partie de son espace au lieu d'une partie
particulire le concernant. Les concepts identifis par l'analyse par objet seront plus stables et
plus abstraits que ceux dvelopps par l'analyse traditionnelle. Ces concepts sont des
composants de base pour construire des modles d'application plus flexibles et plus extensibles.
Les modles raliss en utilisant ces abstractions s'accommodent plus facilement au
changement de spcification (d'une application particulire); et ils facilitent la comprhension,
par les utilisateurs, des problmes rsoudre et de leurs solutions potentielles.

Le document produit en utilisant l'approche d'analyse par objet est trs diffrent de celui de
l'analyse procdurale. Les documents traditionnels sont orients-fonctionnalit: un systme est
vu comme un ensemble de services qu'il peut fournir. Les documents " objets" s'appuient sur
 84

la description des entits et leurs relations avec la problmatique du domaine: un systme est
considr comme un ensemble d'entits qui inter-ragissent.

Avant de construire un systme informatique, les analystes doivent en gnral traiter un grand
nombre de diffrents sujets ou domaines. Chaque domaine peut tre considr comme un
monde spar qui possde ses propres entits conceptuelles ou objets, et qui peut exister plus
ou moins indpendamment des autres. Les interactions entre ces domaines se ralisent par
diffrents vnements. Dans un systme de GPAO, par exemple, le domaine de production
concerne les produits, les machines, les transporteurs, les oprateurs, etc., tandis que le
domaine de l'interface utilisateur est constitu de fentres, de boutons de contrle, d'icnes et
d'affichages textuels ou graphiques, etc.

L'ensemble des domaines du systme est reprsent par un diagramme de domaines (exemple
en gestion de production assiste par ordinateur dans la figure 3-1). Certains domaines sont
assez petits pour que l'on puisse les analyser intgralement, tandis que d'autres contiennent trop
d'objets (lments) et, doivent tre diviss en diffrents sous-systmes analysables.

Figure 3-1 Diagramme des Domaines de GPAO

Une fois le systme dcompos en domaines et en sous-systmes, l'analyse du domaine peut

tre entreprise.
 85

II Analyse du Domaine.

L'analyse du domaine est l'activit d'identification des objets et des services d'un ensemble de
systmes similaires pour un domaine d'application. C'est un processus dans lequel les
informations utilises dans le dveloppement de logiciels sont identifies, recueillies et
organises pour rendre ces informations rutilisables quand on met jour ou quand on cre de
nouveaux systmes similaires [PRIETO 90].

ll.l Dfinition du Domaine

Un domaine est un monde rel spar et hypothtique, ou un monde abstrait, qui constitue un
ensemble d'objets distincts qui se conduisent conformment aux rgles et aux caractristiques
du domaine. En gnral, un domaine est "une sphre d'activits ou d'intrts: champs"
[Sffi.,AER et al. 92]. En termes de gnie logiciel, il peut tre interprt comme un champ
d'application dans lequel les logiciels sont dvelopps.

Un domaine peut tre simple comme un algorithme de calcul ou compliqu comme un systme
de GPAO qui est un ensemble de sous-domaines imbriqus ou semi-hirarchiss (figure 3-1).
Les domaines sont classs en quatre types selon leur rle dans un systme informatis.

1) Les domaines d'application sont le sujet du discours issu de la spcification des

clients (utilisateurs) du systme: quelles sont les fonctionnalits dont les clients ont besoin.
Pour un projet donn, il n'y a normalement qu'un domaine d'application.

2) Les domaines de service fournissent les mcanismes gnraux et les fonctions

utilitaires afin de supporter les domaines d'application. Notons que, au moment de l'analyse,
chaque domaine de service fait certaines hypothses concernant les autres domaines dans le
systme. Ds seront complts et modifis plus tard dans la phase de conception et
d'implmentation. La figure suivante (figure 3-2) [CUGY 83] montre une organisation
fonctionnelle des domaines de services d'une entreprise. Chaque domaine est dfini par son
objectif et les moyens mis sa disposition pour l'atteindre.

- Le domaine vente assure la liaison entre l'entreprise et ses clients. Le processus de

vente ne correspond plus faire couler sur le march des produits dj conus et fabriqus
mais analyser les besoins des clients (tude de march) partir desquels sera faite la
conception d'un nouveau produit et sa satisfaction;
 86

- Le domaine technique comprend la conception des produits et l'tablissement des

phases d'industrialisation des produits (nomenclatures, gammes, etc.);

- Le domaine production met en oeuvre les moyens de production pour obtenir les
produits finis destins la vente;

- Le domaine approvisionnement assure l'alimentation des ateliers de production en

matires premires et ressources;

Domaine
Domaine Marketing Ordonnancement
Programmation

Domaine
Distribution

Domaine
Qualit

Figure 3-2 Fonctionnalits Principales d'une Entreprise

- Le domaine personnel gre les ressources humaines de l'entreprise;

- Le domaine finance et comptabilit a pour but de se procurer et de grer les capitaux

ncessaires au fonctionnement de l'entreprise ou son expansion et d'enregistrer les
mouvements de fonds.

3) Les domaines d'architecture fournissent les mcanismes et les structures gnraux

pour grer les donnes et contrler intgralement le droulement du systme. Les objets dans
les domaines d'architecture comprennent les abstractions de structures de donnes lmentaires
et d'units de code de leur gestion ou de leur contrle. La figure suivante (figure 3-3) montre
une architecture de simulation par processus avec la notion de thread support par le langage
de programmation C++. Cette architecture a plusieurs objectifs.
 87

Le premier est d'imposer une uniformit au niveau de la construction du logiciel par des
stratgies qui rpondent aux questions suivantes.

* Comment les donnes sont-elles organises et distribues?

* Comment le flux de contrle est-il ordonn, structur et enchan?
* Comment l'application et le code de service sont-ils structurs?
* Quelles intercommunications sont autorises entre quelles units de code?
* etc.
Leur intention est de limiter la complexit du systme construire en fournissant des structures
normalises et des voies communes pour des dveloppements des systmes similaires.

ARCIDTECTURE DE SIMULATION

VlSUalSliltion Graphique Format Sortie

des Rsultats
Outils d'Analyse Postscript
d'Aide la Dcision
'.

Exclter la Simulation

Utilis dans les

DocJ.J.ments sur
Un Systme de Plateforme (M.A,PC, )
Avec le Compilateur C++ et les Modules des Processus Lgers (Threads)

Figure 3-3 Architecture de Simulation Concurrente avec des Threads

Le deuxime objectif est de dfinir les diffrentes activits du systme au niveau de

l'architecture. La plupart des systmes exigent des codes signifiants pour grer l'initialisation et
la fermeture du systme, pour maintenir la coordination des diffrentes activits et pour
transfrer les donnes entre les diffrents sous-domaines. Ces activits influent sur tout
systme; il ne faut pas les mlanger avec les domaines d'applications et les domaines de
 88

services. Le domaine d'architecture peut donc donner une structure complte pour dfinir et
organiser ces activits communes de faon plus cohrente.

Le troisime objectif est de dfinir une plate-forme (une interface d'architecture avec plusieurs
systmes d'exploitation) pour le problme de portabilit. Le schma de la figure 3-3 montre
bien que cette architecture s'adapte tous les systmes qui possdent un compilateur C++ et
un module de manipulation des processus "lgers" (threads).

Enfin, nous pouvons construire des composants ou des modules standardiss et valids ou bien
des sous-systmes embarqus si nous avons une architecture commune pour le but
d'optimisation de performances (abstraction, rutilisabilit, modularit, etc.).

4) Les domaines d'implmentation incluent les langages de programmation, les

rseaux informatiques, les systmes d'exploitation et les librairies de classes communes. Ces
domaines fournissent les entits conceptuelles ncessaires l'implmentation du systme. Cet
aspect concernant l'implmentation de la simulation concurrente des systmes de production
par l'approche objets sera dtaill dans le chapitre V.

11.2 Processus de l'Analyse du Domaine

Un systme complexe est compos de plusieurs domaines imbriqus. Chaque domaine est
limit par une frontire dans laquelle sont dfinis les objets, les oprations et les relations
internes et externes. Cette frontire dlimite la capacit oprationnelle de chaque domaine.

L'analyse du domaine est un processus dans lequel les informations utilises dans le
dveloppement de logiciels sont identifies, captures et organises dans le but de rendre ces
informations rutilisables dans le futur. Plus prcisment, l'analyse du domaiJ:le essaie de
dvelopper et d'valuer une infrastructure d'information (comme dans le modle CIM:OSA)
afin de fournir un standard et de permettre la rutilisation des informations. Les composants de
cette infrastructure comprennent les modles du domaine, les standards du dveloppement et
les librairies des composants rutilisables.

Malheureusement, l'analyse du domaine est conduite d'une manire ad hoc. Le processus

d'abstraction est habituellement considr comme une activit intelligente de l'tre humain et il
est trs associ avec les "expriences". Prieto-Diaz [PRIETO 90] a donn un schma SADT
(figure 3-4) qui montre les entres, les sorties, les contrles et les mcanismes pour dcrire le
contexte de l'analyse du domaine.
 89

Les informations sont collectes partir des systmes existants comme les programmes
sources, la documentation, le manuel utilisateur, etc., en mme temps que la connaissance du
domaine et le cahier des charges du systme actuel et futur. Les techniques de l'intelligence
artificielle comme l'acquisition ou la reprsentation des connaissances jouent un rle important.
Les experts et les analystes du domaine extraient les informations et les connaissances (figure
3-5) en s'appuyant sur les systmes existants, les mthodes d'analyse et d'autres informations
introduites. Avec l'aide des ingnieurs du domaine, ces connaissances et abstractions sont
organises et encapsules sous la forme des modles du domaine, des standards et des
collections de composants rutilisables.

Sources de mthodes Modles

d'analyse
ConnaiSSillce
du domaine du
des Domaines Domaine

Analyse taxonomies

du standards

modles fonctionnel
Domaine
langages de domaine

experts ingnieur
du domaine analyste du domaine
du domaine

Figure 3-4 Contexte de l'Analyse du Domaine

C'est un processus de raffinement itratif et incrmentai. Les modles du domaine, sous

diffrentes formes, supportent diffrentes tapes du dveloppement d'un logiciel. Les
ressources rutilisables sont slectionnes et intgres dans les nouveaux systmes. Les
donnes rutilisables sont ensuite collectionnes et retournes la phase d'analyse du domaine
afin de raffiner et d'enrichir les modles du domaine et de mettre jour la librairie des
ressources et des donnes.

Trois intervenants autres que les experts du domaine, les analystes du domaine et les ingnieurs
du domaine jouent un rle important dans ce processus. Ce sont le gestionnaire de ressources
ou de moyens, le responsable maintenance et le bibliothcaire. La tche du bibliothcaire est de
 90

rendre les ressources disponibles et faciles d'accs pour les futurs utilisateurs. Le gestionnaire
de ressources rgle la qualit de ces ressources et les normalise. Le responsable maintenance
maintient la collection des donnes concernant l'analyse du domaine et coordonne la
rutilisabilit globale du systme.

En bref: l'objectif de l'analyse du domaine est de crer un systme gnral ou un ensemble de

systmes intgrs tout en fournissant une infrastructure en permettant que l'on capture et
reprsente les objets des applications potentielles.

Mthodes retour des informations

d'Analyse
du Domaine

>
t Ingnieur u Domaine

D'autres Entres MODELES DU DOMAINE Gestionnaire

de
Systmes-~ Rutilisabilit
Existants L--r---.,---1

Analyste du
Domaine

Ressources Rutilisables

Gestionaire de Ressources Bibliothcaire

Figure 3-5 Infrastructure de Rutilisabilit de l'Analyse du Domaine

dans le Cycle de Vie d'un Logiciel

ll.3 Rsultat de l'Analyse du Domaine

L'analyse du domaine est considre comme un challenge stratgique ainsi qu'une technique
dans laquelle les analystes essaient d'aboutir un consensus sur le vocabulaire et la thorie d'un
domaine [TRACZ 92]. Pour cela, certains moyens de reprsentation tels que: 1) langages
naturels, 2) schma entit-association, 3) objets, 4) thesaurus/taxonomie, 5) logique des
prdicats, et 6) rseaux smantiques ou d'autres techniques de reprsentation issues de l'lA,
sont utilises pour construire une abstraction des objets du domaine. Krueger [KRUEGER 92]
divise les approches d'abstraction en huit catgories: 1) langages de haut-niveau, 2)
rutilisation directe des concepts et des codes par exprience (design and code scavenging), 3)
composants des codes, 4) schmas des algorithmes et des structures de donnes (software
 91

schemas), 5) gnrateurs d'applications, 6) langages naturels ou langages de spcification, 7)

systmes transformationnels et 8) architectures de logiciels.

TI est difficile de comparer dans l'absolu les diffrentes approches existantes. Elles se
distinguent en premier lieu par leur champ d'application; c'est--dire que certaines approches
sont plus spcialises, et donc plus mme de prendre en compte certains composants du
systme que d'autres. Si la conception et la programmation par objet concernent plutt les
composants codes, l'analyse par objet se concentre sur les composants (classes d'objets) du
domaine et leurs interactions ou plutt leurs relations. En gestion de production, TI est
classique de dcomposer les systmes de production en trois composants principaux.

1) Le systme physique (S.P.), appel aussi systme oprant ou systme

technologique, agit sur les produits en effectuant des transformations, des contrles, des
stockages et des oprations de manutention. Les systmes physiques sont organiss de
diffrentes faons, par exemple en lignes flexibles, chaine de transfert, lot de production, etc.

2) Le systme de dcision (SD), appel aussi systme de conduite ou systme de

pilotage, a pour but de modifier, par ses dcisions, l'volution du systme physique. TI dcide
en fonction: du comportement du systme physique, de l'tat de l'environnement et des
objectifs qui lui ont t assigns (par exemple, fabriquer une quantit donne d'un produit dans
un dlai prvu suivant une qualit demande). Les dcisions peuvent tre humaines, assistes
par ordinateur (systme d'aide la dcision, systmes experts) ou automatises (systme
intgr de production). Parmi les dcisions dont ce systme a la charge, on distingue de faon
classique les dcisions de planification, d'ordonnancement, et de lancement.

3) Le systme d'information (SI), assure essentiellement la collecte, la transmission, le

traitement et la mmorisation des informations venues de l'environnement du systme de
production, mais galement du systme lui-mme. n sert de liaison entre le systme de dcision
et le systme physique.

La figure 3-6 illustre les liaisons entre ces trois composants. Nous nous intressons
particulirement la modlisation du systme physique et aux informations collecter pour
que l'on puisse prendre des dcisions. L'intgration du systme de dcision sera considre
dans la modlisation des processus des moyens de production dans le chapitre IV.

Un systme physique est compos de trois sortes de populations: les produits transformer, les
moyens de production (transformation et manutention) et les ressources qui conditionnent le
flux de produits sur les moyens de production (figure 3-7). Ces trois types de population, que
 92

l'on retrouve invariablement selon les rpartitions les plus diverses dans touts les units de
production, sont les lments de base de tout systme de production. Dans ce mmoire, nous
essayons de les modliser au niveau oprationnel dans le but de construire un modle de
simulation des systmes de production. On s'intresse plutt l'axe processus de la production
([JULLULIEN 92], [MATHON 92]). Les outils et les oprateurs sont considrs comme des
ressources afin de mieux dfinir les processus technologiques qui constituent le coeur de la
production.

Systme de Production

Information,
Flux
contraintes, et
d'information
objectifs

Flux physique

Pertu~bation

Figure 3-6 Reprsentation Simplifie du Systme de Production

Moyens de Production
(machines,
transporteurs,
chariots, ... )

Produits ....<r--------------:::>~ Ressources

(produits finis, (outils,
produits semi-finis, outillages,
composants, stockages, .
matires premires, ouvriers,
ordres de production, infomations, ...)
lots, ... )

Figure 3-7 Trois Populations du Systme Physique (Point de Vue de la Simulation)

 93

ll.4 Identification des Classes d'Objets du Domaine

Dans cette phase d'analyse, les objets sont identifis du point de vue des utilisateurs. TI n'est
pas vident de construire une abstraction des objets similaires bien que l'on puisse identifier les
individus facilement dans le monde rel. Par exemple, dans un atelier, on voit diffrents moyens
de production tels que des tours, des fraiseuses, des convoyeurs, etc.; mais comment peut-on
les abstraire en des classes qui possdent des caractristiques communes. Une solution possible
par exemple, en considrant l'espace du problme et les diffrentes exigences informatiques
pour la simulation, on peut abstraire ces moyens de production comme un processus, puisque
ces moyens absorbent des articles en entres (pice ou composant, matire premire, lot, etc.),
et les restituent en sortie aprs un dlai dpendant de leurs comportements et des articles
traits. Tsichritzis [TSICHRITZIS 1988] propose cinq catgories d'objets identifier dans les
systmes objets: 1) objets physiques, 2) objets "rles", 3) objets "incidents", 4) objets
"interactions" et 5) objets "spcifications".

1) Les objets physiques sont des entits relles qui existent dans le systme. Nous
pouvons les apercevoir facilement, et leurs attributs peuvent tre identifis et dtermins
travers leur comportement et les diffrents points de vue des utilisateurs. Par exemple, l'activit
de la production, d'une manire gnrale, met en jeu de faon interactive des individus
appartenant trois populations: la population des produits, des moyens de production et des
oprateurs de production. Elles forment, en quelque sorte, un espace dans lequel se droulent
les oprations de production.

Les attributs sont de diffrentes natures: structurels, conjoncturels, vnementiels, instantans,

historiques et statistiques [YE et al. 93]. Pendant la phase d'analyse, on peut identifier les
attributs structurels et conjoncturels des objets. Les attributs structurels, peu volutifs,
caractrisent les aspects fondamentaux des objets. Cer:tains d'entre eux dcrivent les liens
logiques avec d'autres objets et leur spcification fine dpend essentiellement de la nature des
applications et des conditions d'exploitation. Les attributs conjoncturels expriment le contexte
dans lequel doit se drouler la production. lls sont, dans une large mesure, non modifiables
dans le cadre de la production elle-mme et reprsentent plutt les contraintes extrieures. La
figure suivante (figure 3-8) montre des exemples d'attributs essentiels d'un oprateur. L'attribut
qualification est une donne fondamentale du systme de production pour reprsenter le
niveau de comptence d'un oprateur. L'attribut niveau de rmunration sert reconstituer les
cots oprationnels de production. L'attribut moyens affects sera utilis par des rgles
d'allocation des ressources. Le calendrier des prsences exprime la disponibilit d'un oprateur
 94

en fonction du temps; il est complt normalement par un tableau d'affectation selon les
secteurs d'organisation de production qu'on va ajouter la phase d'analyse de l'application.

Oprateur
identificateur calendrier des prsences:
qualification au niveau de l'quipe
niveau de rmunration au niveau de la journe
moyens affects au niveau de la semaine
etc. au niveau de l'anne

Figure 3-8 Attributs Structurels et Conjoncturels d'un Oprateur

2) Les objets "rles" modlisent les contraintes auxquelles sont soumises les objets ou
les rgles d'utilisations d'objets. Ces objets sont en gnral des attributs des autres objets
physiques. Dans la production, par exemple, les objets tels que le programme de fabrication,, la
nomenclature de produit et la gamme d'usinage de pice, sont des contraintes ou rgles
opratoires. Les objets comme la prvision de demandes, la planification de production, les
rgles de priorit et de pilotage sont des fonctions que le systme de gestion de production doit
accomplir. Une autre utilisation des objets rles est d'exploiter les relations au sein des
mthodes d'objets. Par exemple, le concept de "lot" joue le rle des entits de flux dans la
simulation des flux de production; et les fonctions telles que des rgles de priorit seront
choisies dynamiquement par la machine selon l'tat de la file d'attente, l'tat de la machine et
l'objectif de la production.

3) Les objets "incidents" reprsentent les apparitions des vnements alatoires. Un

objet opration de fabrication, par exemple, contient des informations sur le moyen de
production utilis, le temps de prparation, le temps opratoire, la date de dbut et de fin, les
outillages utiliss, etc. Un objet incident d'une opration de "panne" est produit quand il y a
une casse d'outil, un blocage d'un mouvement d'outillage, une panne de machine de toute
nature: mcanique, lectrique, lectromcanique, pneumatique, informatique, etc.

4) Les objets "interactions" reprsentent des liens ou des relations entre les diffrents
objets. Des liens persistent systmatiquement entre les diffrents individus du monde rel. Une
relation est un lien stable entre deux individus diffrents, qui permet tout moment,
connaissant l'un d'entre eux, de connm"tre d'un autre. TI y a deux natures de relations:
conditionnelle et inconditionnelle [SJll.,AER et al. 92]. La relation inconditionnelle exige que
chaque partenaire d'une association participe la relation. Dans la relation conditionnelle, un
ou l'autre des partenaires d'une association n'est pas oblig de participer la relation. Une autre
caractristique d'une relation est sa cardinalit qui reprsente le nombre d'instances d'un ct
 95

qui sont lies avec une instance d'un autre ct. En incluant la cardinalit et la forme
conditionnelle et inconditionnelle, dix types diffrents de relations existent entre deux classes
d'objets partenaires (figure 3-9).

FORME INCONDITIONNELLE (toutes les instances participent)

@ e 1:1 (? 1:: rd
FORME CONDITIONNELLE (non participant d'un ct)
~
r- -e1 :le
f?
~
le:;@
rr M :Mc
-@
FORME BI-CONDITIONNELLE (non participant des deux cts)

}------f)
le : le
~ le :Mc
~ Mc: Mc

Figure 3-9 Dix Formes d'une Relation entre Deux Classes Partenaires

Le but d'une relation est de permettre la mise en vidence des instances d'une classe qui sont
associes avec celles d'une autre classe. Cela est fait en plaant les attributs de type rfrence
(un pointeur en terme informatique) dans les classes partenaires. Dans le cas de la cardinalit
un--un, l'attribut rfrence peut tre ajout dans l'un des deux classes. On place un attribut
rfrence dans le ct plusieurs d'une relation si la cardinalit est un--plusieurs. Afin de
formaliser la relation plusieurs--plusieurs, nous devons crer un objet "interaction" ou un
objet "association" qui contient les rfrences de l'identificateur de chaque classe participante.
Cet objet possde son propre identificateur, ses attributs et ses mthodes. Une commande de
produit, par exemple, contient les attributs: identificateur, rfrence de clients, rtrence de
produits, quantit commande, date de commande, dlai de livraison, etc. Les mthodes pour
dfinir son comportement sont illustres dans la figure 3-10.

5) Les objets "spcifications" reprsentent des points de vue d'une partie slectionne
d'une structure ou des supports qui combinent des entits simples en entits plus complexes.
L'objet spcification fait habituellement de rfrence aux autres objets. Un tableau d'affectation
des oprateurs aux moyens de production, un catalogue des articles stocks dans le magasin,
une file d'attente amont et aval d'une machine, diffrents tableaux de bord, etc., appartient ce
genre des spcifications. Les points de vue d'un objet correspondent. ~:1a notion de version
d'objet: un produit en stock, en-cours de fabrication, en ordonnancement, par exemple,
 96

possde la mme structure de base mais leurs interprtations contextuells ne sont pas
forcement les mmes.

Commande d'un Produit

vnement 1: Client envoie une commande (Client ID, Produit ID, quantit, prix, date).

Crer une Commande

Si PRODUIT EN STOCKQuantit en stock> COMMANDE.quantit
alors:
dcrementer la quantit en stock
vne crer un vnement 2: rpondre la commande
sinon
crer un vnement 3: lancer un ordre de fabrication
tat courant := " Enregistr"

Informer que la commande est transforme en l'ordre de fabrication

tat courant := "Ordre de fabrication"
vneme t 4: rpondre au messa ede FABRICANT::fourniture des roduits

1 Livraison de produit

Emballer et transfrer le produit au client avec une facture

tat courant := "Livraison de produit"
vnement : rception de paiement
1

1
Pay
-----
enlever cette commande

Figure 3-10 Comportement de l'Objet Interaction "Commande"

Quand ces objets sont identifis, ils doivent tre mis dans le cahier des charges l'aide des
quatre modles suivants [SHLAER et al. 92]: des modles informationnels qui dcrivent les
caractristiques ou les attributs des objets et leurs relations qui persistent entre les objets, des
modles d'tats qui dcrivent la transition d'tat ou le comportement temporel des objets, des
modles de communication qui dcrivent la dynamique ou le contrle global d'objets (les
changes d'informations internes et avec le monde extrieur) et des modles processus qui
dcrivent diffrentes oprations d'une activit ou d'un vnement. Nous discuterons les trois
 97

premiers modles dans la section suivante, et le quatrime sera prsent la phase de

conception des classes (ou plutt de conception des mthodes concurrentes).

III Analyse de l'Application

L'analyse de l'application prend les modles de l'espace de problme, crs pendant la phase
d'analyse du domaine, comme des entres et se concentre sur l'application courante
construire afin de transformer les modles du domaine en modles d'application. Les exigences
des clients sont utilises comme des contraintes qui rtrcissent la quantit d'informations du
domaine. Les informations retenues pour une application particulire sont donc influences par
une grande we de l'analyse du domaine. La structure d'application obtenue est plus gnrale et
robuste que celle qui est dveloppe directement partir de cahier des charges d'une
application particulire construire.

Les modles crs pendant l'analyse du domaine reprsentent des concepts importants du
domaine sans tenir compte des cas particuliers d'application ni des reprsentations
informatiques. L'analyse de l'application filtre les informations du domaine et impose des
conditions qui accompagnent les contraintes informatiques (logicielles ou matrielles). Deux
extensions doivent tre considres: l'enrichissement des classes d'objets vers les applications et
la concrtisation de diffrents modles d'application (figure 3-11).

,_ - - - - - -- - - - - - - - -- - - - --- - - - -- -- - - - - - - --- - - 1

Modles
du
Domaine

,_ -- - - - - - - - - -- - - - - - - -- - ~ -- - - - ---- - -- - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ,.
~

Composants
RutiUsables ~~

--------- --------------------------------
1

1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ,

AppUcations ~~
1

}.pplication 1 7 L application i 7
/ application n /

,_---------------------------------------- 1

Figure 3-11 Etapes d'Analyse Oriente-Objets

 98

ll.l Spcification des Classes d'Objets pour l'Application

Une application est un cas particulier du domaine. Elle est en gnral un problme complexe.
La complexit tient la nature et au nombre d'lments modliser, la diversit et au nombre
d'attributs crer, la sophistication et la quantit des rgles de gestion. TI est impossible de
construire un modle gnral et rigoureux simultanment. Nous essayons ici d'tablir un
modle des systmes de production qui est assez gnral et, qui s'adapte la simulation en
utilisant l'approche par objet.

Pour construire une telle application, il ne suffit plus de faire une analyse du fonctionnement de
chacun de ses lments avant de les assembler. TI faut spcifier les comportements de chacun
lment (complication de l'lment) d'une application avant d'affecter un rle chacun de ses
lments dans la phase de conception d'une application. Nous avons identifi cinq catgories
d'objets dans la phase du domaine. Ces objets doivent d'tre concrtis et spcifis par
diffrents modles graphiques et textuels dans un cahier des charges: modle de
communication, modle des transitions d'tat, modle informationnel, modle de processus,
pour qu'un utilisateur puisse les instancie et concrtise dans son modle de l'application. Nous
les montrons les spcifications de ces modles travers quelques exemples d'objets physiques
des systmes de production.

ll.l.l Modles de Communication de Classes d'Objets

Un systme de production saisit les ordres de fabrication, transmet ses ordres sur diverses
machines qui effectuent les oprations associes et dlivre les produits finis aux clients. La
tche d'une machine, par exemple, est reprsente par le processus suivant:

Processus Machine: :fonctionner

Rpter
Recevoir une commande (prcisement un article)
Transformer l'article
Expdier l'article
A l'infini

Pour un atelier constitu de n machines et donc modlis par n processus concurrents, il n'est
pas vident de synchroniser ces n processus (avec un ou plusieurs processeurs) par les
mthodes procdurales. Par contre, la notion de processus permet de matriser la complexit
d'un systme concurrent. Chaque processus peut tre compar un programme squentiel: il
excute des instructions, l'une aprs l'autre. La juxtaposition de plusieurs processus va
 99

toutefois permettre d'exprimer des activits qui ne sont pas squentielles. Les interactions des
processus entre les objets peuvent tre spcifies travers leurs modles de communication.

Le modle de communication d'une machine avec le $tock amont capacit infinie, les
ressources qu'elle utilise, le stock aval capacit infinie, par exemple, peut tre schmatis
comme dans la figure 3-12. La machine prend un article dans le stock amont. Si le stock est
vide, la machine est bloque; sinon, elle acquiert les ressources associes et transforme cet
article. Dans le cas de stock vide ou de ressources associes non disponibles, cette machine est
bloque, et va tre ractive par deux messages extrieurs: un article vient d'tre aliment dans
le stock amont vide ou des ressources sont redevenues disponibles. Aprs la transformation de
l'article, la machine expdie cet article dans le stock aval et libre les ressources associes. Si le
stock aval est vide ou les ressources associes rclames antrieurement non disponibles, elle
va envoyer un message la machine aval qui consomme dans ce stock ou la machine bloque
par les ressources pour la dbloquer. Ce diagramme fournit une rcapitulation graphique du
comportement temporel de la machine et les interactions avec les entits extrieures. Ce
modle graphique a plusieurs objectifs:

- dcrire le contexte (environnement) dans lequel l'objet fonctionne;

-fournir un support pour identifier les tats lmentaires de l'objet;
- fournir un support pour dfinir le cycle de vie de l'objet;
- identifier les mthodes membres de l'objet;
- identifier les messages potentiels envoys ou reus par cet objet;
- servir comme moyen de communication entre les diffrents intervenants: chefs du projet,
analystes, concepteurs, implmenteurs, etc.

Msg (Stock tait vide et vient d'tre aliment) Dblocage

1 Article non-Disponible
Fourniture d'un Article ....... y
Stock Amont ""' r1 Recevoir .... ~ ~

.,
1 "' Demande d'un Article , Res.
Bioquer J
Acquisition des Ressources
t BonDispoJ

Ressources 1
''
Transformer 1 Dbloquer~ ~
1 1"' Libration des Ressources
A
'
"
Msg (Res. tait n disponible) Dblocage

Stock Aval
1<
Stockage de l'Article
iExpdier '' b
"'
1
~------------------->
Msg (Stock tait vide et un article vient d'tre aliment), Dblocage de Machine Aval

Figure 3-12 Modle de Communication d'une Machine avec Deux Stocks Capacit Infinie
 100

Si plusieurs machines sont identiques ou si elles ont le mme comportement au sens

technologique, on peut les regrouper en une station pour l'optimisation de l'utilisation de la
ressource processeur et l'utilisation des concepts objets -tels que l'abstraction et l'encapsulation.
Une station est un objet processus constitu de n machines, appeles serveurs, qui ont le mme
comportement (mthode fonctionner). Chaque station a une file d'attente amont et une file
d'attente aval communes aux n serveurs (figure 3-13).

... ,
_,Fourniture d'un Article ~ Recevoir 1 Chargement de Serveur
Stock Amont 1
1 "' Demande d'un Article ~

Acquisition des Ressources

,, ' ~

Ressources __, 1 Transformer ~ Serveur Serveurs

ration des Ressources Dispo. J~
,,
Stock Aval _, Stockage de l'Article HExpdier ~
"' Libration de Serveur
Station

Figure 3-13 Modle de Communication d'une Station (Niveau Fonctionnel)

Les processus de la station peuvent tre modliss de deux faons:

- un processus par serveur: la station est dfinie comme une interface qui gre les flux
des articles entre les serveurs. Elle n'intervient pas directement sur l'horloge du systme. On dit
souvent que cet objet possde n processus en parallle [ROSE 92]. La notion de processus est
utilise pour dfinir des mthodes concurrentes de l'objet station.

- un processus pour tous les serveurs: l'objet station prend la responsabilit de charger et
dcharger les serveurs qui lui sont associs. Le serveur n'est plus un processus; il devient un objet
passif qui simule des oprations d'une machine. TI peut tre en tat libre, en tat arrt structurel, en
tat productif, etc. Le comportement de la station est conditionn par les tats de ses serveurs,
des stocks amont et aval, et la disponibilit de ressources associes aux serveurs. Le
comportement de la station est trs similaire celui d'une machine et ne s'en distingue que par son
interaction avec le noyau de synchronisation du systme:
 101

Processus Station: :fonctionner

Rpter
Charger les serveurs en tat libre
Transformer les articles c~gs
Expdier les articles transforms
A l'infini

Les serveurs travaillent en parallle, ventuellement diffrents rythmes. Pour simuler ces n
processus en parallles, l'avancement de l'horloge du systme par le processus de station est
diffrent de celui d'une machine (NB: dans le cas d'une simulation vnements discrets); la
station cherche la fin d'activit du serveur le plus proche, calcule cette dure de transformation et
avance le temps d'horloge du systme de cette dure. Aprs la transformation, la station dcharge
les articles transforms et charge les serveurs qui viennent d'tre librs. Ce processus ne se
bloque que s'il n'y a plus d'articles dans le stock amont et que tous les serveurs sont en tat libres
(figure 3-14) ou si le stock aval est plein et que tous les serveurs sont en tat dchargement. La
station peut tre arrte pour plusieurs raisons; et elle doit tre redmarre quand les conditions
de fonctionnement sont remplies. Notons que dans la figure 3-14 des processus d'une station,
pour simplifier la reprsentation, nous n'avons pas intgr les processus bloquer et dbloquer de
la station.

Etat Serveur

Figure 3-14 Modle de Communication d'une Station

Les moyens de transport comprennent plusieurs catgories: les convoyeurs, les transporteurs
guids, les transporteurs libres, etc. Un transporteur, en incluant les liens avec le stock amont
qui prend des pices, le stock aval qui dpose des pices et les ressources qu'il utilise, doit
communiquer avec une autre entit rseau pour choisir le trajet de transport. Les processus (ou
 102

activits) pnnc1paux d'un transporteur sont: charger des pices, transporter des pices,
dcharger des pices, dplacer vide, bloquer ou dbloquer une activit, etc. Le modle de
communication est illustr dans la figure 3-15. La gestion de message est plus complique que
celle de la machine et de la station par le fait que l'attribut taille de lot de transport joue un rle
dcisif et il peut tre variable selon le type de pices transporter. Nous ne dtaillons pas ici la
circulation des messages.

1
Stock ADimt
1

1
lFoumir lEs Pices..
LI
1lcqurii ~ sPices - \ft
Charger
J~
~c_auisition des
~
PisS ~santes
Re sourees

Msg ~s.D
~Ressource
BIO
l
Stock tait Plein,
1
1 Res nonDispo.
IMIII!'THL1.
1
Msg Dblocage de Pice Insuffisantes W
~achine Amont
Choi: deTraiet
!Dplacer en Charge ~ rraiE :de lm_
......
R1 ~nonD spo. J
'
'~ '~~
w '~ ,, 1
1 Dbloquer
li' 1] sg.Rseau 1 Reseau

1 Bloquer 1
l' )isponible 1
,, J J\
'stock Plei~ ~~
~ .
Choix de ~ ~t
'~ MsgS ocktai ~Plein
.....,. Etat de Su cl
1
1
StockAval
~
Dposer de [1'ices
'] Dcharger
~ Msg Dblocage
1

~ ~
1

1 R se m non Dispo. '

y Smck tait Vide, Libration des ~ ssources
Msg Dblocage de
Machine Aval
--1 Dplacer Vide ~.~
' Trajet de Transfert
Transporteur

Figure 3-15 Modle de Communication d'un Transporteur

Nous pouvons aussi complter les modles de communication pour toutes les entits identifies
dans la phase d'analyse du domaine. Par exemple, un autre diagramme de communication de
machine avec des stocks d'entre/sortie capacit limite (figure 3-16) est diffrent de celui
d'une machine avec des stocks capacit infinie. La capacit des stocks amont et aval de la
machine (des objets extrieurs) modifie, comme on peut le constater dans la figure, le
comportement (mthode fonctionner) de la machine.

Peu peu, les classes d'objets du domaine et leurs comportements sont aussi dfinies.
Remarquons que les modles de communication sont construits au niveau du domaine, ils
 103

peuvent tre simplifis ou enrichis dans une application particulire suivant la complexit de
l'application, les objectifs de simulation et les rles que les objets jouent dans l'application.

Msg (Stock tait plein) Dblocage de Machine Amont

< ---~ Msg (Stock tait vide et vient d'tre aliment) Dblocage
1

1
1
Fourniture d'un Article
sto. capa. Finie Amt. _,
.....
.\1( Article non-Disponible
1 1
1lemande d'un Article
'
1 Recevoir 1

.~ Res no Dispo... ~,
>l Prparer r . ~Bloquer
....
1

f'\cquisition des Ressources 'V

Ressources _, 1 Transformer 1
1
Libration des Ressources
--j Dbloquer l
Msg (Res. tait non disponible) Dblocage

_,
Etat du Stock
'-' Expdier

1
+
Stock est plein
'1 1
Sto. capa. Finie Aval
1
Stockage de l'Article Machine
1

1
1
Msg (Stock tait plein et un article vient d'tre rtir par une machine aval) Dblocage
1

L - - - - - - - - - - -> Msg (Stock tait vide) Dblocage de Machine Aval

Figure 3-16 Modle de Communication d'une Machine avec Deux Stocks Capacit Finie

ID.1.2 Modles des Transitions d'Etat des Classes d'Objets

Lorsqu'on observe des objets dans un systme de production, on constate qu'au cours du
temps, ils passent successivement, de faon prvisible ou alatoire, par un certain nombre de
phases diffrentes, ou tats lmentaires. Le modle d'tat sert reprsenter le cycle de vie
d'un objet ou le diagramme des transitions d'tat d'un objet. On prsent ici cet aspect travers
un exemple des transitions d'tat d'une machine.

Lorsqu'une machine n'est pas mise en service, ou lorsqu'elle est dcrte indisponible pour des
raisons de maintenance ou de modification, elle est l'tat "non engag". Sinon, elle est l'tat
"engag", c'est--dire qu'elle est implique dans le processus de production. Elle contribue ds
lors, qu'on le veille ou non, aux performances du systme de production.

Une machine est susceptible, ds qu'elle se trouve libre, de recevoir un article transformer.
L'tat "engag" n'est donc pas toujours synonyme de "productif': il comporte en ralit
plusieurs sous-tats, dont un dit "productif' et plusieurs tats "arrts". Une machine est en tat
 104

productif lorsqu'elle est en opration normale sur le produit. Cette transformation peut tre
physique (c'est le cas gnral) ou logique, comme dans le cas d'une opration de test qui
transforme un produit " contrler" en un produit "contrl". L'essentiel est que ce moyen soit
effectivement en train de participer l'volution du produit dans le systme de production,
conformment la mission pour laquelle elle est conue.

Une machine peut tre arrte pour plusieurs raisons. Elle peut tre en tat d'arrt structurel et
en tat d'arrt conjoncturel dans les quatre cas suivants.

1) Blocage amont: attente d'approvisionnement en composants. La machine se trouve

en tat de fonctionnement mais, pour des raisons qui lui sont extrieures, elle ne peut participer
la production. Elle se trouve en tat prt--charger (ou en tat disponible) si on utilise les
termes de simulation.

2) Saturation en sortie: attente d'vacuation des composants transforms. C'est le cas

inverse du prcdent, qui provoque le mme effet de blocage de l'activit de la machine. Elle
est en tat prt--dcharger.

3) Rglage pour le changement d'outillage ou de composant. Ce cas d'arrt structurel

est dans une certaine mesure d la nature et la conception de la machine mise en oeuvre
pour une opration donne. Une machine peut donc tre en tat prparation ou en tat prt
charger si la prparation est finie mais qu'il manque des composants en entre. TI est fugitif et
artificiel. En fin de prparation, la machine passe de l'tat prparation l'tat prt--charger.

4) Panne ou maintenance. Une machine peut subir des pannes de toute nature:
mcanique, lectrique, hydraulique, informatique, etc. Ces arrts propres d'une machine
induisent des arrts subis par les produits en cours de fabrication et par les oprateurs en poste
sur cette machine. On dit que la machine est en tat de panne (remarquons que dans la figure
3-17 on ne reprsente que la panne non pr-emptible.). Elle peut aussi tre arrte pour
maintenance ou visite technique. Elle est alors en tat maintenance.

Ces arrts ou pertes de temps seront de nature et d'importance diffrentes selon les processus
de production auxquels ils appartiennent. Ds sont lis la nature de ces processus et a~
individus (objets) impliqus, ou plus gnralement l'organisation de l'ensemble des moyens de
production. C'est pourquoi il est intressant de mettre ces arrts en vidence, ds lors qu'ils
consomment du temps et de l'argent sans faire progresser les articles (produits) dans les
systmes de production.
 105

A partir des tats ainsi numrs, nous sommes en mesure de construire un diagramme de
phase qui constitue un modle des transitions d'tat d'une machine (figure 3-17).

Si le but essentiel de l'activit de production est de faire voluer les produits vers un tat
d'achvement prcis, cette volution, au niveau lmentaire, ncessite la rencontre pendant un
certain laps de temps entre un produit et une machine, un oprateur ou d'autres moyens de
production Cette rencontre, et ceci sera explicit dans la partie simulation par les diffrents
tats d'objets, s'opre au prix d'un certain cot oprationnel. C'est la prolifration plus ou
moins contrle de ces rencontres (tats) lmentaires qui constitue l'activit du systme de
production et c'est l'accumulation des cots oprationnels lmentaires qui engendre le cot de
production du produit (et non le prix de revient, qui intgre bien d'autres cots).

mise en service _ _ !Di_se_h!>ll ~eJYi_e_ _ _ _ _ ~~ _!lOD-Actif

Etats Actifs

~repnse dacti->.
maintenan ann
Etat --1---- Etat --- 1--~ EtatPanne
1 Maintenance
...
- -. - 1,- Dis nible <fin1d -anne
- - - non-Pr-emptlble
.____ _ _..;;.__ __.
acqws1tionet ------------- P
chargement de :
ressources Y
Etat f Etat
1
Prparation ~-~ Prt l Charger
prparation alimentation d' cle

Etat
Productif
fin de transformation

Etat fin d'vacuation

Prt l Dchu er

Figure 3-17 Modle des Transitions d'Etat d'une Machine (Niveau du Domaine)

De la mme manire, nous modlisons les modles d'tat des autres entits relles. Une
ressource utilise par une machine, par exemple, peut tre dans diffrents tats (figure 3-18):

-Etat non-engag: la ressource est hors de service;

- Etat libre: la ressource est mise en service, mais elle n'est pas encore prise par un objet
processus (une machine, une station ou un transporteur);
- Etat prparation: la ressource est acquise par un processus qui est dans l'tat prparation;
- Etat productif la ressource est utilise par un processus pour une opration sur une pice;
 106

- Etat prt--dcharger: la ressource est prte tre dcharge d'un processus;

- Etat panne: la ressource ne peut pas tre utilise par un processus

Figure 3-18 Diagramme des Transitions d'Etat d'une Ressource Partage

Evidemment, une machine peut tre spcialise en des machines particulires comme un robot,
une machine commande numrique, etc. On peut construire, de la mme manire le modle
d'tat correspondant de ces machines [RODDE 90]. La figure 3-19 illustre un diagramme des
transitions d'tat d'une machine commande numrique. Ces tats d'objets conditionnent les
comportements d'objets Q'enchanement de leurs mthodes) et illustrent les modifications des
attributs des objets concerns. Les performances du systme de production sont reprsentes,
dans l'approche oriente-objets, d'une part par les attributs des objets, d'autre part par les
relations entre les objets. C'est le moment que nous aborderons les modles informationnels
des classes d'objets qui dfinissent les caractristiques d'objets.

Table vide et propre

Figure 3-19 Diagramme des Transitions d'Etat d'une Machine Commande Numrique
 107

ill.l.3 Modles Informationnels des Classes d'Objets

Un modle informationnel d'un objet dcrit les caractristiques ou les donnes essentielles de
l'objet et les relations qui persistent entre cet objet et le ~onde extrieur. Une machine, par
exemple, est caractrise par ces donnes. En terme d'analyse oriente-objets, ces donnes sont
appeles les attributs d'objets et elles sont reprsentes dans le modle d'information d'objets.
Ces attributs peuvent tre diffrencis en diffrentes catgories; nous prenons l'exemple de
l'objet machine pour les illustrer.

a) Les attributs structurels caractrisent les aspects fondamentaux d'une machine.

Certains d'entre eux dcrivent les liens logiques entre les diffrents objets, et leur spcification
fine dpend essentiellement de la nature des applications et des conditions d'exploitation. En ce
qui concerne la simulation des flux de production, les principaux attributs structurels d'une
machine comprennent: son identifiant, son cot unitaire d'utilisation, son oprateur associ, les
rfrences de composants fabriquer, les files d'attente d'entre/sortie et leurs caractristiques
(modes de gestion), son implantation gographique, etc. lls expriment l'aspect intrinsque ou
organisationnel de la machine.

b) Les attributs conjoncturels expriment la disponibilit effective des objets ou le

contexte dans lequel doit se drouler la production. lls sont, dans une large mesure, non
modifiables dans le cadre du systme de production lui-mme et reprsentent plutt les
contraintes extrieures comme la prvision de non-engagement, le plan de charge.

c) Les attributs instantans expriment l'tat courant des objets. lls rendent compte en
temps rel des conditions d'utilisation de la machine. En ce qui concerne les attributs
relationnels permettant de la situer dans le systme de production, ils comprennent: rfrence
du produit ou lot de produit en cours, compteur de pice pour le lot en cours, etc. On n'aborde
pas ici les attributs d'tat intrinsques, telles que les valeurs courantes des parmntres du
fonctionnement (tempratures, pression, etc.), sauf la valeur courante de la machine pour
gnrer des indicateurs de sortie dans le but de calcul conomique.

d) Les attributs vnementiels sont ceux qui provoquent l'volution des attributs
instantans. Ce sont l'ensemble des phnomnes dont dpendent le modle des transitions d'tat
de machine un instant donn. Ces attributs principaux comprennent le temps opratoire, le
temps de panne, le temps de retouche, le temps de rglage, le temps d'attente, etc.

e) Les attributs historiques sont ceux qui permettent de rendre compte de faon plus
ou moins dtaille du pass rcent de la machine comme le temps productif, le temps d'arrts
 108

propres (le cumul des temps de panne), le temps d'arrts induits (le cumul des temps d'attente),
le temps en tat rel productif, le temps total observ, etc.

t) Les attributs statistiques sont le rsultat de calculs permettant de compacter les

attributs historiques sur de longues priodes, de manire dgager les lois de fonctionnement
du systme de fabrication concern. Ces calculs fournissent une image trs reprsentative des
capacits relles d'une machine comme la loi sur la dure de panne, le taux de rebuts, le taux
d'occupation, le nombre total d'ordres lancs et termins sur une priode donne, etc.

Attributs
conjoncturels

Pass 1
Pass 1
Pri~e 1
TelDjS
loign proche enclurs

Attributs
vnementiels

~ ~
( Comportement Attributs
d'Objet Concurrent structurels
.~. )
Attributs '
instantans

''
( !Enregistrement )
...v
Attributs

r-
!Compactage 1)
historiques Dcisions
)~
1

~
Attributs
statistiques

Figure 3-20 Relations entre les Attributs d'un Objet Concurrent

Bien entendu, aucune de ces catgories d'attributs n'est a priori fige. Les attributs structurels
eux-mmes voluent en fonction des dcisions prises au vu des rsultats et performances du
systme de production; autrement dit, suivant les attributs statistiques. Certains attributs sont
dfinis aussi comme des mthodes d'aprs le dtail de la modlisation et de la simulation. Tous
 109

les attributs voluent au cours de la production sous l'effet du comportement des moyens de
production (figure 3-20) sauf les attributs conjoncturels qui ont une influence sur l'atelier sans
recevoir de ractions en retour (informations entres dans les constructeurs d'objets).

Une machine peut tre regarde sous diffrents points de vue: organisationnels, processus
(transition d'tat), flux de production, agrgation/dsagrgation au sens de la modlisation,
niveaux de dcision, etc. Au point de vue processus, une machine possde un cycle infini qui
acquiert des articles dans le stock amont, les transforme et les expdie vers le stock aval (voir
le modle de communication). La mthode fonctionner de la machine dfinit ses diffrentes
transitions d'tat possibles, les processus impliqus dans ces transitions et les coordinations
temporelles et spatiales avec d'autres objets. Si nous encapsulons ses activits, une machine
peut tre vue comme une boite noire qui transforme des flux d'entre (FAE) en flux de sortie
(FAS). Sous un point de vue organisationnel, une machine a une file d'attente en amont et une
file d'attente en aval (figure 3-21). Elle peut possder un pointeur vers l'objet "Panne" (un autre
processus) pour son traitement de pannes, un pointeur vers l'objet "Palette" pour modliser son
temps de prparation, un pointeur vers l'objet "Inspecteur" pour reprsenter le contrle de la
qualit de transformation sur des articles. Elle peut interagir avec le contexte extrieur par les
messages "Ordres". L'ensemble de ces objets (agrgation) interagissent et l'enchanement des
activits de ces objets sont dfinis par le comportement (la mthode fonctionner) de la
machine.

0 s 1 Recyclage
k
IPann~
~
'-~

,, ::t
~
-----~ ~k----
FAE
Machine
1
FAS
: ')
IPttte 1

Figure 3-21 Structure Gnrale d'une Machine

L'intrt de considrer un objet machine sous ces diffrents points de vue est d'identifier sa
structure (les attributs) et les oprations associes afin de mieux dfinir les attributs et les
services (fonctionnalits) de la machine en terme objets (figure 3-22). Nous concrtisons des
services identifis la phase d'analyse en des mthodes d'objets la phase de conception par
objet dans les deux chapitres suivants.
 110

Identifiant tat
capacit rfrence de pice ou lot de pice
cot unitaire d'utilisation compteur de pice pour le lot en cours;
implantation gographique
oprateur associ valeur
type de pices compatible avec l'quipement temps de panne
files d'attente d'entre (FAE) temps de retouche
files d'attente de sortie (FAS) temps de rglage
temps d'attente
caratristiques des FAE temps d'usinage
caractristiques des FAS
prvision de non engagement de machine taux de rebuts
plan de charge taux d'occupation
temps productif loi sur la dure de panne (MBTF)
temps d'arrts propre(cumul de temps de panne) nombre d'ordres (lots) lancs
temps d'arrts induits(cumul de temps d'attente) nombre d'ordres (lots) termins
_~JPps_ops_e~ ______________________________________________ _
ordonnancer cette machine
mise en service bloquer la machine
dfinr une rgle de priorit dbloquer la machine
slectionner une opration traiter la panne
saisir une pice visite technique
acqurir des ressources mise jour des attributs
transformer la pice mmoriser les valeurs d'attributs
expdier la pice calculer le taux d'utilisation
librer les ressouces mthodes statistiques
stocker la pice etc.

Figure 3-22 Attributs et Fonctionnalits d'une Machine

De la mme manire, on peut identifier les attributs des autres entits dans les systmes de
production. Un article ou une pice qui circule dans les systmes de production, par exemple,
possde aussi six sortes d'attributs comme ceux d'une machine (figure 3-23).

a) Les attributs structurels caractrisent les aspects technologies de la pice. L'attribut

le plus fondamental concernant la pice est videmment la gamme de fabrication. En ce qui
concerne la simulation des flux de production, les principaux autres attributs structuraux
comprennent: identificateur (nom), matire premire, temps de cycle technique, etc.

b) Les attributs conjoncturels expriment les demandes extrieures et les ressources

disponibles pour une unit de production tels que: ordre de fabrication, en-cours, priorit, date
d'exigibilit, etc.

c) Les attributs instantans expriment l'tat d'avancement de la pice par rapport sa

gamme. Le but recherch en gnral est que le temps de transit effectif de la pice dans le
 Ill

systme de production soit le plus proche possible de son temps de cycle technique. Ds
comprennent: opration et moyens de production en cours, position dans la gamme, tat de
pice, etc.

Pice (Composant)

Nom de la Pice Ordre de Fabrication

Matire Premire Niveau du Stock
Gamme d'Usinage Date d'Exigibilit (Due Date)
Temps de Cycle Technique Date Dbut
Priorit
Dbut d'une Opration
Fin d'une Opration Etat de la Pice
Dbut d'Attente Moyen de Production en Cours
Fin d'Attente (Machine ou Transporteur)
Dbut Stock Oprateur en Cours
Fin Stock Ressources en Cours
etc. Compteur de Temps
Compteur de Passages
Position dans la Gamme
date de Lancement de la Tte de Lot Opration en Cours
date de Lancement de la Queue de Lot etc.
date de Sortie de la Tte de Lot
date de Sortie de la Queue de Lot Temps Moyen d'Attente
Taille du Lot Lanc Temps Moyen d'Opration
Taille du Lot Sorti Temps Moyen de Transport
Cumul des Temps Productifs Loi de Qualit (Taux de Rbut)
Cumul des Temps d'Attente Distribution de Cycle de Production
Cumul des Temps de Transport Rythme de Production
Cumul des Temps en Stock Cot de Production
Cadence de Lancement Cot du Stockage
Cadence de Sortie Cot d'Attente
Coefficient de Perte Cot Actuel
En Cours etc.
Valeur de la Pice

Figue 3-23 Attributs d'une Pice pour la Simulation des Flux de Production

d Les attributs vnementiels expriment l'volution des attributs instantans. Ces

valeurs vont permettre de dterminer avec prcision comment la pice a occup le temps
pendant lequel elle a fait partie du systme de production: dbut et fin d'une opration, dbut et
fin d'attente, dbut et fin de contrle de qualit, etc.

e) Les attributs historiques: il est intressant (et parfois obligatoire) de connatre dans
quelles conditions une pice a t labore dans le but de dgager les lois caractristiques du
 112

systme de production. Ces attributs caractrisent plutt la rpartition des temps passs par la
pice dans le processus de production.

f) Les attributs statistiques rendent compte des lois reprsentatives du flux travers le
systme de production. Ces donnes peuvent, d'une part servir de rfrence pour les rsultats
de simulation destine tester les chances de succs de telle modification, de tel ou tel
scnario, ou les consquences probables d'une dcision ou d'une volution conjoncturelle,
d'autre part, devenir la matire premire d'une comptabilit analytique fonde sur la
connaissance objective de la ralit.

Les attributs des classes d'objets issues de la phase de l'analyse du domaine comme: station,
transporteur, atelier, oprateur, produit, march, client, fournisseur, sous-traitant, prvision,
commande, achat, plan industriel, programme directeur de production, nomenclature, carnet de
commande et de lancement, lot, gamme de fabrication, opration, etc., peuvent tre ainsi
identifis et structurs. Ces trois modles constituent un cahier des charges du domaine. Pour
une application particulire, nous pouvons instancier ou tendre ces classes d'objets existantes,
ou crer de nouvelles classes d'objets s'il n'existe pas de classes similaires. Notons que le cycle
de vie de dveloppement des classes est diffrent de celui du dveloppent de l'application.

ill.2 Construction des Modles de l'Application

Une fois les entits du domaine et leurs fonctionnalits (les attributs et les services qu'elles
doivent fournir) identifies, nous devons les assembler et les mettre en ordre pour construire
un modle d'application. Les classes d'objets sont des moyens de morceler et de structurer une
application pour la rendre modulaire et rutilisable, etc. Souvent, un ensemble de classes
collaborent pour accomplir un but commun: ces classes constituent un sous-systme ou une
sous-architecture de l'application [MONARCID et al. 92]. Un bon sous-systll!e fournit un
guide et une direction pour la conception et le dveloppement d'une application. Ces sous-
systmes sont des entits conceptuelles (qui n'existent pas pendant l'excution du programme).
De la mme manire, chaque sous-systme est compos de sous-systmes. C'est un modle
imbriqu. Chaque sous-systme est caractris par une interface vers l'extrieur. Les sous-
systmes principaux sont pilots par un module principal (dans le cas de simulation objets, il
s'agit d'un noyau de synchronisation qui pilote l'ensemble des objets actifs ou des processus
parallles) qui a une relation logique diffrente des relations d'hritage et des relations
d'agrgation/dsagrgation. Notons que la conception de classes d'objets a un impact majeur
sur la facilit, la rapidit et la qualit du dveloppement d'une application.
 113

Une entreprise est un systme complexe qui comprend plusieurs niveaux d'abstractions. Dans
un systme d'aide la dcision comprenant un module de simulation, plusieurs sous-systmes
existent: la production, l'environnement, la dcision et l'valuation, etc.

eat COIIIJIIIUid par

CLNT ~b---------------~ PRODUIT
ClientiD EN STOCK
Nom
Adresse ProduitiD
Prix de vente
Quantit en stock
eat inclu dans eat ensemble de Quantit prvisionnelle
r---'----"""'1
Dlai de livraison
MARCHE COMMANDE
Clients Identificateur
Clients potentiels ClientiD
ProduitiD
SS-TRAITANT
Quantit Identificateur
Prix d'achat Nom
Dlai de commande Adresse
Dlai d'obtention
IOUItraile

PRODUIT
FABRIQUE
Identificateur Identificateur
Fabriquant eat apcialia de Nom de produit
Nomenclature Identificateur
Prix de fabrication SB-Traitant
Cycle de fabrication Prvision
Vente rel
Prix d'achat
Dlai de livraison

ACHAT
FournisseurID
Identificateur
Matire premire
Nom Quantit
Adresse
Prix d'achat
Date de command
Dlai d'obtention COMPOSANT
FOURNISSEUR Identificateur
eat fourni par
~~----1--_;;.,.;~~----1 Nomdepi

Identificateur Matire premire

Nom 1----------~-~ Gamme d'usinage
Adresse fournit Temps de cycle technique
Date de lancement

Lgende:
COMPOSANT LOT COMPOSANT
~hritage EN OPERATION EN STOCK
7 cardinalit un--un
: cardinalit un--plusieurs

Figure 3-24 Contexte du Systme de Production

 114

Le sous-systme environnement d'une entreprise comprend en gnral les fournisseurs, le

march, les clients, les sous-traitants et les produits commands par les clients. n dfinit le
contexte dans lequel la production se droule. Un objet march est un ensemble de clients qui
commandent ou peuvent commander des produits. Les classes d'objets dcisionnels possdent
des mthodes pour ces dcisions commerciales qui, selon l'tat du systme (capacit, suivi,
finance, etc.), les commandes fermes et les fournisseurs, dterminent la quantit de produits
fabriquer. Un objet commande est donc une association qui a son propre comportement (figure
3-10). Les matires premires acheter (approvisionnements) sont gnres en suivant ces
commandes, les tats des produits et des composants en stock. Un objet achat est donc une
autre association qui est caractrise par les attributs: les composants ou les matires premires
acheter, les fournisseurs que l'on peut choisir, la quantit et le prix des matires acheter, et
la date d'obtention. L'architecture des ces classes d'objets est caractrise par leurs relations
logiques. C'est la phase d'implmentation d'une application que l'on prcise exactement les
interactions. Les modles conceptuels comme entit-association (figure 3-24) sont souvent
utiliss pour reprsenter les rsultats de l'analyse et de la conception d'application.

Le sous-systme dcision est le plus difficile modliser. Les mthodes traditionnelles sont
orientes vers une dcomposition fonctionnelle: diviser le problme en une squence de tches
formant les blocs essentiels pour une application [GERSHWIN 89], [MCPHERSON et al. 86],
[O'GRADY 86] (figure 3-25). Puisque ces entits de dcision ou classes d'objets dcisionnels
(objets rles ou spcifications) sont caractrises par leurs services et non par leur
reprsentation (d'ailleurs, la variabilit des mthodes de conception par objet et des langages
objets influe fortement sur la conception de ces classes), nous ne construisons que des classes
d'objets de base la plus gnrale possible afin de construire des classes plus riches et plus
smantiques par les utilisateurs futurs pour ses applications particulires et donnons des guides
essentiels pour la conception de ces classes dcisionnels.

Deux sortes de dcisions doivent tre modlises: des dcisions implicites et des dcisions
explicites. A la fin d'une opration sur une machine par exemple, une dcision implicite
consiste envoyer cet article trait vers une destination donne et acqurir un article
suivant., dans ce cas l, la machine consulte l'tat d'un objet article concern par l'envoi d'un
message ce dernier (au point de vue de la relation agrgation) pour obtenir le moyen de
l'opration suivante sur l'article et envoie cet article dans la file d'attente correspondante. Ces
dcisions sont ralises par le mcanisme d'hritage et par des relations entre les composants
internes (ou prcisment les relations d'agrgation/dsagrgation). Les concepts comme les
classes abstraites, les fonctions virtuelles, ou les liaisons statiques et dynamiques facilitent,
techniquement parlant, ces implmentations.
 115

Les dcisions explicites comme la dcision d'achat, la dcision de lancement, la dcision

d'approvisionnement, les maintenances, etc., sont trs subjectives. Elles dpendent des outils et
des langages de programmation utiliss. Nous les modlisons par deux approches. La premire
faon est d'instaurer une interface de dialogue avec !~utilisateur (guide d'utilisateur ou
surveillance, chapitre IV) ([MIRY et al. 92], [MIRY 93], [VINCENT et al. 92]). La deuxime
est d'envoyer un message proprement dit un autre objet (commande automatique).

Normalement, cette mthode est virtuelle et abstraite, il faut redfinir quand l'utilisateur
instancie ces classes d'objets pour son application. Ces classes doivent comprendre: dcision
d'achat, dcision commerciale, dcision de prvision, dcision d'investissement, dcision de
lancement, etc. Ces dcisions sont soit noyes dans les mthodes (dcisions statiques) des
autres classes d'objets, soit des messages (dcisions dynamiques) qui font des liens logiques
entre des classes d'objets. Le dveloppement de ces dcisions explicites n'est pas un processus
rptitif.

Le sous-systme valuation est un module d'analyse qui exploite des donnes (indicateurs)
obtenues par la simulation pour valuer les performances du systme (MIRY et al91], [MIRY
et al. 93]). Plusieurs progiciels existant sur le march (ou au laboratoire), permettent de
construire des classes d'objets d'valuation (histogramme, diagramme de Gant, objets
d'affichage, etc.).

Le sous-systme production consiste construire un modle de simulation des systmes de

production. Un systme de production est un ensemble de moyens qui permet une
transformation des matires premires en produits finis. n comprend trois sortes d'entits
modliser ([KELLER 92], [YE et al. 94b]).

1) Un sous-ensemble d'entits de transactions compos des matires premires, des

produits semi-ouvrs, des composants fabriquer, des nomenclatures, des gamms associes
aux composants ou aux produits, des oprations, ainsi que des ordres de production ou de
fabrication que le systme de production peuvent raliser. Ces entits de transactions peuvent
tre des objets physiques ou logiques (objets rles ou spcifications).

2) Un sous-ensemble d'entits physiques dfini l'ensemble des moyens de production et

de manutention, leur rpartition gographique et leurs interconnexions logiques et physiques
(objets physiques ou spcifications).
 Objectifs du Plan Objectifs du Plan Objectifs du

I'T'j

1'
Stra1gique d'Entreprise
Produits fabriquer
Moyens de Production
Directem de Production
Taux et volume agrgs de production
Dlai de livraison de produits
Programme de Production
Date d'exigibilit
Temps de C~Je Technique
-
Perturbations:

J 1
Panne de machine
Opmteurs En-cours

j~~:~~
Echancementde produits - Mainhmance de machine
w Ressources - Commande urgente de clients
Allocaon de ssources
~ -......
~
V1 1
a
~ Plan Directeur .....
,. Programme ,..... Ordonnancement
Ordonnancer , Acvi1de
,. Processus ,.
a -~
~

de Pro~uction de Production r< Production

~- JI'

~ Prvision diommandes
eoJ
clients
-1' Etat du Processus de Production
Variables de Contrle de Processus
J

tj
CD .....
.....
o. Etat d'Activi1 du Programme de Production 0'1
~-
~
g- RETROACTION
~ D~nnine des variables ...,
~ de contrle de haut niveau '
CD partir de variables de
~ contrle de bas niveau
g- Etat d'ActivM de Plan Dictalr de Production

~
g- RETROACTION
a.g Dtermine des variables ...,
: de contrle de haut niveau l'
partir de variables de
contrle de bas niveau
 117

3) Un sous-ensemble d'entits dcisionnelles de gestion/pilotage spcifiant les rgles de

gestion de processus du droulement de la production (objets interactions, incidents ou
spcifications).

Si l'avantage de l'approche objets est de fournir une flexibilit, rutilisabilit et fiabilit aux
systmes modliser, nous devons introduire une dmarche d'analyse pour la construction des
modles de l'application. Comme nous avons constat dans le chapitre II que plusieurs
approches d'analyse existent, nous utilisons la mthode SADT pour spcifier les tapes de la
construction d'une application par !(approche objets puisqu'elle propose une universalit des
concepts et une simplicit d'utilisation.

La mthode SADT est souvent employe au pralable la ralisation du schma directeur,

pour mieux connal"tre l'existant. Elle s'avre galement intressante pour dgager, partir d'une
analyse des besoins et des modles du domaine (figure 2-4, chapitre II), les spcifications
fonctionnelles du modle de simulation concevoir (figure 3-26). C'est dans cet aspect l que
nous proposons notre dmarche de la construction des modles d'application: une dmarche
fonctionnelle du cycle auteur/lecteur pour mieux comprendre l'application construire et ses
principales fonctionnalits.

La mthodologie dveloppe est centre sur l'utilisation d'une technique: la simulation de

processus par l'approche oriente-objets. Cette mthode se dcompose en quatre grandes
phases:

-la prise et l'analyse des donnes (analyse du domaine et analyse de l'application)

- la modlisation
- la simulation
- l'interprtation des rsultats et conclusions de l'tude.

Les diagrammes SADT (actigramme) suivants dcrivent l'enchanement des activits de cette
mthodologie (figure 3-26).

Aprs l'tude de modles du domaine et l'tude de l'application, nous collectionnons les

informations sur l'application tudie, l'environnement, la recherche et les contraintes
d'entreprise afin de produire des classes d'objets de l'application (physiques, dcisionnels ou
informationnels) (figure 3-27) et tablir les modles correspondants de cette application dans le
but de la simulation (figure 3-28).
 Concummee, Clientle, Mareh
Environnement. Fournisseurs
vonlraintes systmes et budgtaires
~~!..!!!~t!lli!ill!!Jrr..-..&-..:........,. Ob 'eetifs

'ne 1 Objets de dcision

Architecture du domaine Objets exprimenlaux
1 Librairie des objets
~ -.} res de eone~ption
L__~..-....:.--:.....L_,

d ModBser
2
1- Modle de

1 tt 'tveloppeurs J ln
Entreprise etses savopmai ~
simulation

Modtle ....
....00
Outils de modlisation
,~
....
Sim
Simuler 1
R sultata
d'valujmon
Crits d'yaluation
Modle de ~
configuration t If\1
S ~
Simulateur
Gnrateur d'appli afion
Contraintes

Meanismeetlogieiel de 'mulation 1---;........;;~

C.R. Simulation Objets d'valualion....,--,.........,i:U

C.R. Exploitation des rsultata

Fjgure 3-26 Schma AO: Concevoir un Systme de Simulation de Production

 Concurrence, Clientle, March
Environnement, Fournisseurs
Contraintes systmes et budgtaires
Modles
du domaine Obiectifs
Dscription
de l'appli. Librairie des objets
du domaine
Dfinir les C.R Exploitation
donnes 1 Liste des besoins des rsultats
ncessaires 1

Clients
t
Expriences
C.R Simulation , . Objets exprimental1

t
Utilisateur 1 Savoir-faire
......
......
Langage objets
13 Donnes SGBD, ere.
\0

application
'f1'
Savoll'- ~ t
aue Bibliothcaire
.-
Gestionnaire e :ressources Valider les Donnes valides
donnes Librairie des objets
14
du domaine
. - - - - - - L - - - - - , Objets
dduits
Structurer dudomai
Mthodes d'analyse
les donnes
en objets

Moale
Entit-association
Figure 3-27 Diagramme Al: Analyser l'Application (les Systmes de Prodtion)
 Modle d'architecture du domaine
C.R. Exploitation _l_ .Q~jectifs
des rsultalB Attente du modlisateur
Spcification statique
et dynamique des objets
/C.R. Dveloppement
Libmirie des objelll

- Treillis de cl11114es
/C.R Classes v81ides

Mthodologies objelll

Outils dbogueUIB t Langage objets Contraintes atelier existant

-
~
Expriences et experts ..------:~-.Modle traduit
1 Traduire ltc.R Vrification
leModle
& a
24
a
Programmeur
1 Modle vrifi
Langage de simulation Vrifier /C.R. Validation
' ~Ile Modle
25

Valider IModlevalid'
le Modle
C.R. Classe modifier 26

Entreprise Sfioir-faire
Mthodes mathmatiques
C.R Modle mn valid

Hgure 3-28 Diagramme A2: ModHser l'Application (Un modle de Systme de Production
 121

IV Conclusion

Dans ce chapitre, nous avons propos une mthodologie d'analyse en nous inspirant des
techniques de l'analyse du domaine et de l'analyse oriente-:-objets dans le but de construire un
cahier des charges pour la simulation des systmes de production.

Ce processus est subdivis en deux tapes: l'analyse du domaine et l'analyse de l'application.

Dans l'analyse du domaine, on tablit le contexte principal dans lequel les informations utilises
dans le dveloppement de logiciels sont identifies, recueillies et organises pour rendre ces
informations rutilisables quand on met jour ou quand on cre de nouveaux systmes
similaires. Le but de l'analyse est d'essayer d'aboutir un consensus sur le vocabulaire et la
thorie d'un domaine: un systme de production est constitu de trois sous-systmes
(physiques, dcisionnels et informatiques) dans lesquels trois populations interviennent
(produits, ressources et moyens de production) et ces trois populations seront identifies
travers cinq types d'objets (physiques, rles, incidents, interactions et spcifications).

L'analyse de l'application prend les modles de l'espace de problme, crs pendant la phase
d'analyse du domaine, comme des entres et se concentre sur l'application courante
construire afin de transformer les modles du domaine en modles d'application. Ces modles
sont reprsents par trois modles d'objets d'application: modles informationnels qui dcrivent
les caractristiques ou les attributs d'objets et leurs relations entre les classes d'objets, modles
des transitions d'tat qui dcrivent le comportement temporel d'objets et modles de
communication qui fournit une rcapitulation graphique de la dynamique ou des interactions
entre les objets (les changes d'informations internes et avec le monde extrieur).

Les rsultats de ces deux tapes d'analyse sont. illustrs dans un schma Al du modle SADT
(figure 3-26) dans le but de fournir des classes d'objets pour la construction des modles de
simulation et des scnarios de simulation. Le chapitre suivant est consacr la mise en ouvre
de ces classes d'objets pour les systmes de production.
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Chapitre IV Conception d'un Modle de Simulation des Systmes
de Production par l'Approche Objet

1 Introduction

La conception concerne la spcification et la modlisation des lments de la solution de

problmes du domaine ([BOOCH 92], [COAD et al. 91]). Concevoir un systme consiste donc
transformer la reprsentation de problmes en une reprsentation de rsolutions. De
nombreuses mthodes ou techniques de conception existent. Certaines d'entre elles en
utilisation sont de type:

- procdural (conception structure),

- orient-donnes (data driven),
-logique,
-orient-accs (une technique pour la conception d'interface utilisateur),
- orient-objets,
- dclaratif,
- etc.

Chaque mthode a ses admirateurs et ses dtracteurs. L'approche oriente-objets est une
combinaison des techniques procdurales et orientes-donnes. Cette approche constitue un
processus de conception qui repose sur un principe d'organisation du logiciel autour des objets
relatifs l'application que l'on souhaite traiter, plutt que sur les fonctions que l'on souhaite
voir ralises (c'est en s'appuyant sur les composants les plus stables du logiciel, ceux qui sont
les moins susceptibles de changer, que l'on peut obtenir la souplesse et la rutilisabilit
recherches). Dans le chapitre prcdent, nous avons analys les systmes de production avec
l'approche objets. Dans la phase de l'analyse, nous essayons de modliser l'espace du domaine
ou le sujet du discours qui est une perception fonctionnelle et partielle du systme rel. Le but
de l'analyse est de produire un cahier des charges qui spcifie la fonctionnalit du systme. En
utilisant le modle objet, ce cahier des charges contient des classes d'objets essentiels du
domaine, leurs structures et les services qu'ils doivent fournir et les relations entre ces classes.

Dans la phase de conception, nous devons tout d'abord dtailler, pour chaque objet identifi
par l'analyse, son comportement et ses intercommunications avec d'autres objets (messages)
afin de satisfaire les problmatiques poses par le cahier des charges de l'application. Ensuite,
nous rexaminerons les classes d'objets du domaine: raffiner, tendre ou rorganiser ces classes
 124

afin d'amliorer la rutilisabilit et la modularit, et de profiter ainsi au maximUm des concepts

d'hritage et de liaison dynamique. Enfin, nous devons ajouter d'autres objets additionnels
exigs par la rsolution logicielle de problmes tels que les objets d'interfaces, les objets
d'application, les objets utilitaires ou mathmatiques, etc: La figure suivante (figure 4-1) dcrit
la relation gnrale qui existe entre l'analyse et la conception.

Figure 4-1 Relation entre l'Analyse et la Conception

La conception par objet (CO) consiste donc d'une part, rexaminer les comportements et les
communications des classes d'objets smantiques (conception de haut niveau ou conception de
l'application) qui reprsentent des entits physiques ou des concepts dcrivant le systme et son
comportement afin d'amliorer la rutilisabilit, la modularit, etc.; d'autre part dfinir des
classes d'objets (conception de bas niveau ou conception des classes d'objets) q refltent la
structure interne du logiciel tels que la hirarchie des classes smantiques, les objets d'interface,
les objets d'application et les objets auxiliaires/utilitaires [MONARCHI et al. 92] (figure 4-2).

Tout objet du monde rel possde une activit (comportement) autonome. Les objets
communiquent entre eux et avec l'extrieur par des messages. Or les mthodes traditionnelles
objets comme la mthode BOOCH [BOOCH 92], la mthode YOURDON ([COAD et al. 90],
[COAD et al. 91]) et la mthode MEYER [MEYER 88], la mthode SHLAERIMELLOR
[SHLAER et al. 92], la mthode OMT [RUMBAUGH et al. 91], fournissent des moyens pour
identifier et dfinir des objets squentiels, c'est--dire, des objets qui fournissent une
encapsulation d'organisation (structure) et certains services prts tre utiliss. On dit souvent
que ce sont des objets squentiels ou des objets passifs [CO:MMUNI 93].
 125

Figure 4-2 Analyse et Conception Orientes-Objets

Dans un modle de simulation bas sur la notion de processus (chapitre TI), un monde rel est
modlis par deux types d'objets: des objets actifs et des objets passifs. Les objets actifs ont un
comportement autonome (on appelle aussi des objets contrles) dont l'volution dans le temps
est dfinie par ses processus. Dans ce chapitre, nous considrons les moyens de production, les
procdures de commande, etc., comme des objets actifs, et les produits, les pices, les
messages qui circulent dans les systmes de production comme des objets passifs (objets
circulants, objets de transactions). Bien sr, nous pouvons faire l'inverse: dfinir les processus
autour des produits et considrer les moyens de production et de transport comme des
ressources pour des oprations effectues sur les produits. C'est un choix sur le cot (effort) de
modlisation et les indicateurs de performance sortis de la simulation projete [BENSLEY et
al. 92]. Nous pensons que les moyens de production sont plus stables par rapport aux produits
qu'ils fabriquent, et surtout que notre objectif de simulation est de rendre ompte des lois
reprsentatives du fonctionnement des systmes de production dans sa globalit. Aprs la
conception du comportement des objets actifs et la conceptualisation des processus de
production, nous construisons, dans ce chapitre, la hirarchie des classes d'objet smantiques
pour la simulation des flux et la hirarchie des classes d'objets pour la rsolution du problme.
 126

La distinction entre la phase d'analyse et de conception par objet est ambigu et imprcise
([CRIBSS et al. 92], [HENDERSON et al. 90]). Si on examine la dfinition des classes
d'objets smantiques, l'analyse oriente-objets concerne plutt la dfinition de la structure de
classes d'objets et l'identification des relations entre ces classes, et la conception oriente-objets
n
concerne la dfinition du comportement et la hirarchisation des classes d'objets. n'existe pas,
lors d'une analyse ou d'une conception par objet, d'une approche purement descendante ou
purement ascendante; en fait il s'agit d'effectuer des "allers-retours", de manire amliorer et
raffiner progressivement le modle conceptuel du logiciel d'application et la hirarchie des
classes d'objets du domaine ([BOOCH 93], [HaL 93], [CASTELLANI 93]).

II Conception du Comportement des Classes d'Objets

Les mthodes traditionnelles de l'analyse et de la conception par objet dfinissent des classes
d'objets squentielles [CARO:ME 93]. Ceci est la consquence du modle de communication
entre objets: lors du lancement du programme, un seul objet est actif, entre le moment o un
message est mis et o le rsultat est reu, l'metteur reste bloqu, et un objet n'est actif que
pendant le calcul de la rponse. Ainsi, un instant donn, un seul message est actif.

Dans le monde rel, les systmes de production sont faits de multiples objets ou groupes
d'objets situs divers niveaux, communiquant entre eux et avec l'extrieur, dans les deux sens,
explicitement ou implicitement. Idalement, il faudrait que chaque objet repre sa production
(entre/sortie) et ses changes de messages (informations) avec d'autres objets (ou avec lui-
mme) d'une part, entre l'organisation et l'environnement du systme d'autre part, afin d'tablir
un comportement plus proche de la ralit dans l'entreprise.

Pour qu'un objet puisse fonctionner plus ou moins indpendamment des autres, il doit avoir un
contexte ou un environnement partiel vis--vis des autres et tre muni d'un contrle interne qui
coordonne les mthodes qui lui sont associes. Cette notion nous oblige munir les objets
d'une activit autonome ou d'un processus de contrle d'activit. On parle d'objets actifs
(contrles), c'est--dire, des objets qui ont une activit autonome et peuvent travailler
indpendamment et concurrentiellement avec d'autres objets et qui sont capables de:

- prendre ou ignorer les messages extrieurs,

- comprendre les messages et dcouvrir des possibilits de connaissances (ou prcisment
des ractions aux messages),
- traiter les messages conformment son comportement aux normes fixs,
- arrter ou reprendre leur activit ou l'activit d'un autre objet actif,
 127

-obtenir des soutiens (aides) d'objets dcisionnels (par le biais d'appel d'unemthode d'un
objet dcisionnel) ou des informations d'environnement (informations de contexte) dans
le but de prendre des dcisions (on dit qu'il communique avec l'extrieur),
-etc.

Dans le but de rduire la complexit de modlisation et des algorithmes de simulation, nous

simplifions les objets du monde rel en deux grandes catgories: des objets passifs et des objets
actifs (appels aussi "agents" en intelligence artificielle). L'objet actif est diffrent de l'objet
passif par ses primitives de cration et de manipulation des processus. Un objet autonome est
un objet actif qui possde un flot local de contrle d'activits (une mthode spciale appele
dornavant excuter ou fonctionner) que l'on appelle un script de processus qui dfinit la
squence d'excution des mthodes d'un objet actif En d'autres termes, les objets actifs ont des
primitives de cration de processus et des mcanismes de communication et synchronisation
entre eux pour qu'ils puissent possder un comportement autonome.

II.l Dfinition du Script de Processus (Comportement) d'Objet Actif

Le schma suivant (figure 4-3) reprsente une organisation gnrale d'un objet actif et son
comportement. TI y a deux modes de communication entre un objet actif et son environnement:

- Communication synchrone ou directe: il existe un lien direct avec l'objet qui met
le message destin cet objet actif Dans le cas d'une machine, par exemple, quand un
transporteur arrive dans le stock amont vide, il va provoquer un message de dmarrage de
l'activit de la machine. On dit aussi que l'objet actif reoit un message direct. Cela peut tre un
message de changement de mode de fonctionnement, par exemple un message comme "Si la
machine NO 5 tombe en panne, alors la machine NO 3 doit cesser de fabriquer le type de pice
4; la machine N 3 peut changer le mode de slection de pice dans son stock amont ou
remettre en cause tout ses heuristiques de fonctionnement". Ces messages sont gnrs par des
objets actif qui ont un lien explicite avec cet objet.

- Communication asynchrone ou indirecte: l'objet actif a un tampon qui reoit les

messages extrieurs. Quand un message arrive, il ne perturbe pas l'activit courante de l'objet.
Par exemple, chaque machine est associe un tampon pour mmoriser les articles (messages)
qui lui sont destins. La machine prend en compte ces articles quand elle est libre. En
informatique, on parle de la communication producteur/consommateur ou bote aux lettres, un
mcanisme qui permet aux objets actifs de communiquer sans ncessiter la prsence simultane
des interlocuteurs.
 128

Dans ce schma, nous distinguons dans l'activit d'un objet actif:

- la perception et l'acquisition: dcodage du message,

- la cognition: reconnaissance et interprtation du message,
- la dcision: mode de raction au message,
- bloquer, dmarrer ou redmarrer l'activit de l'objet et dlguer ou traiter le message
reu: raction plus ou moins autonome de l'objet et/ou communication d'autres objets.

Rejet

Message Dired -1---~.__P.,...E_R_C_EPT_I_O_N___. ~~:n Atten}e)

traiter
tat d'objet

rorganise une /
/
, "tat d'objet
/
Dlguer _!>b~-.Q
Message Direct ~---.,----1
L,----,--T"'

Figure 4-3 Script de Processus d'un Objet Actif (Concurrent)

11.1.1 Perception et Acquisition

Le message direct, parvenant l'objet, sa perception peut tre rejete ou accepte. Le rejet (qui
sans doute n'est jamais total mais peut laisser une trace inconsciente) correspond un filtrage
de ce que l'objet n'est pas capable de percevoir ou de ce que l'objet ne dsire pas percevoir ces
 129

messages. Le message accept peut tre mis en attente lors que l'activit courante de l'objet ne
peut pas tre interrompue, ou tre interprt immdiatement.

Les messages indirects, provenant de l'extrieur et stocks dans le tampon, et les messages
directs mis en attente sont pris en compte un temps donn par cet objet selon son
comportement temporel. Le choix d'un message dpend des alternatives disponibles (rgles de
priorit pour des files d'attente, par exemple) et le mode de fonctionnement de cet objet (flux
tirs ou flux pousss pour une machine, par exemple).

ll.1.2 Cognition

Les relations entre perception ou acquisition et cognition sont trs troites. La cognition est la
reconnaissance, la comprhension, l'interprtation du message compte tenu des connaissances
et des mcanismes d'intelligence de l'objet. Pour une machine, ce pourrait tre, par exemple, le
traitement du message compte tenu des donnes (tat de la machine) et des programmes
stocks (mthodes de la machine) dans sa mmoire. L'arrive d'une pice dans le stock amont,
par exemple, est un message indirect; aprs acquisition de la pice, la machine va chercher
l'opration raliser sur la pice dont les caractristiques de l'opration sont dcrites dans sa
gamme d'usinage. Les donnes instantanes et vnementielles comme le temps d'usinage, les
ressources associes sont mises jour et les donnes historiques de la machine et de la pice
sont archives, etc.

En d'autres termes, la cognition dpend de chaque objet en fonction de ses reprsentations

(structure ou attributs) et de sa capacit rorganiser ces reprsentations (mthodes associes)
sous l'influence de nouveaux messages. Schmatiquement, trois cas peuvent se prsenter:

- le message met jour et mmorise l'tat d'un ou de plusieurs objets (dans une
reprsentation),
-le message modifie ou rorganise la structure d'un ou de plusieurs objets,
-enfin le message peut dclencher une prise de dcision interne de l'objets dans le but de
lancer une action interne ou externe.

Dans les deux premiers cas, les messages dclenchent immdiatement l'excution d'une
mthode squentielle (qu'on appelle aussi procdure ou mthode normale). Ces mthodes
correspondent aux concepts d'objets traditionnels. Dans le dernier cas, les messages peuvent
provoquer un changement du comportement spatial ou temporel, c'est--dire, qu'ils vont
dclencher une mthode concurrente (ou un processus en termes de la simulation qui provoque
un avancement du temps du systme).
 130

D.1.3 Dcision

La dcision consiste choisir, dclencher, arrter ou redmarrer un traitement externe ou

interne selon la signification du message reu, l'tat et la finalit de l'objet.

L'objet peut dlguer le message un autre objet ou l'ignorer s'il n'est pas capable de le traiter.
TI peut aussi faire appel aux mthodes d'autres objets par l'envoi d'un message direct. Par
exemple, une machine trs surcharge peut dlguer un ordre de fabrication (pas au niveau de
l'article) qui lui est destin une machine remplaante si c'est ncessaire. Cet objet assure la
transmission du message reu, labor et codifi vers d'autres objets.

L'objet peut dclencher un traitement interne ou plus prcisment une raction interne au
message: il va

- se comporter diffremment dans sa discussion (une excution des mthodes) avec son
tat courant et les objectifs dduits de sa finalit (sous quelle forme);
- modifier consciemment ou non une dcision, une manire de faire, toutes choses
inexplicables pour quelqu'un d'autre extrieur qui ne serait pas au courant de la
circulation du message (encapsulation des mthodes dcisionnelles d'objets): dclencher,
arrter ou interrompre une action.

D.1.4 Action

Une action se passe dans un contexte. Le contexte dcrit l'ensemble des informations
permettant une action de savoir o il en est dans l'excution de son script de processus (de
son activit). Un processus est une unit atomique d'excution des activits, qui peut tre
virtuellement un processeur ([BUHR et al. 90], [DORSEUIL et al. 91]). Avant de savoir o il
en est dans l'excution de son activit, l'objet va consulter le contexte de son procssus.

Un processus a aussi des tats: il peut tre lu, ligible, bloqu et termin. Quand on passe de
l'excution d'un processus celle d'un autre processus, il y a une commutation (changement)
de contexte: une opration qui consiste remplacer le contexte d'un processus utilisant le
processeur par celui d'un autre processus qui doit devenir lu suite l'arrive d'une action issue
de la dcision (voir chapitre V). Dans la vie courante, c'est comme si nous posons une question
sur un autre sujet.

Les dcisions prises par un objet peuvent conduire aux actions suivantes:

- bloquer un processus inconditionnellement,

 131

- bloquer un processus en attendant qu'un ou plusieurs autres processus soit (soient)

termin (s),
- dbloquer un processus,
- interrompre un processus,
- dmarrer ou arrter un processus,
-etc.

Ces actions causent un changement de contexte. Diffrentes implmentations [SCHIPER 86]

sont possibles: moniteur en Concurrent Pascal, tche et rendez-vous en ADA, coroutine en
Modula TI et en C++. Un objet actif et autonome possde au minimum un script de processus
ou un thread en terme informatique qui dcrit ce qu'un objet doit faire dans sa vie. Ce thread a
aussi une notion de "squentialit" [DAVID 93] dans ce terme qui rappelle le fil de la vie d'un
objet actif. Nous conceptualisons ici les processus des objets au niveau de la simulation des
flux de production. La description sur l'implmentation sera prsente dans le chapitre V.

ll.2 Conceptualisation des Processus de Production

ll.2.1 Opration (Tche)

Une opration est une action d'un objet actif. En terme informatique, c'est une action (tche)
ou une activit du processus. Un systme en temps rel est compos, en gnral, de plusieurs
tches qui s'excutent en parallle. Une tche peut tre:

-active (lue, ligible ou bloque): elle dmarre lorsque la tche tait arrte;
-lue: elle monopolise la ressource processeur pour une dure t;
-bloque: elle suspend la tche appelante pour une dure indtermine.

ll est noter que la quasi-totalit des oprations industrielles (figure 4-4 [BARBIER 89])
peuvent tre formalises partir d'un jeu rduit d'oprations lmentaires en termes de
modification d'tats d'objets: transformation, assemblage, transport, etc.

ll.2.2 Processus

Un processus est une logique d'enchanement d'oprations (tches). Pour notre part, nous
dfinissons un processus par rapport un ou plusieurs objets actifs. Un processus dtermine
indissociablement un ensemble d'oprations excutes par un objet actif. ll est noter qu'un
processus dtermine des contraintes d'antriorit de certaines oprations sur certaines autres et
non pas, sauf cas particuliers d'un processus purement squentiel, une chronologie (thread)
d'enchanement d'oprations.
 132

Opration de Opration de
contrle transport

Opration de
production complexe

Opration de
d'assemblage

Opration de Opration de
Opration de transformation
d'emboitement dformation lastiqu de matire

Opration Opration de Opration de

d'emboutissage tournage perage

Figure 4-4 Une Classification d'Oprations dans les Processus de Production

En fait, un processus rpond lui-mme la dfinition d'une opration dans la mesure o,

considr globalement, il ralise la gense d'objets en aval (sorties du processus) partir
d'objets en amont (entres du processus).

Un processus spcifie donc la dcomposition d'une opration "agrge" en oprations un

autre niveau respectant une logique d'enchanement dtermine. Cette dcomposition est
rcursive et peut tre poursuivie jusqu'au niveau des oprations lmentaires de la figure 4-4.
Barakat [BARAKAT 91] a propos 4 niveaux pour l'abstraction des oprations et des
processus: action, acte, opration et jonction. Pour notre part pour la simulation des flux de
production, nous travaillons sur le niveau acte et opration. Dans la partie suivante, les
 133

attributs et les mthodes pour la construction de modles d'atelier sont identifis et structurs
selon ces deux niveaux.

III Construction de Modles de Simulation

ID.l Architecture de Modles

Un systme de production est un systme ouvert sur de nombreux environnements volutifs

avec lesquels il est en interaction permanente. Les changements de l'environnement induisent
des ractions du systme ou le conduisent des actions anticipatrices. Celles-ci sont ralises,
dans un modle de simulation, par un ensemble de schmas de comportement et de rgles de
conduite (un ensemble de scnarios en terme de simulation) dfinis dans le module de pr-
simulation (figure 4-5).

UTILISATEUR (OPERATEUR)

Systme de Communication
Homme/Machine
INTERFACES

UNITES DE TRAITEMENT

Figure 4-5 Architecture des Domaines d'Application en Vue de la Simulation

Un module de pr-simulation comprend les fonctions configuration, planification et

ordonnancement, modlis essentiellement par des objets d'interfaces smantiques qui
reprsentent les attributs structurels et contingents des objets smantiques tels que les articles,
 134

les ressources et les moyens de production, des algorithmes qui traduisent la logique M.RP.
ou des rgles de pilotage. Les rsultats de la simulation sont traits dans un module appel
post-simulation qui a pour objectif l'analyse et l'valuation des performances de tel ou tel .
scnario dfini dans le module de pr-simulation. Ce module est aussi modlis par des objets
d'interfaces qui reprsentent essentiellement les attributs historiques et statistiques des objets
smantiques (comme histogramme, diagramme de gant, etc.) en incluant des algorithmes
d'analyse et de statistique (comme calcul de~ variances, des moments, des moyennes, etc.). Ces
deux modules constituent l'unit de traitement d'interface homme-machine qui peuvent
fonctionner indpendamment du module de simulation (on parle de simulation hors de ligne).

Constructeur de Modle

Systme de Communication
Homme/Machine
INTERFACES

Librairie de Classes d'Objets

Figure 4-6 Architecture de Construction de Modles de Simulation

Un module de simulation (simulateur) produit certains aspects du fonctionnement dynamique

d'un systme de production afin de rpondre des interrogations sur son fonctionnement
dfinies dans le module de pr-simulation. Notons que la simulation ne permet pas de trouver
de faon directe des solutions des problmes de production (comme les logiciels
d'ordonnancement ou comme les systmes experts). C'est pourquoi les modules de pr- et
surtout de post-simulation constituent une partie trs importante du modle de simulation. La
figure (figure 4-6) montre l'intervention des utilisateurs sur la reconfiguration de scnarios et
de modles de simulation l'aide des classes d'objets dans la librairie et la mise jour de la
 135

librairie des classes. Nous dtaillons ici seulement la modlisation du systme de production,
c'est--dire le module de simulation que nous allons construire.

ill.2 Modlisation de Production

Notre objectif est de reprsenter, selon des degrs de finesse diffrents, le droulement de la
production. Une telle modlisation doit tre structure, intgre et informatisable.

- Structure, pour avoir plusieurs niveaux de dtail dans la description du processus de

fabrication. En conception, on cherche impliquer progressivement l'quipement de
production au fur et mesure des choix technologiques. Inversement, le suivi de la
fabrication conduit ignorer les actions technologiques de l'quipement pour n'en retenir
que leurs effets fonctionnels sur le produit. Pour notre part, nous travaillons sur le niveau
action sous l'aspect fabrication [BARAKAT 91].

- Intgre, par une description explicite de chaque opration non seulement en termes
d'effets (consquences) sur le produit (mthodes associe au produit) mais aussi en termes
de fonctionnement des quipements (agrgation des oprations au niveau processus ou
dfinition des mthodes associes diffrents niveaux des moyens de production).

-Informatisable, en vue d'laborer des outils interactifs de simulation d'ateliers. Nanmoins,

les systmes de production ne sont pas toujours entirement informatisables.
L'intervention d'oprateurs humains joue frquemment un rle essentiel: soit qu'elle
permette des solutions moins onreuses et plus efficaces, soit qu'elle se rvle
indispensable, dans le cas par exemple de la mise en oeuvre de rgles de gestion non
formalisables, de l'exploitation d'un certain savoir-faire ou du maintien d'un certain niveau
de vigilance.

Nous considrons qu'un atelier est constitu den machines qui communiquent par le biais de m
transporteurs. Les produits qu'un atelier peut produire sont modifiables et variables. Les
activits de production se situent en trois niveaux: opration, processus (machine, station,
transporteur, procdure de pilotage) et atelier (figure 4-7).

- Niveau Oprationnel. On identifie ce niveau les diffrentes actions des objets actifs.
Quatre types d'oprations peuvent tre analyses vis--vis des objets actifs et de leur
environnement: transformation, transport, assemblage, dmarrage (dblocage)/arrt
(blocage). La transformation peut tre physique ou logique avec ou sans quipement
 136

associ, etc. L'opration de transport ou d'assemblage peut tre vue comme une
transformation spciale.

- Niveau Processus. On dfinit ce mveau, autour des objets actifs, la squence

d'oprations (macro-opration) qui sera reprsente par un processus.

- Niveau Atelier. On dfinit des rgles de pilotage ou l'interface qui contrlent la

circulation des objets passifs qui seront transforms ou transports par diffrentes
machines ou transporteurs dans l'atelier. Le comportement d'atelier est caractris par
ceux des machines et des transporteurs.

:---JK'- --~;' -----~.-. ----J;' --~,- -------:

Figure 4-7 Modle d'Atelier

La production ne se passe que lorsqu'il y a des produits fabriquer dans l'atelier. Les trois
niveaux des activits de production formalises ci-dessus sont spcifis par rapport aux moyens
de production dans le but de dfinir des dcisions locales qui sont indpendantes de produits
transformer. En fait, la modlisation de production doit inclure non seulement les moyens de
production, mais galement les produits que l'atelier peut fabriquer et les rgles globales de
 137

conduite d'atelier. Nous proposons une structure globale de modle de simulation qui contient
quatre niveaux de modlisation (figure 4-8).

- Niveau Ressource. On dfinit les typologies des ressources (machines, transporteurs,

outils, oprations) et leurs comportements lmentaires sans considrer les caractristiques
des produits fabriquer. En d'autres termes, il s'agit de dfinir des classes d'objets de
moyens de production indpendamment de leurs utilisations contextuelles.

- Niveau Atelier. On intgre ce niveau l'organisation de la production. Autrement dit, on

dfinit la structure ou l'organisation des moyens de production (tlow-shop, job-shop, etc.)
et intgre les gammes de produits fabriquer qui influent les fonctionnement des moyens
de production dans cet atelier.

- Niveau Unit de Production. Puisque la structure de l'atelier et les produits fabriquer

sont dfinis, on dfinit ce niveau des rgles locales pour piloter la circulation des flux
matires (de produits) entre les moyens de production telles que l'affectation des
ressources, la slection d'une opration, etc.

- Niveau Systme de Production. C'est le niveau le plus lev dans le modle de simulation.
On dfinit ici les rgles globales de gestion qui sont en gnral dduites d'un systme de
gestion assiste par ordinateur telles que les rgles de lancement d'un ordre de fabrication,
l'investissement des moyens de la production, la rorganisation de la production, ou
l'adoption d'une autre politique de gestion (passe de la mthode M.R.P. la mthode
juste--temps, par exemple).

/ GPAO / Niveau Systme

(rgles de management) de Production

/ _ rgles locales (priorits)/ Niveau Unit

de Production

/organisation +produit 7 Niveau Atelier

machine,transporteuts
outils, ouvrier, opration Niveau Ressource

Figure 4-8 Niveaux de Modlisation dans la Simulation

 138

ill.3 Intgration des Dcisions dans le Modle de Simulation

Nous avons dfini qu'une dcision, au niveau d'un objet actif, est d~ choisir, de dclencher ou
d'arrter une action (une mthode d'objet). Au niveau du systme, le systme de dcisions
consiste enchaner un ensemble d'actions simples ou complexes conformment aux objectifs
fixs. Comme nous l'avons constat, la simulation ne permet pas de trouver de faon directe
des solutions des problmes de production, nous devons intgrer les dcisions, dans les
simulations traditionnelles, dans les scnarios correspondants (avant l'excution du modle);
puisque la modification (reconfiguration) du modle au cours de la simulation est difficile voire
impossible. Dans l'approche oriente-objets, les mcanismes de liaison dynamique et le
polymorphisme nous permettent d'intgrer les dcisions au moment de l'excution du modle.
Nous pouvons donc intgrer des dcisions dans le modle de simulation de trois faons en
fonction des objectifs souhaits:

-La surveillance: la fonction de dcision n'est pas automatise. TI ne s'agit que d'analyse
de donnes, de visualisation de ces donnes (sous formes graphiques ou textuelles) et
d'indication d'alarmes travers diffrents objets d'interface au cours de la simulation (on
les qualifie de dcisions interactives). L'oprateur (utilisateur) du modle prend des
dcisions selon les contextes et son exprience. Les informations ne circulent que dans
un seul sens: du modle de simulation au systme de communication homme/machine
(figure 4-5). L'information sortie de la simulation est matrialise normalement par les
fichiers de scnarios (ou une base de donnes).

- Le mode guide oprateur: ce mode complte en fait le mode prcdent en apportant des
traitements un peu plus labors. Le systme ne se contente plus de transmettre les
sorties de simulation pour qu'elles soient facilement interprtables par l'oprateur mais il
prend des dcisions (dans les modules pr et/ou post simulation des units de traitement)
et propose l'oprateur des actions possibles que celui-ci n'a plus qu' appliquer.

- Le contrle automatis: il s'agit de la vritable rgle de pilotage automatise de la

simulation, c'est--dire d'une structure en boucle ferme. L'oprateur n'intervient plus
dans les activits de la simulation. Ceci est fait travers diffrents algorithmes ou rgles
de pilotages intgrs dans le module de simulation.

Nous nous intressons ici la structuration et la dfinition de cette dernire sorte de dcision.
Les deux premires faons qui seront en gnral prises en compte par la simulation sont
dfinies aprs la construction du modle de simulation ou en dehors du module de simulation
(simulation hors-ligne), puisqu'elles dpendent du modle de production simuler.
 139

IV Construction des Hirarchies des Classes d'Objets Smantiques

Plusieurs concepts importants doivent tre prsents avant d'aborder les hirarchies des classes
d'objets pour la simulation des systmes de production. Ce _sont les perspectives, les points de
vue, les relations et le cycle de vie des classes d'objets, etc.

IV.l Trois Perspectives de la Reprsentation par Objets

Du point de vue de la modlisation pour la simulation, il est prfrable de regarder les classes
d'objets sous trois perspectives: perspective lmentaire, perspective oriente-modle et
perspective oriente-application ([MCLAREN et al. 88],[YE et al. 92a]) (figure 4-9).

- La perspective lmentaire concerne la construction des classes d'objets de base que

contient le systme, ainsi que les mcanismes pour atteindre la flexibilit et la maintenabilit qui
sont essentiels pour le support de la simulation. Dans cette perspective, deux choix importants
doivent tre considrs: choix d'une approche de simulation qui adapte l'architecture de
simulation dtermine pendant la phase d'analyse du domaine (figure 3-3, par exemple) et
choix d'un langage de programmation objets pour implmenter des objets de base pour la
simulation. La simulation discrte est base sur la notion d'vnement ou de processus. Les
vnements ou processus sont mis dans une liste appele chancier qui est un noyau de
synchronisation du systme (scheduler). Dans l'approche par objet base sur la notion de
processus, le systme simuler est dcompos en un ensemble de processus concurrents.
Chaque processus reprsente une entit qui volue dans le temps par opposition aux autres
entits. Le "scheduler" contrle l'excution des processus et permet de les interrompre ou de
les reprendre. Cette perspective sera dtaille dans le chapitre V.

- Dans la perspective oriente-modle, l'utilisabilit et la comprhensibilit des classes

d'objets sont primordiales, elles doivent donc bien couvrir le domaine modliser. n s'agit en
effet d'laborer un ensemble minimum de classes d'objets (objets de transactions, objets de
moyens de production, objets de dcision, etc.) permettant de reprsenter tout type de
systmes de production. L'objectif est de fournir une librairie de classes d'objets exploitables
pour la construction des modles de simulation afin d'en tester la validit et d'en valuer les
performances. Dans cette perspective, nous ne prcisons pas qu'un objet est actif ou passif.
Tous les objets sont considrs actifs et autonomes: on les appelle classes d'objets contrles
qui encapsulent non seulement les informations, mais galement les comportements temporels
ou dynamiques (interactions entre les objets).
 140

- La perspective oriente-application concerne essentiellement l'enrichissement et

l'instanciation des classes d'objets du domaine, la construction et l'implmentation de nouvelles
classes de l'application et la construction des modles de diverses applications particulires (en
prcisant les rles d'objets (actifs ou passifs) et en connectant ces instances des classes pour
une application) conformment au cahier des charges des applications.

Figure 4-9 Perspectives des Classes d'Objets

IV.2 Les Points de Vue des Objets (Versions d'Objets)

La perception que l'on peut avoir d'un objet varie dans le temps, d'un individu l'autre suivant
le niveau d'observation (contexte). Un objet machine w par diffrents acteurs tels les
concepteurs, les contrleurs, les gammistes ou les oprateurs est diffrent. Dans les systmes
objets, ces diffrentes perceptions correspondent autant de points de vue (perspectives en
intelligence artificielle, vues en base de donnes, reprsentation en conception assiste par
ordinateur) diffrents d'un mme objet. Au sein d'un mme point de we, la connaissance
(mthodes associes) dtenue sur un objet peut voluer, en particulier elle peut tre affine ou
change dans sa vie (on parle de version d'objets).
 141

Les points de vue et les versions d'objets sont orthogonales. Pour un mme objet on doit
pouvoir prendre en compte un nouveau point de vue et/ou en affiner d'autres. Plusieurs
possibilits existent dans les systmes objets. Ces concepts sont pris en compte par trois
mcanismes.

- Une modlisation explicite ou implicite ds points de vue. Une modlisation explicite

consiste enrichir les concepts d'objets (sous diffrents points de vue) et intgrer ces
concepts dans un mme objet. Une machine dans le modle de simulation, par exemple, peut
tre vue sous des points de vue organisationnels, processus, flux, agrgation/dsagrgation,
niveaux de dcision [YE 93], points de vue qui permettent d'identifier ses structures et les
relations associes. Une modlisation implicite (on ne rajoute pas de nouveaux concepts)
consiste utiliser des concepts existants, par exemple l'agrgation, la spcialisation multiple; et
ces points de vue cohabitent au sein de la classe agrge en terme de composition ou de la
classe parent en terme d'hritage.

- Un mcanisme de classification. La classification consiste rechercher quelle classe

une instance (un objet) particulire peut tre rattache [RECHENMANN 88]. Si, par exemple,
la connaissance sur une instance est enrichie, le mcanisme de classification tente de la
rattacher une classe plus spcialise que celle de sa cration (polymorphisme et liaison
dynamique). De manire plus gnrale, la classification permet de prendre en compte
l'volution des connaissances dtenues sur un objet.

-Un mcanisme de multi-instanciation. La multi-instantiation consiste permettre le

rattachement simultan d'un objet plusieurs classes qui ne sont pas directement ou
indirectement des spcialisations les unes des autres ([RIEU et al. 91], [NGUYEN et al. 92]).
Elle autorise donc le rattachement d'une instance des classes comportant des smantiques
diffrentes de celle draine par sa classe de cration. TI ne s'agit plus d'affinage ou d'une remise
en cause d'un point de vue de l'objet mais bien d'un enrichissement de comaissances
smantiquement diffrentes, c'est--dire d'une prise en compte d'un nouveau point de vue sur
un objet.

Bien que la classification et la multi-instanciation prsentent certains avantages, nous nous

intressons plutt la modlisation explicite et implicite des points de vue par diffrentes
relations: spcialisation/gnralisation, agrgation/dsagrgation, association, etc.
 142

IV.3 Les Relations des Classes D'Objets

Au niveau de l'analyse, nous avons dfini qu'une relation est un lien stable entre deux objets
diffrents, qui permet tout moment, connaissant l'un d'entre eux, de connatre l'autre. Dans
les systmes objets, il faut distinguer les relations au niveau de l'application et au niveau des
classes d'objets. Ces deux niveaux fournissent une division naturelle de la conception de haut
niveau et de la conception dtaille (de bas niveau). Les relations au niveau de l'application ont
pour but d'aider modliser l'espace du problme tandis que les relations au niveau des classes
ont pour but de supporter l'implmentation des classes d'objets individuelles.

IV.3.1 Relations au Niveau de l'Application

Dans le processus de dveloppement orient-objets, la phase d'analyse et de conception de haut

niveau consiste modliser l'environnement et la structure du problme. Les classes d'objets
identifies et dveloppes ce niveau correspondent aux entits ou concepts du monde rel.
Les relations entre ces classes sont aussi identifiables dans le monde rel. Ces classes et
relations sont nommes en gnral avec les termes du domaine modliser.

Bien qu'il existe un nombre infini de relations possibles dans l'espace de domaine, trois types de
relations peuvent couvrir l'ensemble des relations: spcialisation/gnralisation, agrgation et
association. Ces trois relations, dcrites au niveau de l'application, sont trs similaires celles
au niveau des classes. La diffrence est dans l'utilisation de la relation et non pas dans leur
dfinition. Une relation au niveau de l'application est une partie de modlisation du domaine,
tandis qu'une relation au niveau des classes est oriente vers l'implmentation des classes.

- Spcialisation/Gnralisation. Cette relation a pour but de dvelopper un modle

hirarchis qui part des concepts abstraits pour dfinir, dans les couches successives
infrieures, des entits qui sont de plus en plus spcifiques. La relation spcilisation est
souvent dsigne sous le nom d'un lien est-un ou d'un lien sorte-de (is-a ou a-kind-of en
anglais). Elle dfinit une relation de pr-ordre (un ordre partiel) et interdit la possibilit des
cycles dans la structure de spcialisation. Bien videmment, une entit peut tre une
spcialisation de plusieurs concepts gnraux (plusieurs points de vue, par exemple). A
l'inverse de la spcialisation qui permet decrire des objets spcifiques partir d'un autre objet,
la gnralisation a pour but de dduire des objets plus gnraux, voire marginaux (objets
abstraits), partir d'un ensemble d'objets qui ont des caractristiques communes. Cette relation
est intimement lie au mcanisme de classification.

-Agrgation. Cette relation, trs utile pour modliser des systmes importants, exprime
le fait qu'une entit peut tre dcrite partir d'autres entits: une agrgation est une union
 143

d'objets formant un objet. Cette relation est souvent dsigne sous le nom d'un lien partie-de
(is-part-of en anglais). Tout systme, et par consquent tout objet, peut tre dcompos en
sous-systmes, eux mme dcomposables en sous-systmes et ainsi de suite jusqu' l'obtention
des sous-systmes ou des objets primitifs. Cette modlisation d'un tout en parties de plus en
plus fines est communment appele hirarchie de parties qui dcrit les liens structurels entre
les parties (objets). On trouve, dans un objet agrg (compos), deux types d'information: les
informations chacune des parties et les informations propres au tout (qui rsultent
prcisment de la composition de plusieurs objets au dpart indpendants). Dans la hirarchie
de parties qui constitue l'objet agrg, ces informations doivent tre stockes des niveaux
logiques donc des niveaux diffrents. Dans l'idal, le tout doit connatre les parties qui le
composent mais ces parties n'ont pas de connaissance du tout.

- Association. Cette relation permet d'tablir un rapport entre deux entits dans lequel
l'une d'entre elles dtient des instances de l'autre. Cette relation a t largement aborde dans le
dveloppement des librairies objets par des classes "conteneurs" ou "collections". Ces classes
dfinissent des protocoles communs pour recevoir, enregistrer ou retourner des instances
qu'elles possdent; mais elles ne modifient pas ces instances (elles passent seulement des
messages ces instances). Dans un modle de simulation, cette relation sert modliser
diffrentes files d'attente, stocks, etc. L'association est diffrente de la relation agrgation par le
fait qu'une association est un lien entre une classe et les "pices" qui profitent des services de la
classe "conteneur"; par contre une agrgation est une relation structurelle entre une classe et
les parties de sa reprsentation.

IV.3.2 Relations au Niveau des Classes d'Objets

Les relations au niveau des classes surgissent quand nous conceptualisons l'implmentation
d'une classe. Souvent l'implmentation d'une classe dpend des instances des autres classes.
Les relations au niveau des classes peuvent tre l'implmentation des relations a-u niveau de
l'application ou l'implmentation des attributs relations entre les classes. Nous prsentons trois
relations importantes: message, composition et hritage.

- Message. La plupart des relations au niveau de l'application (agrgation et

association) sont ralises dans le modle objet par l'envoi des messages entre les instances de
deux classes impliques. Un message est donc une requte adresse un objet demandant
l'excution d'une opration, c'est--dire, une spcification d'une opration xcuter sur un
objet. Le message doit donc correspondre une mthode spcifie dans l'interface publique
d'une classe dont l'instance sera le rcepteur (un slecteur) du message. Une mthode est une
procdure (ou fonction) implmentant la rponse aux messages destins l'objet.
 144

Un message peut galement passer des informations un objet destinataire sous forme
d'arguments. Le lien entre une classe et les classes dont les instances sont figures dans le
message est appel une relation rejers-to (une rfrence dynamique). Le graphe produit par
des envois des messages constitue le coeur de la structure d'un systme objets dans lequel
l'envoi des messages est le seul moyen de communication et de synchronisation.

- Composition. Cette relation est une notion d'implmentation des relations qui
correspondent aux relations agrgations au niveau de l'application. L'encapsulation de la classe
est ralise par la cration des instances d'une ou plusieurs classes. Quand une classe est
assemble partir des instances des autres classes, ces instances ne sont plus des objets
indpendants. L'utilisateur peut ou non agir directement sur ces instances dpendant de
l'implmentation de la classe. Si la classe est une boite noire dont les instances sont
inaccessibles, l'implmentation s'apparente dans ce cas la notion d'encapsulation.
L'inconvnient de cette dmarche est qu'elle oblige dfinir l'ensemble du protocole ce
niveau et qu'elle crase totalement la hirarchie de parties dfinie au niveau de l'application. Si
la classe est we comme un ensemble de composantes accessibles, il devient ncessaire de
contrler l'accs ces composantes (instances). Le problme qui se pose, lorsqu'on veut
modifier la classe, est de savoir si elle est composante d'une autre classe complexe. On voit ici
que la relation inverse partie-de ne peut en pratique tre ignore.

-Hritage. L'hritage est un mcanisme destin l'conomie des systmes: la relation

spcialisation/gnration au niveau de l'application prconise la dcomposition des systmes et
la minimisation de leurs parties communes; au niveau des classes, l'hritage permet les partages
d'objets et autorise la dfinition d'une nouvelle classe partir de la (ou des) dfinition(s) d'une
classe (hritage simple) ou de plusieurs classes (hritage multiple). n faut donc distinguer deux
types d'utilisation de l'hritage: l'hritage pour l'implmentation et l'hritage pour la
spcialisation. L'hritage pour la spcialisation est une implmentation des relations entre les
classes spcifies au niveau de l'application par des relations spcialisation/gnralisation.
L'hritage pour l'implmentation signifie que la reprsentation interne des classes existantes est
utilise pour fournir une partie de la reprsentation interne de la classe dfinir. D'autres
concepts importants lis l'hritage comme les variables de classe, les variables d'instance, la
valeur par dfaut, le polymorphisme, l'hritage statique, l'hritage dynamique, la liaison
dynamique (rsolution tardive), etc., sont bien expliqus dans la littrature ([BOOCH 92],
[CO:MMUNI 90], [COMMUNI 92], [MEYER 88], [COAD et al. 90], [COAD et al. 91],
[MCGREGOR et al. 92], [SHLAER et al. 92], [RUMBAUGH et al 91]), nous n'abordons pas
ici ces mcanismes.
 145

IV.4 Le Cycle de Vie des Classes d'Objets

Pour que la rutilisation joue un rle plus important dans le dveloppement du logiciel, les
classes (composants du programme) doivent avoir une vi~ indpendante de l'application dans
laquelle elles sont originairement dveloppes. Le dveloppement des classes s'adresse la
conception et l'implmentation des entits (objets), qui peut bien videmment aider dans la
rsolution du problme courant, mais ces classes doivent galement rester suffisamment
gnrales pour qu'elles puissent tre rutilises dans le futur projet. Le dveloppement d'une
application peut tre considr comme la coordination des instances de ses classes afin de
produire une solution un problme spcifique ou le dveloppement d'un produit particulier.
La figure suivante (figure 4-10) prsente un cycle de vie de classes qui peut tre orthogonal par
rapport au cycle de vie de l'application (analyse, conception, implmentation, test et
maintenance): l'identification de classes fait partie du cycle de l'application, mais les tapes du
dveloppement des classes sont indpendantes du dveloppement d'une application
particulire. Cette indpendance a pour but de produire une classe qui est un modle le plus
complet possible d'un concept ou d'une entit reprsenter et qui est celle qui sera le plus
probablement rutilise dans les autres applications.

Cycle de Vie
des Classes
Maintenance

Test

Conception Identification
de Classes Cycle de Vie de
l'Application
Cration Test
Spcification des Instances d'Intgration Maintenance

Dveloppment (Cycle du Vie) de Classes Relation entre Cycles de Vie de Classes et d'application

Figure 4-10 Cycle de Vie de Classes et Relations avec l'Application

Une classe identifie dans l'application peut tre dveloppe de trois faons: dvelopper une
classe partir de zro s'il n'existe pas de classes similaires dans la librairie, rutiliser les classes
existantes (c'est--dire crer des instances) ou faire voluer les classes existantes (c'est--dire
 146

spcialiser des classes) si ncessaire. Dans la plupart des outils pour la simulation oriente-
objets, les classes essentielles pour la simulation (au point de we de perspective lmentaire)
sont dfinies comme dans les logiciels (dont nous disposons dans notre laboratoire du .
dpartement): MODSIM ll [BELANGER 90a], Meijin++ [NICOLAS 91], SIM Plus Plus
[ROSE 92]. Le travail essentiel des dveloppeurs est d'tendre ces outils de simulation vers le
domaine de la production.

IV.5 Les Classes d'Objets dans la Simulation des Flux

Dans le chapitre rn, nous avons identifi trois grandes catgories d'objets constituant un
systme de production: objets logiques ou transactionnels, objets moyens de production et
objets dcisionnels. Ces trois ensembles d'objets incluent tous les objets identifis pendant la
phase d'analyse du domaine: objets physiques, objets rles, objets interactions, objets incidents
et objets spcifications; et ils sont reprsents dans un modle de simulation par deux types
d'objets: objets actifs et objets passifs. Le choix d'implmenter une entit du domaine (objet
smantique) comme un objet passif ou actif dpend du cot de modlisation et des indicateurs
de performances sortis de la simulation. Un objet passif est aussi appel objet circulant. Dans la
partie qui suit, nous ne faisons aucune distinction entre un objet passif et un objet actif.
Rappelons justement qu'un objet actif est un objet driv d'un objet Process dans lequel on
peut dfinir un flot de contrle local (script du processus) de l'objet.

IV.5.1 Dfinition des Classes d'Objets de Transactions

Le systme de pilotage d'atelier reoit des informations du niveau de dcision hirarchiquement

suprieur. Les informations qu'il reoit en amont sont des quantits de produits fabriquer
pour une date donne. Un produit peut tre une pice simple ou assembl partir de plusieurs
pices (composants). Chaque produit est affect une classe PRODUIT qui est caractrise
par des attributs: nom de produit, quantit fabriquer, date au plus tt (date prwe de
lancement), date au plus tard (dlai de livraison), prix de vente, nomenclature, priorit
(confiance aux clients), et des attributs caractrisant ses performances: cot de production,
temps de production, temps d'avance/retard, etc. Les attributs sont essentiellement drivs d'un
systme de GPAO et les mthodes associes sont issues principalement de la logique M.R.P.

Si un produit fabriquer (ordre de production) est simple, il correspond un ordre de

fabrication (classe LOT), sinon, nous devons suivre sa nomenclature en utilisant la mthode
M.R.P. pour calculer, pour chaque composant, sa quantit fabriquer, la date au plus tt et au
plus tard, sa priorit, etc. On a donc besoin d'une classe NOMENCLATURE qui est une
arborescence des composants pour faire le lien logique entre le produit et ses composants. Ces
 147

nomenclatures dfinissent l'ordre pratique d'utilisation de diffrents composants et la hirarchie

d'exploitation.

Les composants ou pices sont des entits relles qui vont subir des transformations dans le
systme de production. Ds appartiennent une classe COMPOSANT (PIECE) qui inclue non
seulement les attributs (structurels et conjoncturels) induits de la classe produit (lien logique),
mais galement leurs propres attributs (instantans, vnementiels, historiques et statistiques).
Leurs mthodes dfinissent les relations entre leurs attributs, les liens avec les produits
travers la nomenclature et les liens avec les moyens de production travers la gamme de
fabrication. La mise jour des valeurs des attributs d'un composant est fait par les
comportements des moyens de production. (Notons que nous n'avons reprsent que, dans la
figure 4-11, les attributs essentiels des classes d'objets concernes, les attributs dtaills, une
pice par exemple, peuvent rfrencer aux modles informationnels d'objets (figure 3-23)).

La gamme de fabrication d'un composant (ou d'un produit) est l'ensemble des oprations que
doit subir ce composant dans le systme de production. La classe GAMME est donc une liste
d'oprations qui dcrit les tches effectuer squentiellement sur les matires ou les
composants pour aboutir un produit fini. Les mthodes essentielles sont dfinies dans la
classe abstraite suprieure (liste simple, liste double, ou tableau dynamique, etc.).

Produit Pice(Composant) Opration

Nom du Produit Nom de Pice Nom d'Opration

Nomenclature Matire Premire Priorit
Composants Date de Livraison Date de Dbut
Prix de Vente Date de Lancement Date de Fin
Cot de Production Priorit Temps Opratoire
Priorit Gamme Principale Temps de Prparation
Dlai de Fabrication Gamme Secondaire Temps d'A~te
Stock Machine Utilise
Loi de Commande Cycle de Production
Temps d'Attente Moyen
Temps d'Attente par Opration
Valeur Ajoute
En_cours

1 1 Position dans la Gamme

l Nomenclature 11------l~~ Temps d'usinage 1-------::~~J Gamme 1
Machine Utilise

Figure 4-11 Liens entre Produit, Pice et Opration

 148

La classe OPERATION est la description d'une tape de fabrication sur une pice qui contient
comme attributs: le temps opratoire, le type de machine ncessaire, la priorit (par rapport au .
chemin critique), la date de dbut et de fin de l'opratio~ etc. La gamme de production est un
ordre partiel (en d'autres termes, il peut exister dans une gamme un certain nombre
d'oprations ralisables dans un ordre quelconque) mais la structure de reprsentation (tableau
ou liste) est un ordre linaire. Nous devons donc dtailler l'objet opration pour qu'il permette
de modliser cet ordre partiel. n s'agit en effet de raffiner l'objet OPERATION en
TRANSFORMATION, ASSEMBLAGE et TRANSPORT (figure 4-12) afin d'inclure des
attributs pour dfinir la relation de l'agrgation/dsagrgation des composants (l'assemblage est
une opration effectue sur plusieurs composants diffrents en mme temps; le transport est
une opration qui agit sur un composant ou un lot (plusieurs composants)). Le mcanisme
polymorphisme nous permet d'implmenter cette relation d'association.

Notons que les oprations constituant les gammes de fabrication sont affectes aux moyens de
production de manire dynamique, c'est--dire que lorsqu'une opration est termine sur une
pice, la consultation de la gamme va indiquer un couple opration/moyen effectuer ensuite.
Pour chacune de ces oprations, on explore le parc de moyens candidats (s'ils existent)
utiliser, en valuant par exemple un critre de cot, ce qui permet de slectionner un couple
opration/moyen dynamiquement permettant de l'excuter. Ceci est au coeur de la procdure
de simulation; la recherche d'un quipement pour un ensemble de moyens candidats se fait en
trois temps:
r - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ~
1

Transformation Assemblage Transport

Identificateur Identificateur Identificateur

Etat Etat Etat
Temps Opratoire Rfrence des Composants Temps de Montage.
TempsdeFTparation Temps de Frparation Temps de Dmon~
Temps de Dchargement Temps de Montage Date de Dbut au Plus Tt
Date de Deut au Plus Tt Date de Dbut au Plus Tt Date de Dbut au Plus Tard
Date de Dbut au Plus Tard Date de Dbut au Plus Tard Temps de Transport
Date d'Exigibilit Date Dbut Date Dbut
Date Dbut Date de Fin Date de Fin
Date de Fin Machine Utilise Position de Dpart
Machine Utilise Ressources Utilises Position d'Arrive
Ressources Utilises Identificateur Compos Transporteur Utilis
Ressources Utilises

Figure 4-12 Structure des Objets Transformation, Assemblage et Transport

 149

1) Dtermination des machines susceptibles d'excuter cette opration {par consultation

des caractristiques de l'opration concemante dans la gamme);

2) Pour chacune de ces machines:

- dtennination des ressources de transport candidates pour acheminer la pice de la
machine actuelle vers la machine destination ainsi que de la disponibilit et du
cot de ce transporteur;
- dtermination du cot de l'opration sur la machine destination et de la capacit de
cette machine.

3) Enfin une phase de choix, base sur l'estimation des cots, des dlais ou des
combinaisons des cots et des dlais, ce choix est alors traduit par diffrents algorithmes
implments dans les files d'attente aval de la machine actuelle.

Cette procdure peut sembler complexe et onreuse, cependant elle sera exploite en regard de
la structure du systme de production et des gammes de fabrication modliser.

Les demandes exprimes par le niveau de dcision hirarchiquement suprieur donnent lieu au
lancement de articles {pices) dans l'atelier. La notion correspondant cet ordre de fabrication
dans le modle de simulation est le concept lot. Les principaux attributs structurels et
historiques de la classe LOT comprennent: contenu du lot (rfrence de composant), taille du
lot lanc, taille du lot sorti, date de lancement, date de sortie, etc., et des attributs de
performance: taux de rebuts, cadence de lancement, cadence de sortie, coefficient de perte,
cumul des temps d'usinage/prparation, etc., qui sont aussi des mthodes prdfinies par cette
classe d'objet.

La notion de lot est une notion de groupement. TI peut servir comme unit de flux dans la
simulation, c'est--dire dans le mme tat d'avancement. L'individualisation des pices dans le
lot nous permet d'observer plus finement les donnes (vnements) de la production. Dans
notre modle de simulation, la notion de lot est utilise comme une unit de lancement, il
correspond ventuellement un lot de transport (si le transporteur peut transporter plusieurs
pices en mme temps). Les units de base de la production est la notion de pice (article).
L'automatisation du dcoupage de lots ou groupement de pices pour l'opration transport
dpend des caractristiques du transporteur et des pices concernes. Ces fonctions
implmentes dans les mthodes de l'objet transporteur seront prcises au moment de la
construction du modle de simulation par les utilisateurs.
 150

Le modle conceptuel de ces classes d'objets transactionnels peut tre schmtis, en suivant
un formalisme entit-association tendu, comme le montre dans la figure 4-13.

a un ou non ,compos de

~ssocie un , , : ~

tf
associ
Ordonno assoCie , -est un
,,, , ti t
conen
par estun
J;.,
.-----G.!..a-rn....l.rn-e--...!;' , compose
Gamme de
d'Ordonnancement Fabrication

associe
1 Machine ~ comprend
est un type Moyen de
compren Production
r-------.,
Transporteur

Figure 4-13 Modle Conceptuel des Objets Transactions

Notons que la vision des moyens de production qui figurent dans le schma prcdent est
considre comme statique (ou une vision fonctionnelle), les points de vue dynamiques
(comportements) sont dtaills dans leurs modles de communication de processus (chapitre
ITI) des objets correspondants. La gamme d'ordonnancement d'un produit peut tre une
instance de sa nomenclature ou une suite de phases d'ordonnancement qui contiennent une
suite d'oprations raliser successivement sur une mme cellule de gestion (unit de
production) ou sur un lot (unit du flux) [YE 90]. Les gammes d'ordonnancement sont utilises
dans la planification moyen terme et les gammes de fabrication servent l'ordonnancement
court terme et l'affectation des moyens de production trs court terme. Les liaisons entre le
systme de commande de la production et les gammes sont dcrites dans la figure 4-14. La
plupart de ces fonctions sont programmes par des units de traitement dans le module de pr-
simulation pour dfinir les scnarios de simulation. Certaines d'entre elles sont implmentes si
possible dans le modle de simulation comme l'affectation des moyens de production, le
dgroupage/groupage des pices, etc.

IV.S.2 Dfinition des Classes d'Objets des Moyens de Production

Les classes d'objets des moyens de production comprennent deux grandes catgories: les
ressources et les agents [YE et al. 94a]. Les ressources tels que outils, outillages et
oprateurs, sont tous des objets rentrant dans le fonctionnement d'un atelier hormis les
 151

machines, les transporteurs et les pices. Elles sont caractrises par leur exclusivit,
partageabilit, leur allocation dynamique, leur aspect consommable, etc. Nous pensons que
leurs fonctionnements ou leurs utilisations peuvent tre dfinis implicitement comme des
mthodes normales qui seront appeles par des messages des classes "agents". Cette
simplification ayant pour objectif de rduire la complexit du modle et des algorithmes de
simulation, en minimisant et en rationalisant le travail de modlisation.

Objectifs de
Prvision Production

Organisation Long Terme

Programme de
Production
r-----"------, Commandes
Planification Prvisions de Ventes
des
Approvisinne-
~------.Programme
ments d'Approvisionnement
Programme
Oprations de Fabrication
Indpendantes
Jalonnement
des Lancements (Ordonnancement
(ou des lots) Prvisionnel)
Squencement
des Lancement
.------li"--...;;..;...;__.....,

SUIVI

Figure 4-14 Schma du Systme de Commande de la Production

Les objets "agents" comprennent les machines, les stations, les transporteurs et les rgles de
conduite d'atelier. Ils sont tous drivs d'un objet "Process" dont l'activit est autonome. Les
rgles de conduite bloquent et dbloquent des processus physiques, ce sont des processus
logiques modliss selon un modle d'atelier concret. Les machines, les stations et les
transporteurs sont modliss comme des processus physiques (ou comme des processeurs
virtuels), ils absorbent des entits en entre et les restituent en sortie aprs un dlai dpendant
de leur comportement et des entits traites.
 152

IV.5.2.1 Les Ressources

L'tude des diffrents types de ressources au sens le plus gnral a permis de dgager 4 critres
qui permettent de modliser leurs proprits, tant en ce qui concerne leur nature que
l'utilisation qui en dcoule. En voici les caractristiques:

- Exclusivit. Une ressource exclusive ne peut tre alloue un instant donn qu' une
seule des oprations qui en ont besoin. En d'autres termes, elle ne peut tre alloue une
opration qu'aprs avoir t libre par l'opration prcdente.

- Partageabilit. Une ressource partageable signifie qu'elle peut tre affecte

plusieurs oprations (tches). Ces affectations peuvent tre statiques ou dynamiques
(l'affectation peut tre modifie en cours de simulation). Une affectation de ressource
partageable est exclusive. En fait, une ressource peut tre la fois exclusive et partageable.
L'exclusivit a le trait aux oprations alors que la partageabilit est lie aux agents
(quipements) et aux pices (objets transactionnels).

- Allocation Dynamique. Quand l'utilisation de la ressource est termine, elle peut tre
alloue pour un autre usage et, si besoin, tre transporte vers son nouveau lieu d'affectation.

-Consommable. Une ressource consommable (nergie par exemple) est susceptible de

s'puiser et peut ncessiter alors un certain dlai pour tre de nouveau utilisable. La ressource
est alors rinitialise une quantit donne fixe ou alatoire. Une ressource non consommable
(outillage par exemple) peut causer un verrouillage mortel (deadlock) avec une autre ressource
non consommable. De plus, une telle ressource a une certaine probabilit de tomber en panne
et un certain dlai de rparation. Les ressources consommables peuvent tre optimises par
leur quantit et leur frquence de rapprovisionnement, les ressources non consommables par
leur nombre et leurs algorithmes de gestion.

Une ressource autonome se dplace elle-mme vers le lieu o elle est demande. Dans ce cas, il
vaut mieux la reprsenter comme un agent. La distinction des moyens de production en
ressources et agents est donc subjective, elle dpend de la finesse et de l'objectif de la
modlisation. D'autres critres tels que la mobilit de la ressource ou le mode de classement
des requtes peuvent tre ajouts, nous nous intressons aux trois premiers critres et nous les
caractrisons comme des attributs gnraux de l'objet ressource.

La gestion. des ressources peut tre supervise par un allocateur de ressource, qui s'occupe
d'organiser les diffrentes requtes (messages) qui demandent l'allocation. Une requte contient
la dure d'utilisation prvue, le nombre d'units de ressources, le lieu o la ressource doit tre
 153

mise sa disposition (c'est--dire l'emplacement du demandeur) et une priorit dtermine par

le demandeur et par l'opration raliser. L'allocateur de ressources (qui est un algorithme
d'une file d'attente des ressources) commence par vrifier si le demandeur n'a pas dj fait
l'objet d'une allocation statique de ce type de ressource.. S'il existe un tel lien, l'allocateur
rpond celui-ci en dsignant la ressource, avec une date de disponibilit immdiate. Sinon,
l'allocateur doit chercher d'ventuelles ressources libres du type demand. S'il en existe,
l'allocateur doit en slectionner une (au sens d'un critre cod dans son algorithme). S'il n'y a
plus de ressource libre du type demand, alors l'allocateur de ressources en avertit le
demandeur, en lui indiquant ventuellement une date de disponibilit au plus tt, calcule
d'aprs la dure d'utilisation prvue des requtes en cours de service. L'allocateur ne s'occupe
pas de la raction du demandeur (un objet actif) qui est code dans les mthodes concernes du
demandeur. Lorsque l'utilisateur d'une ressource libre celle-ci, il en avertit l'allocateur, qui
explore alors sa liste de requtes afin de tenter d'en satisfaire un nouveau demandeur.

IV.5.2.2 Les Agents

Ferber [FERBER et al. 88] a dfini un agent comme une entit physique ou abstraite, qui est
capable d'agir sur elle-mme et sur son environnement, qui dispose d'une reprsentation
partielle de cet environnement, qui, dans un univers multi-agents, peut communiquer avec
d'autres agents, et dont le comportement est la consquence de ses observations, de sa
connaissance et des interactions des autres agents. Les agents sont, dans notre modle de
simulation, implments comme des objets actifs drivs d'un objet "Process" et ont des
comportements relativement autonomes. On appelle aussi des objets contrles ou autonomes.
La notion de Process sert principalement modliser les moyens de production qui effectuent
les oprations sur les pices. L'objet Process est donc caractris par une file d'attente en
entre pour arranger les pices arrives (ventuellement une liste d'oprations acceptables par
ce processus), par un processus qui dcrit le changement d'tats des pices reprsentant les
oprations qu'il est capable d'effectuer et le changement d'tats du processus qui modlise les
transitions possibles d'tats d'un processus, et par une file d'attente en sortie pour dposer les
pices transformes. Un objet Process a besoin d'une autre file d'attente (figure 4-15) pour
cooprer (synchroniser et communiquer) avec d'autre processus (c'est--dire pour traiter et
stocker les messages directs) et une rfrence des ressources associes (lien statique).

Toutefois, un objet Process peut n'effectuer aucune opration de transformation sur les pices,
pour pouvoir modliser par exemple une opration de transport, un stock oti une rgle de
pilotage des oprations. L'objet Process sert donc modliser les moyens de transformation
(machines, stations, postes de travail, etc.), les moyens de transport (chariots, convoyeurs,
transporteurs, etc.), les rgles de conduite d'atelier, etc.
 154

F.AE. F.AS.
~>11111~-----~ --~IIIII~
File d'Attente des Msg Asynchrones File d'Attente des Msg Asynchrones Sortis

Allocateur des Ressources

Figure 5-14 Structure du Process (Objet Actif du Point de Vue Processus)

IV.5.2.2.1 Types des Mthodes

Nous avons construit les trois modles des objets actifs (modle informationnel, modle de
communication et modle de transitions d'tat) dans le chapitre prcdent. Nous dtaillons
donc ici le quatrime modle: modle de processus. Avant de dtailler, pour chaque objet actif
(agent), ses processus ou mthodes qui figurent dans le modle des transitions d'tat, il faut
bien tudier le modle de communication pour dfinir son comportement: la mthode
fonctionner (ou excuter). C'est une mthode virtuelle sans paramtre qui doit tre surcharge
par les utilisateurs; puisque chaque agent a un comportement diffrent des autres. Mais nous
pouvons construire des macro-comportements dans la mthode fonctionner qui appelle des
mthodes virtuelles ou abstraites qui seront dfinies ultrieurement par les utilisateurs.Par
exemple, la mthode fonctionner (comportement temporel) d'une machine peut tre
schmatise comme une boucle infinie (figure 4-16).

Quatre types de mthodes peuvent tre distingues dans la mthode fonctionner d'un agent: les
mthodes accs, les mthodes gnrateurs d'vnements, les mthodes transfol'IQ1l.tions et les
mthodes tests. Ces types de mthodes sont plutt caractriss par leur nature d'utilisation.

Mthodes Accs

Une mthode accs est une procdure dont l'objectif est d'accder aux valeurs d'un objet. Elle
peut tre parmi les suivantes:

-Une mthode Crer (constructeur), cre une instance d'une classe d'objet,
- Une mthode Lire, lit les valeurs des attributs d'un objet,
- Une mthode Ecrire, met jour les valeurs des attributs d'un objet,
-Une mthode Supprimer (destructeur), efface une instance d'une classe d'objet.
 155

Machine::fonctionnerO
Rpter
Si le stock amont est vide
bloquer et sauvegarder l'tat de la machine et rendre le processeur au scheduler
Si le stock amont est plein
rveiller la machine bloque par ce stock
Finsi
Prendre l'article dans le stock amont et acqurir les ressources ncessaires
Transformer l'article et mettre jour les informations
Si le stock aval est plein
bloquer et sauvegarder l'tat de la machine et rendre le processeur au scheduler
Si le stock aval est vide
rveiller la machine bloque par ce stock
Finsi
Expdier l'article dans le stock aval et librer les ressources acquises
A l'infini

Figure 4-16 Mthode "Fonctionner" (Macro-Comportement) d'une Machine

Une mthode accs est assigne un message destin fournir une (des) valeur(s) d'un objet.
Les mthodes accs sont en gnral les plus rutilisables, non seulement dans la mthode
fonctionner, mais galement l'intrieur de chaque mthode (service) qui figure dans le modle
des transitions d'tat. Ces mthodes sont en gnral publiques et sont: 1) appeles de manire
synchrone (non bloquante) par d'autres objets et 2) dfinies pour tous les objets et
indpendantes du changement d'tat figur dans le modle des transitions d'tat d'objets.

Mthodes Gnrateurs d'Evnements

Un gnrateur d'vnements est une mthode qui produit un vnement destin un objet
rcepteur prcis ou un ensemble d'objets rcepteurs. C'est une mthode dont 1) la rponse
d'vnement est trs diffrente selon l'tat de l'objet rcepteur, 2) cet vnement peut perturber
le comportement qui figure dans le modle des transitions d'tat et 3) elle peut tre appele de
manire synchrone ou asynchrone (communication bloquante), dpendant de la conception du
modle de communication. L'objet qui gnre l'vnement synchrone attend immdiatement la
rponse de l'objet rcepteur. TI y a donc un retour du message. Dans le cas d'un vnement
asynchrone, l'objet qui gnre l'vnement continue son excution et cet vnement sera pris en
compte par l'objet rcepteur en cas de besoin.
 156

Mthodes Transformations

Une transformation est une mthode dont l'objectif est un calcul, une transformation des .
donnes ou une activit. Dans les deux premiers cas, cette mthode consiste convertir des
donnes d'entre en des donnes de sortie (bien sr sous une autre forme). Dans le troisime
cas, la transformation va durer un certain moment et va provoquer ventuellement des
changements d'tat d'objets. La mthode transformation peut utiliser ou appeler des mthodes
accs pour lire ou crire les valeurs d'attributs d'objets; elle peut aussi gnrer des vnements
synchrones ou asynchrones. Ces mthodes seront raffines dans le modle de processus.

Mthodes Tests

Une mthode test permet de faire un choix de direction dans le programme et de passer le
contrle l'instruction choisie, ou d'tablir des boucles en cas de problme d'itration. Cette
mthode est normalement utilise pour dfinir la prcondition de la transformation ou de la
gnration d'vnements. Dans le modle des transitions d'tat, quand l'objet passe d'un tat
l'autre, il y a en gnral une mthode test associe.

Dans un modle objets, les objets interagissent par le biais d'vnements et de mthodes
accs. Ces deux types d'interactions n'ont pas la mme nature dans le temps. Quand un objet
gnre un vnement, l'objet rcepteur peut ou non prendre en compte cet vnement. On peut
donc dfinir des communications asynchrones entre les objets. Par contre, quand un objet
accde aux valeurs des attributs d'un autre objet, l'accs aux donnes se fait en mme temps
(conceptuellement) que l'excution de la mthode de l'objet rcepteur. On appelle cela une
communication synchrone entre les objets. Nous dtaillons dans la suite les mthodes
bloquantes (processus) par quelques exemples comme les mthodes d'acquisition d'un (des)
article(s) et d'expdition d'un (des) article(s) dans la machine et la station.

IV.5.2.2.2 Dfinition des Processus d'une Machine

Dans la figure 4-15, nous avons construit la structure de base d'un processus. Une machine est
un objet driv de l'objet "Process". Elle prend l'article (pice) dans la file d'attente d'entre
(FAE). Si la FAE est non vide, la machine va en choisir un selon une rgle de priorit dfinie
par l'utilisateur et va charger les ressources ncessaires selon un algorithme d'allocation de
ressources. Si la FAE est vide ou les ressources demandes sont non-disponibles, la machine
passe l'tat arrt structurel et l'activit de la mthode recevoir est bloqu. La mthode
d'acquisition d'un article (recevoir) est schmatise dans la figure 4-17. Notons que cette
mthode s'excutera aprs la mthode expdier et ds que cette mthode se termine, elle lance
la mthode transformer. Cette mthode va gnrer un vnement (un message de dblocage)
 157

vers la (les) machine(s) qui alimente(nt) cette file d'attente si elle est pleine. Diffrentes rgles
de dcision (objets dcisionnels) peuvent tre intgres dans le droulement des activits de ce
processus:

- slection d'une pice fabriquer (choix d'un mode de gestion de file d'attente),
- affectation des ressources appropries (choix d'un algorithme),
-etc.

.... .. - - - - - - - - - ... - - ... 1

traitement de
: panne non pr-emptible :
oui

affectation de ressources (choix d'un algorithme)

non

non

prise de l'article de la file d'attente

. - - - - - - - - - - . - - - - t dbloquer la machine amont

r ___ v_ __ _
1

: transformer 1

Figure 4-17 Mthode d'Acquisition d'un Article par la Machine :: Recevoir (Item*)

Aprs le processus de transformation (mthode transformer), la machine va eXpdier l'article

transform dans la file d'attente de sortie (FAS). Si la FAS est pleine, l'activit du processus
expdier est bloqu, sinon, la mthode met l'article dans la FAS et gnre un vnement vers
la(les) machine(s) qui consomme(nt) des articles dans cette FAS si elle est vide. Diverses
 158

mthodes "accs" utilises par le processus d'acquisition et d'expdition d'articles peuvent tre
identifies dans le modle de communication de la machine. La figure 4-18 schmatise la
mthode expdition.

1
r - - - - - - - -

traitement de ,
oui
:_ p~~ ~o~ p::e~p~b!e_:

, '
Libration de ressources - - - ~ Ressources , 1
... .. - . -
.
non oui

insertion de l'article dans la file d'attente insertion de l'article dans la file d'attente

dbloquer la machine aval

r - - - - - - - - - - - - - - - - 1

Figure 4-18 Mthode d'Expdition d'un Article par la Machine: expdier (Item*)

Une machine peut tre en panne. Deux types de panne peuvent tre modliss [YB et al. 92a]:
panne sur une opration premptible et panne sur une opration non premptible. Une panne
sur l'opration non premptible (figure 4-19) spcifie que le processus panne n'arrive pas
pendant le processus transformation, et que la mise en panne surviendra immdiatement avant
ou aprs la transformation. Une panne sur l'opration premptible (dfaillance) spcifie que la
machine doit tre immdiatement retire de l'activit production (processus transformation), et
la mthode associe doit dcider soit de terminer le processus transformation (s'il arrive
pendant la transformation), soit de la suspendre. Si la transformation est suspendue, une
mthode dcide soit d'attendre la disponibilit de la mme machine (comme un arrt structurel)
soit d'accepter un remplacement (en vhiculant les articles en attente devant une autre
machine). Ces mthodes dcisionnelles sont conues comme des mthodes virtuelles et seront
surcharges et prcises lorsque l'utilisateur instancie l'objet machine. La dfinition du
processus transformation est trs diffrente selon le type de panne. Pour une opration non
premptible, les traitements de pannes dfinis dans le processus transformer sont implments
 159

par deux appels une mthode virtuelle de gestion de pannes. Par contre, pour une opration
premptible, l'utilisateur doit surcharger le processus "transformer" afin d'intgrer sa propre
gestion de panne.

Panne de Machine

Premptible (Dfaillance) Non-Premptible

/~
Terminaison
Prmature Suspension
~~
Attente Remplacement

Figure 4-19 Gestion de Panne sur le Processus Transformer d'une Machine

IV.5.2.2.3 Dfinition des Processus d'une Station

Ordres

File d'Attente des Evnements (Messages Synchrones)

-- -> <--

File d'Attente des Articles Entrs. ' File d'Attente des Articles Sortis

....U.....J.....L..L..
--~>IITII
Tableau de n Serveurs Allocateur des Ressources

Figure 4-20 Structure Gnrale d'une Station

Comme nous l'avons constat, il y a deux possibilits pour implmenter les processus d'une
station qui contient n serveurs: un processus par serveur ou un processus .pour tous les
serveurs. Nous adoptons la deuxime approche pour les problmes de temps de calcul
(performance) et une meilleure utilisation des concepts d'objets: l'encapsulation et l'abstraction.
Pour simplifier la prsentation, nous n'abordons pas ici la gestion des ressources et la gestion
de panne des serveurs. La structure gnrale d'une station (figure 4-20) est trs similaire celle
 160

d'une machine, mais se distingue par un pointeur sur un tableau de serveurs. Les processus de
la station servent simuler les processus de ces n serveurs qui travaillent en parallle.

Si la file d'attente amont contient des articles et si la station a des serveurs libres, elle va
charger ces derniers (mthode recevoir) jusqu' ce qu'il n'y ait plus d'articles dans la file
d'attente amont ou jusqu' ce qu'il n'y ait plus de serveurs libres. Si la file d'attente est vide et
tous les serveurs sont libres, la station est bloque et elle va tre dbloque par un message
"dblocage" de la station amont qui alimente la file d'attente. Sinon, elle dclenche le processus
transformer, c'est--dire, les serveurs chargs sont l'tat productif et l'horloge est avance par
une dure dtermine. La figure 4-21 schmatise le processus d'acquisition (mthode recevoir)
d'articles.

Le processus transformer de la station simule les serveurs chargs qui travaillent en parallle.
A un moment donn, une station peut se trouver dans un des cas suivant: tous les serveurs sont
chargs, certains serveurs sont libres, certains serveurs attendent d'tre dchargs ou certains
serveurs sont en panne, tous les serveurs sont libres, etc. Les serveurs n'ont pas donc les
mmes rythmes de travail ou leurs performances sont diffrentes. Pour encapsuler la gestion du
temps de transformation de ces serveurs, le processus transformation de la station va continuer
jusqu' ce qu'il n'y ait plus de serveurs chargs. L'algorithme de transformation d'une station
peut se dfinir de la manire suivante:

Station::Transformer
Rpter
pour les serveurs chargs (un ensemble t)
calculer la dure de transformation commune 'd' de ces serveurs
trouver les serveurs (un ensemble n) dont la dure de transformation est gale 'd'
avancer le temps d'horloge du systme de 'd' (delay (d))
changer l'tat de l'ensemble de serveurs n (de l'tat productif l'tat prt--dcharge )
mettre jour la dure restante de transformation pour l'ensemble de serveurs (t-n)
fin pour
A l'infini

Le processus de gestion de panne d'un serveur est dfini diffremment de celui d'une machine.
Un serveur n'est plus un agent dans la station. TI est dfini comme un objet passif dont le
comportement est encapsul dans les mthodes de la station. La gestion d'une panne est donc
similaire la gestion d'une ressource. On peut retirer un serveur du tableau de serveurs de la
station pendant le temps de panne. L'utilisation des ressources est associe au serveur, il n'y a
plus de lien direct entre l'agent station et les ressources qui sont manipules par les mthodes
 161

de la station. La station accde ces ressources travers ses serveurs. Avec cette structure,
nous pouvons ajouter des rgles de pilotage des serveurs ou des choix d'itinraire des objets
circulants entre les serveurs.

oui

prise d'un article de la FAE prise d'un article de la FAE

charger le serveur et mettre jour ses donne

prise du prochain serveur libre 1

Figure 4-21 Diagramme de la Mthode Station::Recevoir (Item**)

Le processus d'expdition (mthode expdier) des articles transforms d'une station est
schmatis dans la figure 4-22. Le processus va continuer jusqu' ce qu'il n'y ait plus de
serveurs en tat prt--dcharger ou jusqu' ce que la file d'attente aval soit pleine dans le cas
 162

o la capacit de file d'attente est limite. Dans le cas o la file d'attente est vide, la station va
gnrer un message de dblocage pour la(les) station(s) aval qui consomme(nt) des articles de
cette file d'attente.

oui

oui

gnrer un message dblocage

our la station aval

non changement d'tat du serveur

oui

insertion d'un article dans la FAS

mettre jour les donnes du serveur

dchargement du prochain serveur prt--dcharger.

Figure 4-22 Diagramme de la Mthode Station: :Expdier (Item**)

 163

De la mme manire, nous pouvons dfinir, l'aide de ces processus lmentaires, les
processus des objets actifs (agents) des systmes de production comme un convoyeur ou un
transporteur, une machine avec des stocks capacit infinie, une ressource autonome, un
processus de pilotage global, etc. La figure 3-10 du chapitre rn, par exemple, illustre un
comportement d'un objet commande si l'on le modlise comme un objet actif.

IV.S.J Dfinition des Classes d'Objets Dcisionnels

Les classes d'objets dcisionnels des systmes de production constituent l'instrument le plus
gnral, le plus ouvert et le plus puissant pour piloter l'atelier. Elles permettent d'exprimer
n'importe quel programme de pilotage, au sens informatique du terme, qu'il soit issu d'une
rflexion effectue au moment de la conception du systme de production ou qu'il provienne de
l'exprience acquise par le responsable de l'atelier. Cet aspect d'enrichissement n'est pas le seul
avantage car il est trs probable que la conception des systmes de production ne peut fournir
une solution fige aux impratifs de production. Ainsi il est ncessaire d'avoir ces objets
dcisionnels exprims clairement et modifiables comme des entits part entire.

L'adaptation de l'atelier au contexte de production (ractivit) est un des objectifs cl de cette

recherche (flexibilit du modle). Elle doit se traduire par une possibilit d'action (choix par
exemple) des rgles ou des algorithmes de pilotage. L'laboration et le choix de ces rgles et de
ces heuristiques est un point dlicat, mais ce n'est pas la seule difficult. En effet, la
modlisation et la simulation doivent tre utilises d'une manire efficace, nous avons renonc
implanter ces rgles comme base d'un moteur d'infrence interrogeable par les algorithmes de
simulation ([JAIN et al. 90], [YE et al. 92a], [GUO et al. 90]); et nous avons d traduire ces
rgles en des algorithmes et des procdures, susceptibles d'tre invoques directement par les
mthodes des objets agents ou les algorithmes de simulation.

Les classes d'objets sont composes de rgles de gestion et de rgles de pilotage du systme.
Trois types de rgles doivent tre modlises: les rgles de priorit (dispatching), de
management et de gestion des ressources [GUILLARD 92].

IV.5.3.1 Les rgles de Priorit (Dispatching)

Les rgles de priorit consistent organiser le choix des oprations (articles) sur lesquelles
vont travailler les agents (machine, station, etc.), et rciproquement, pour chaque opration
choisie, l'agent qui va la traiter dans la mesure o il y en a plusieurs possibles (station). Ceci
conditionne aussi la circulation des agents transporteurs. Le travail de rpartition-se fait dans la
mesure des liberts laisses par la structure des gammes opratoires associes aux articles et
par le potentiel opratoire des agents dans l'atelier.
 164

Ces rgles ont un caractre local, puisqu'elles concernent des choix ne portant que sur l'tat
des oprations, des agents de transfert qui devront les prendre en charge et des agents
machines ou stations ayant le potentiel opratoire ncessaire. L'tat du reste du systme influe
peu ou nullement sur le fonctionnement de ces rgles. De plus, ces rgles ont un caractre
anonyme, puisqu'elles peuvent s'exprimer sans dsigner explicitement les objets concerns. Par
exemple, on peut avoir une rgle du genre: "A la sortie d'une opration d'assemblage sur une
machine, l'article doit aller la machine de test dont les places d'attente d'entre sont les moins
remplies", ou encore "L'article doit aller sur la cellule flexible qui demandera l'allocation du
moins de ressources possibles pour les traiter".

Une centaine de ce genre de rgles est fournie dans la littrature [PANWALKER 77]. Chaque
atelier peut appliquer une rgle ou des rgles combines mieux adaptes son cas particulier.
Ici rside la difficult majeure du problme: une rgle peut donner d'excellents rsultats dans
certains cas et de trs mauvais dans d'autres. Aussi, en dynamique, lorsque de nouveaux ordres
de fabrication arrivent, et donc changent des donnes (contexte), les performances obtenues en
appliquant toujours la mme rgle peuvent se dgrader. C'est pour cela que nous abstrayons
des heuristiques gnrales en des objets modifiables et fournissons aux utilisateurs un modle
ouvert et dynamique de simulation qui leur permet d'appliquer ces heuristiques, directement ou
par enrichissement de leurs connaissances. Le tableau 4-1 prsente les rgles de priorit les
plus utilises [CANALS 86]:

Rsdes Commentaire
FIFO premier arriv premier servi
SPT plus petit temps opratoire
EDD la date au plus tard (di) l'article qui contient l'opration
SLACK plus petite marge entre la d; et temps courant
SLACK/OPN plus petite marge par opration
SPT-T mixage de SPT et de SLACK/OPN
SPT-X mixage de SPT et de SLACK
CoverT pondration de SPT par le cot du retard
TZAR marge plus temps opratoire
s pondration statique de SPT par le temps d'attente
SMOT opration de l'article de dure moyenne opratoire min.
MOPNR la plus longue opration de l'article de gamme restante
FOPNR la plus courte opration de l'article de gamme restante

Tableau 4-1 Rgles de Priorit

 165

D'autres rgles telles les rgles de lancement des ordres de fabrication existent
[BOUKACHOUR et al. 93]. On y a souvent recours dans l'industrie. La diffrence de ces
rgles est dans la dfinition de deux mthodes insrer ou enlever de l'objet dcisionnel qui
drive d'une file d'attente. Elles peuvent tre trs bien dfinies partir d'une classe d'objet .file
de priorit: l'utilisateur surcharge donc l'algorithme d'arrangement des articles dans la file et les
deux mthodes insrer et enlever de la file pour construire leurs propres rgles de priorit. Ces
rgles sont trs attaches la structure des articles contenus dans la file. Une rgle de priorit
comme FIFO ou LIFO peut tre implmente sans connatre la structure de l'article. Par
contre, une rgle SPT doit connatre le temps opratoire de l'article sur cette machine et une
rgle EDD le temps opratoire restant et la date de sortie souhaite, etc. Ces rgles sont
dfinies comme des mthodes normales d'un objet dcisionnel, mais leurs applications sont
dfinies comme des mthodes virtuelles ou mthodes pures dans les objets agents. C'est au
moment de l'excution que les utilisateurs prcisent quelles dcisions doivent appliquer par les
objets actifs dans une application.

IV.5.3.2 Les Rgles de Management

Les rgles de management (ou rgles de comportement global) ont pour rle de traiter des
vnements qui peuvent survenir dans l'atelier, au sens large. On exprime ainsi une sorte de
programme de contrle qui traite l'atelier dans son ensemble (bien qu'il puisse fonctionner en
particularisant telle ou telle partie). Au contraire des prcdentes, ces rgles ont donc un caractre
global et explicite (non anonyme). Ces rgles proviennent de l'exprience du responsable de
l'atelier ou de la simulation. Bien entendu, ceci n'est pas une loi gnrale. Un exemple pourrait
tre: "Si la machine nS tombe en panne, alors la machine n3 doit cesser de fabriquer le type de
pice 4 puisqu'il ne sera pas trait; la machine n3 peut changer le mode de slection dans sa file
d'attente d'entre ou remettre en cause son comportement".

Ces rgles ne concernent que les vnements les plus probables et ne peuvent pas traiter
exhaustivement l'ensemble des problmes susceptibles de survenir dans l'atelier (si c'tait le cas, on
disposerait d'un outil analytique capable de rsoudre tous les problmes de l'atelier). Dans
l'exemple propos, cela revient dire que la machine nS tombe frquemment en panne.

Nous considrons que ces rgles sont bases sur un modle (gnral ou spcifique). Quand nous
modlisons les classes d'objets logiques et physiques, nous devons fournir ds attributs et des
mthodes pour rpondre ces messages envoys par les rgles de "management".
 166

IV.5.3.3 Les Rgles de Gestion de l'Allocation des Ressources

Les rgles de gestion de l'allocation des ressources servent classer les demandes d'allocation
selon un critre particulier. Par exemple, on pourra dcider de grer l'allocation d'un outil.
(outillage, oprateur, etc.) en se basant sur les priorits des articles fabriquer ou bien
simplement de grer les requtes selon leur ordre d'arrive.

Ces rgles proviennent galement de la phase de conception du systme de production, mais

elles conditionnent beaucoup la fluidit de la circulation des objets de transactions et doivent
ventuellement tre remises en cause et values. Les ressources sont ensuite gres par un
allocateur de classe (voir section V.2.1).

V Construction des Classes d'Objets de Rsolution

Nous avons examin et raffin les classes d'objets smantiques (ou classes d'objet du domaine).
Un systme logiciel objets contient aussi des classes d'objets de rsolution, c'est--dire, des
classes d'application, des classes d'interface, des classes auxiliaires/mathmatiques.

V.l Classes d'Objets d'Application

Les classes d'objets d'application peuvent tre considres comme les mcanismes de conduite
ou de contrle du systme. Les classes d'objets d'application pour la simulation concernent
essentiellement la dfinition des classes d'objets chancier, le noyau de synchronisation et les
mcanismes de synchronisation et de communication entre les processus (chapitre V).

V.2 Classes d'Objets Auxiliaires/Utilitaires

Les classes d'objets auxiliaires/utilitaires sont des objets qui sont indpendants des applications.
Les objets de base ou auxiliaires comme les listes (liste simple, liste double, arbre, tableau,
gestion des fichiers, etc.) sont dfinies dans la littrature tant au niveau de la spcification qu'au
niveau de l'implmentation. Les objets auxiliaires mathmatiques comme les matrices, les
vecteurs, les diffrents algorithmes de tri (HeapSort, QuickSort, ShlSort) et les objets
utilitaires pour la simulation comme les diffrents gnrateurs (poissonnien, exponentie~
gaussien, etc.), les objets d'analyse (variance, moment, esprance, histogramme, lissage
exponentiel, etc.) sont aussi prdfinis par la plupart de progiciels ou d'outils pour la
modlisation et la simulation. Nous pouvons les tendre facilement comme des objets d'analyse
des performances des systmes de production, des objets de gestion des informations, etc.
 167

V.3 Classes d'Objets d'Interface

Les classes d'objets d'interface, c'est--dire la manifestation visible des objets smantiques sur
l'cran, ne sont pas directement lis aux problmes r~soudre, mais elles reprsentent les
points de vue des objets smantiques par l'utilisateur (objets fentres, objets botes de dialogue,
objets contrles, etc.). La tche principale dans cette phase de conception est d'laborer une
implmentation graphique des objets smantiques pour afficher les tats de sortie, les masques
de saisie, les communications, etc., en utilisant les classes d'objets informatiques de base. Un
exemple de configuration d'une machine avant le lancement de simulation, par exemple, est
illustr dans la figure 4-23. Cette interface est pour la saisie des informations sur les attributs
structurels et conjoncturels de la machine.

- Modelisation du Systeme ~,,

He

Nom de Machine: ._IT_o_u_r_4_ _ _.,.~ Position ~: ._ll_oo_ ___.l Position :X:=I~...1_DO_ ___.

Mode (FAE): Mode [FAS):

jsPT Il [Eoo 1
J;ot d'Aquisition: j2.000.000 j J;ot unitaire d'Utilisation: j1 000 1
:=.====:;
Iaux de Rebuts: ~...15_"_ _ ___.1 Iemps de Prparation: 1,_5_ _ _ _.....1

.Loi de Panne: Loi de Maintenance:

1PoissonR Il jNormaiR 1

Figure 4-23 Ecran de Configuration d'une Machine

D'autres objets smantiques d'interfaces tels que le march, la commande, le programme de

production, le produit, la ressource, etc., sont aussi construits avec le package de
programmation graphique: ObjectWindows. Une interface (base de donnes) entre ces
informations de configuration est ainsi ralise.
 168

VI Conclusion

Bien que le nombre de publications concernant les mthodes de conception oriente-objets se

multiplie, les thmes fondamentaux et les approches (en vocabulaire et en notation) de ces
mthodes ont plus de similitudes que de diffrences. n est difficile (voire stupide) de qualifier
ou de quantifier la puissance et la faiblesse de chaque mthode. Notre but est d'essayer de tirer
les meilleurs concepts de chaque mthode et de les intgrer dans notre travail. Dans ce travail,
nous nous sommes inspir de beaucoup de techniques telles que nous trouvons dans l'analyse
du domaine, la programmation concurrente, le langage de programmation C++, les concepts
temps rel et les concepts objets concurrents. La dmarche de conception propose dans ce
mmoire a pour objet de construire des classes d'objets implmentable directement en langage
C++: une plate-forme de dveloppement pour l'application.

Nous avons dtaill, dans ce chapitre, l'tape de la conception de modles de simulation des
systmes de production en deux phases: une phase de conception de haut niveau qui consiste
modliser les classes d'objets du domaine et de son environnement ainsi qu'une phase de
conception de bas niveau qui consiste, d'une part raffiner, tendre, hirarchiser et
rorganiser les classes d'objets du domaine et d'autre part, dfinir la structure interne du
logiciel tels que l'architecture de modle, les classes d'objets d'application, les classes d'objets
d'interface et les classes d'objets auxiliaires/utilitaires.

Nous avons commenc par la conceptualisation des objets actifs, un concept trs important
dans l'approche par processus dans les modles de simulation objets. Un objet autonome est
un objet actif qui possde son propre flot de contrle (scripts de processus). D encapsule non
seulement sa structure (organisation) interne, mais galement fournit des primitives de cration
de processus et des mcanismes de coopration entre eux. Les problmes principaux
concernent la granularit des activits concurrentes l'intrieur d'objets: 1) une seule ou
plusieurs activits existent dans un mme objet; 2) les messages entre objets sont synchrones
ou asynchrones (et aussi unidirectionnels ou avec retour); 3) le nombre d'activits est-il fix ou
non (la dynamicit de la configuration des processus), etc. Nous les distinguons en quatre
activits dans les objets actifs: perception et acquisition, cognition, dcision et action.

Ensuite, nous avons construit une architecture ouverte et flexible qui permet diffrents
utilisateurs d'y intervenir diffrents niveaux des modles (ressource, atelier, unit de
production, GPAO). Les aspects sur les perspectives de la reprsentation par objets, les points
de vue des objets, les relations entre les classes d'objets et le cycle de vie des classes d'objets
sont analyss avant de prsenter les classes d'objets smantiques dans la simulation des flux de
production: classes d'objets de transactions, classes d'objets des moyens de production et
classes d'objets dcisionnels. Les attributs et mthodes de ces classes d'objets sont prsents et
 169

conceptualiss. Nous pouvons implmenter directement ces classes d'objets dans un outil de
simulation qui supporte la notion des processus "lgers" (threads).

Enfin, le quatrime modle d'objets: les modles de processus sont illustrs travers les
exemples d'objets de machine et de station, et la conception des objets auxiliaires et des objets
d'interfaces est brivement prsente.
 Chapitre V Simulation Concurrente par
l'Approche Objet

1 Introduction

Les techniques de la programmation concurrente ont considrablement chang durant cette

dernire dcennie ([ANDREWS 83], [WILLIAMS 90]). Premirement, les progrs thoriques
ont engendr de nouvelles dfinitions pour la programmation concurrente qui pennet
d'exprimer des processus concurrents plus simples, de construire des communications et des
synchronisations plus explicites, de faciliter la preuve fonnelle d'exactitude du programme
concurrent, etc. Deuximement, l'utilisation des systmes parallles ou des systmes rpartis
pennet d'implmenter rellement des programmes concurrents ou parallles. La programmation
concurrente n'est donc plus uniquement la comptence de ceux qui conoivent ou
implmentent des systmes d'exploitation. Elle devient une notion essentielle et indispensable
pour tout type de programmation, tels que les systmes de gestion des bases de donnes, les
applications en temps rel, les systmes de contrle embarqus, les algorithmes parallles et les
simulations vnements discrets bien entendu.

La notion de concurrence ou paralllisme est prsente dans toutes ces catgories d'application.
Dans chacune d'elles le temps intervient avec une notion diffrente et d'une faon plus ou
moins explicite. En ce qui concerne la simulation, le temps qui intervient est soit un temps
virtuel [JEFFERSON 83], soit un temps physique ("rel") pour des applications relles
[HOOGEBOOM et al. 93]. Le temps virtuel peut tre associ au temps physique par des
relations plus ou moins complexes. Par exemple, dans le cas de l'assignation des priorits aux
processus sur un calendrier, le temps intervient d'une faon implicite. Par contre, dam le cas o
un certain processus attend une ressource ou une condition pour dclencher un vnement, le
temps est spcifi explicitement. D intervient souvent de manire explicite dans le cas de la
simulation vnements discrets.

Les modles de simulation avec des concepts concurrents ou parallles peuvent tre
implments de diffrentes manires [WILLIAMS 90]: modle squentiel avec un ou plusieurs
processeurs, modle avec des machines vectorielles, modle avec des processeurs pipelines,
modle avec une mmoire distribue, etc. On s'intresse uniquement, dans notre cas de
recherche, la programmation concurrente avec la notion de processus "lger" {light-weight
process) implment par un objet abstrait "thread" pour la simulation. Les threads ne sont pas
un langage mais des bibliothques de constructeurs. Ds pennettent d'avoir plusieurs flots de
 172

contrle dans le mme espace d'adressage. lls ont leurs propres activits et rssources (piles,
donnes) [WALAS et al. 93].

L'approche oriente-objets (AOO), un nouveau concept pour l'analyse, la conception et la

programmation, nous laisse entrevoir beaucoup d'avantages dans certains domaines
d'application par rapport aux approches fonctionnelles et structures. En pratique, n'importe
quel objet du monde rel peut tre modlis par un objet informatique dans un systme
objets. Comme les objets rels peuvent exister et s'excuter concurrentiellement, l'approche
objets montre aussi son utilisabilit potentielle pour la construction des systmes concurrents.
Diffrents types de concurrences existent dans un systme objets: diffrents objets peuvent
excuter diverses activits (mthodes) en mme temps ou un objet peut excuter plusieurs
activits (mthodes) concurrentiellement. Une explosion potentielle des activits concurrentes
est donc possible dans un modle objets. Comme dans n'importe quel langage concurrent, le
problme majeur du langage orient-objets (LOO) est sa capacit d'exprimer et de contrler les
activits concurrentes: peut-on concevoir des abstractions, dans le sens orient-objets,
rutilisables et extensibles, et qui permettent des utilisations concurrentes comme dans le cadre
de la programmation parallle, et si oui par quels mcanismes syntaxiques les dcrire.

La plupart des langages objets traditionnels ne peuvent pas tre considrs comme des
langages concurrents bien qu'ils fournissent une certaine forme de concurrence (langages bass
sur C avec le concept coroutine, langages bass sur Lisp avec le mcanisme de "diviser et
conqurir", langages bass sur Smalltalk comme DistributedConcurrentSmalltalk et
ConcurrentSmalltalk, langages bass sur la notion d'acteur, etc.). Diverses recherches sont en
cours dans ce domaine ([NELSON 91], [WYATT et al. 92]). Nous prsentons d'abord les
concepts du processus en terme d'implmentation et essayons d'claircir les concepts
"concurrence" (cration de processus, synchronisation et communication entre processus).
Ensuite, nous analysons les trois langages (ou logiciels) de simulation objets CJ,ui supportent
ces concepts et qui sont disponibles dans notre laboratoire. Enfin, en utilisant un logiciel de
simulation Meijin++, nous dtaillons comment nous implmentons des modles de simulation
du systme de production par des entits communicantes dont chacune est un objet actif.

II Dfinitions

II.l Processus

Au concept de traitement parallle, il faut attacher un certain nombre de notions fondamentales

dont celles de processus et de procdure. Une procdure (ou un programme) est une entit
 173

compose d'une ou de plusieurs squences d'instructions, agissant sur un ensemble de donnes

(les variables externes ou internes la procdure). Une procdure est essentiellement statique.

Un processus, entit essentiellement dynamique, met en oeuvre de manire squentielle une ou

plusieurs procdures statiques, en vue de la ralisation d'une activit donne par un processeur.
Notons qu'une activit est une action de processus (qui se droule donc dans un laps de temps
ni ngligeable ni indiffrent a priori).

Avant de continuer, prcisons les notions de tche et de processus. Certains puristes font une
distinction entre tche et processus en insistant particulirement sur l'aspect cyclique de
l'excution d'une tche tandis qu' un processus sont plutt attaches des notions de
progression et d'action. Cette distinction n'a que peu de consquences pour la comprhension
de la suite.

ll.l.l Contexte de Processus

Un processus ou encore une tche, est fonction du temps; il peut tre cr, excut, bloqu ou
encore dtruit. Un processus excute les instructions du programme auquel il est associ. Sans
entrer dans les dtails, un processus comporte diffrentes zones, en gnral trois, qui constitue
une partie du contexte d'un processus:

* Une zone programme contenant les instructions du programme et ventuellement

certaines constantes (coefficients, texte, etc.), considre par le systme comme une zone
constante accessible uniquement en lecture, si l'entit de gestion de la mmoire le permet.
* Une zone de donnes contenant les donnes variables et les donnes constantes ou
initialises. Cette zone est bien sr accessible en lecture et en criture.
* Une zone de pile permettant de ranger des informations temporaires (variables locales,
adresses de retour de sous-programme, etc.) accessibles galement en lecture et en
criture.

L'accs aux diffrentes zones s'effectue gnralement par rapport des registres initialiss par
le systme lui-mme lors du lancement du processus. Ainsi, le compteur de programme est
initialis sur la premire instruction du programme, la zone de donnes et la pile tant, quant
elles, respectivement rfrences par un pointeur de zone de donnes (registre de donne ou
d'index) et un pointeur de pile. Ces informations font partie de ce que l'on appelle le contexte
du processus. En d'autres termes, ce contexte comporte gnralement:

* l'tat des registres du processeur;

* l'tat des pointeurs de zones mmoire associes au processus (instructions, donnes, pile);
 174

* les caractristiques du processus dans lesquelles on retrouve essentiellement: un

identificateur grce auquel l'ordonnanceur ou le systme d'exploitation identifie ce
processus, une priorit permettant de quantifier le degr d'urgence du processus (Cette .
priorit permet de dterminer l'ordre d'allocation du processeur lorsque plusieurs
processus sont en attente d'excution.), un droit d'accs spcifiant les ressources
matrielles ou logicielles accessibles par le processus, un tat instantan du processus, etc.

TI.1.2 Etats du Processus

Un processus cr dans un modle simplifi de simulation ne peut tre que dans l'un des quatre
tats fondamentaux suivants:

- non-oprationnel (cr, donnant, hors-service): le processus est cr et connu de

l'ordonnanceur (voir section ll.l.S) (c'est--dire le contexte du processus est initialis et
maintenu par l'ordonnanceur),
-lu (en cours, en excution), le processus est en possession d'un processeur et en cours
d'excution,
-ligible (prt), le processus est en possession de toutes les ressources ncessaires son
fonctionnement sauf d'un processeur,
- bloqu (en attente), le processus est en attente d'une ressource quelconque
indispensable son excution future.

n est important de distinguer l'tat ligible de l'tat bloqu. Lorsqu'un processus passe en
excution partir de l'tat ligible, il suffit de mettre jour une variable signalant le nouvel tat
du processus et d'initialiser les registres du processeur. Pour reprendre un processus bloqu, il
faut recharger tout le contexte sauvegard lors du blocage. Le processus reprend alors
exactement l'endroit interrompu. Les transitions entre tats du processus sont prcises sur la
figure ci-aprs (figure 5-l ):

- la transition non-oprationnel -> ligible correspond une activation du processus et

peut-tre mme lu selon sa priorit et celle du processus en cours;

- la transition ligible -> lu correspond une allocation du processeur slectionn par

l'ordonnanceur. Le lancement d'un processus dpend en gnral de sa priorit par rapport
au processus en cours d'excution ou aux autres processus l'tat ligible;

-la transition lu-> ligible correspond une premption (ou rquisition) du processeur
au profit d'un autre processus; cette premption est dcide selon l'algorithme
d'ordonnancement utilis;
 175

terminer

Figure 5-1 Diagramme des Transitions entre Etats d'un Processus

- la transition lu -> en attente est gnralement due un appel systme ou l'occurrence

d'un vnement impliquant l'attente d'une condition;

- la transition attente -> ligible encore appele rveil du processus s'effectue suite
l'occurrence de l'vnement attendu;

-la transition lu, ligible, en attente-> non-oprationnel correspond une terminaison (si
le processus est l'tat lu) ou une dsactivation (si le processus est l'tat ligible ou
l'tat en attente).

Dans un systme compliqu, les tats d'un processus peuvent tre raffins ( condition que
l'ordonnanceur les connaisse). L'tat d'attente de processus peut, par exemple, tre raffin dans
les trois cas suivants: attente d'une ressource, attente d'un vnement ou attente durant un laps
de temps (dlai). La figure 5-2 montre un diagramme des changements d'tat de processus plus
complet. Les phases de transitions numrotes de 1 16 sur le diagramme sont explicites ci-
dessous:

01 Cration d'un processus (new (p));

02 Destruction d'un processus (delete (p));
03 Activation d'un processus en vue de sa slection par l'ordonnanceur;
04 Dsactivation d'un processus
05 Slection d'un processus et allocation d'un processeur par l'ordonnanceur;
06 Rquisition du processeur au profit d'un autre processus (premption);
 176

07 Fin d'excution du processus en cours;

08 Blocage sur accs une ressource non disponible;
09 Blocage sur attente de fin d'un dlai;
10 Blocage sur occurrence d'un vnement (gnralement asynchrone);
Il Activation d'un processus forc d'attendre l'coulement d'un dlai;
12 Activation d'un processus forc d'attendre un vnement;
13 Activation d'un processus forc d'attendre la libration d'une ressource;
14 Activation d'un processus suite la libration de la ressource attendue;
15 Activation d'un processus suite l'coulement d'un dlai;
16 Activation d'un processus suite occurrence d'un processus.

Figure 5-2 Diagramme des Etats des Processus et leurs Transitions

ll.1.3 Commutation de Contexte

Les changements d'tat d'un processus conduisent gnralement une commutation de

contexte qui consiste remplacer le contexte d'un processus Pl par celui d'un processus P2
(nouvel lu) en vue de l'excution de ce dernier par un processeur. Un processeur est donc un
agent actif responsable de l'excution d'un ou de plusieurs processus de manire alternative ou
quasi simultane ( l'aide d'un ordonnanceur).

TI faut dj bien distinguer la commutation de processus de la commutation de contexte.

L'opration de commutation de contexte intgre en rgle gnrale:
 177

-la sauvegarde de l'tat des registres du processus courant (fonction longjmp (env) dans
le langage C, par exemple);
- la restauration de l'tat des registres relatifs au nouveau processus (fonction setjmp Q).

Une commutation de contexte peut tre effectue suite un appel au noyau de synchronisation
(ordonnanceur) ou lors de l'occurrence d'une interruption. La commutation de processus
consiste en l'abandon du traitement du processus en cours pour commencer ou continuer le
traitement d'un autre processus. Une commutation de processus peut tre provoque:

- sur demande explicite du processus lui-mme (mise en attente d'une condition, fin du
processus);
- sur dcision de l'ordonnanceur (processus en cours moins prioritaire qu'un autre
processus ligible);
- par ncessit de rponse un phnomne externe (vnement).

TI en rsulte qu'une commutation de processus peut ventuellement induire une commutation

de contexte. Les oprations de base (fonctions "systme") de changement de contexte d'un
processus effectues sont alors les suivantes (la figure 5-3 montre l'utilisation de ces oprations
dans la mthode suspendreO d'un processus):

-sauvegarde du contexte du processus en cours (sauvegarder (processus));

-mise du processus en cours dans la liste des processus en attente (insrer (processus));
- invocation de l'ordonnanceur pour dterminer le processus ligible le plus prioritaire
excuter sur le processeur (slectionnerO) dans la liste des processus ligibles;
-restitution du contexte du nouveau processus (restituer(processus) ou reprendre (p)).

L'appel la mthode suspendreO dans le processus Pl invoque la mthode slectionnerO de

l'ordonnanceur qui elle-mme appelle la mthode sauvegarderO du processus invoquant. Le
premier appel sauvegarderO retourne une constante Cl (une valeur 0 en gnral) et sauve le
contexte associ au processus P 1 en we d'une ractivation future. Suite au premier retour de
la mthode sauvegarderQ, le processeur est sous la direction de la mthode slectionnerO qui
slectionne, selon la figure 5-3, un nouveau processus P2.

Pour ractiver le processus P2, la mthode slectionnerO fait appel la mthode reprendre 0
du processus P2 qui rcupre le contexte du processus P2 en retournant une constante C2 (une
valeur diffrente de 0) et transfre le contrle du processeur au processus P2. Le processus P2
 178

excute les procd~res associes, la fin de son excution il transfert 8on contrle en
excutant sa mthode suspendreO qui dclenche le mme enchanement que prcdemment.

suspendre()
slectionner()
~ sauvegarder(Pl)
~ retour (constante Cl)

(Slection du Processus P2
reprendre (P2)-------::)o~

suspendre()
slectionner()
~ sauvegarder(P2)
~ retour (constante Cl)

Slection du Processus Pl

.,.<<------- reprendre (Pl)

~ retour (constante C2)
retour

Figure 5-3 Mise en Oeuvre des Oprations dans la Mthode SuspendreO d'un Processus

ll.1.4 Descripteur de Processus

Les structures de donnes manipules par un noyau de synchronisation (ordonnanceur) sont

essentiellement constitues par les descripteurs de processus. Un descripteur de processus est
un objet permettant de retrouver travers ses mthodes toute l'information propre (contexte)
un processus, savoir:

- l'ensemble des variables propres au processus;

- la priorit et l'tat du processus;
- le contenu des registres du processeur, lorsque le processus ne s'excute pas.

L'ordonnanceur est donc une liste des descripteurs de processus. Pour retrouver toute
l'information propre un processus, il suffit de retrouver la pile du processus. La solution
 179

gnrale est, soit de conserver dans le descripteur de processus le pointeur de sommet de pile
du processus (figure 5-4), soit d'utiliser le mcanisme du double chanage permettant un
descripteur de processus d'tre reli par un pointeur au descripteur prcdent dans la file et par
un autre pointeur au descripteur suivant. Dans les logiciels de simulation, on retrouve souvent
les deux solutions. Dans plusieurs ouvrages ou articles, on trouve des tudes sur les
algorithmes de manipulation de la structure du noyau (ou prcisment de la file d'attente de
priorit) et des comparaisons des avantages et des inconvnients des uns par rapport aux
autres: "calendar queues" [BROWN 88], "heap queues" [GONNET 76], "binomial queues ou
trees" ([BROWN 78], [VUILLE:MIN 78]), etc. Le choix dpend essentiellement de la
complexit de l'application (nombre de processus modliser) et les contraintes du temps de
traitement (performance du modle).

tte de liste
nil

descripteur du descripteur du
processus pl descripteur du
processus p2 processus p3
(en excution)

registre du
processeur zone de
1
donnes zone de
~ donnes

sommet pile du pile du pile du
de pile processus pl processus p2 processus p3

Figure 5-4 Liste des Descripteurs de Processus (le Processus pl est en Excution)

11.1.5 Le "Scheduler" ou l'Ordonnanceur

L'ordonnanceur est le "chef d'orchestre" d'un modle de simulation. TI effectue le choix d'un
processus parmi N processus ligibles et lui alloue le processeur. Le processus concern est
dit processus lu. L'ordonnanceur (le scheduler) a des rles essentiels:

- garantir chaque processus un temps d'allocation donn,

- assurer la gestion des commutations de processus,
 180

- effectuer le choix d'un processus dans l'ensemble des processus ligibles en respectant
un ordre de priorit entre processus,
- annuler de manire premptive un processus qui monopolise le processeur,
-etc..

Les algorithmes d'ordonnanceurs classiques, implments auparavant dans diverses structures

de files d'attente, sont conceptuellement une arborescence d'instructions, accomplies
invariablement dans un ordre qui ne dpend gnralement que des donnes initiales, et qui peut
s'exprimer partir de quelques structures de donnes et d'actions (procdure, bloc, squence,
boucle logique, boucle itrative, slection, interrogative) avec un vocabulaire restreint. lls ne
font pas intervenir le temps et donnent toujours le mme rsultat pour des donnes initiales
identiques [THORIN 90].

Les algorithmes d'un ordonnanceur d'un simulateur dpendent du temps, en outre, il fait
intervenir:

-les objets de type temps (assimilable une variable relle ou entire valeurs monotones
croissantes, modifie au moins chaque accomplissement d'action d'un processus) et de
type vnement (assimilable une variable logique qui change de valeur quand ce qu'il
reprsente s'est produit: un objet venant d'tre cr, dtruit ou de prendre une certaine
caractristique, ou encore une action venant de commencer, de se terminer ou d'entrer
dans une certaine phase), qui ne sont pas structurs;

- les structures d'actions de

* Processus: procdure (entit) dont l'excution est simultane avec d'autres;

* Squence Synchronise: suite d'ordres excuts une fois la survenance d'un

vnement, ou chaque survenance d'un vnement, ou encore seulement jusqu'
la survenance d'un vnement; cela correspond dans le langage de programmation
aux structures suivantes:
lorsque (vnement) (squence),
toutes les fois que (vnement) (squence),
jusqu'au moment o (vnement) (squence);

* Boucle Synchronise: suite d'ordres excuts indfiniment jusqu' la survenance

d'un vnement; cela correspond, dans le langage courant, des ordres utilisant les
 181

conjonctions "pendant que", "tandis que", "aussi longtemps que", "en mme temps
que" avec la structure suivante du langage:
aussi longtemps que (non vnement) (squence);

* Slection Synchronise: ensemble de squences dont une au plus est excute

selon la survenance d'un vnement comme dans les structures suivantes:
selon que (vnement) (squence),
ou (vnement) (squence),
ou (vnement) (squence),

smon (squence);

*Interrogative Temporelle: ordres d'accs portant sur l'vnement; cela correspond,

dans le langage courant, un ordre utilisant "quand" ou "depuis quand".

avec un vocabulaire plus large (attendre, dclencher, arrter, avertir). Ces structures sont
surtout composes de plusieurs arborescences accomplies simultanment et dans un ordre
quelconque (simultanit des flots d'excution).

Un algorithme dpendant du temps ou algorithme temps rel est donc un ensemble de

plusieurs processus en parallle, c'est--dire excuts simultanment. L'intrt d'un algorithme
temps rel, contrepartie d'une complexit accrue par rapport ceux qui ne font pas intervenir
le temps, rsulte des raisons suivantes:

1) eux seuls peuvent reprsenter les oprations de certains systmes en relation avec
l'environnement du monde rel,
2) ils sont souvent plus naturels pour reprsenter des lments autonomes d'un systme,
mme sans relation avec l'environnement rel,
3) ils sont parfois plus efficaces, notamment en ce qui concerne les temps de rponse, et
parfois plus faciles crire mme dans le cas complexe.

On appelle multiprogrammation le cas o les processus se partagent une machine, y compris le

processeur (il y a donc simultanit globale et entrelacement des activits, mais pas
simultanit relle un instant); multitraitement le cas o les processus se partagent les
mmoires, chacun ayant son processeur; traitement rparti le cas o chaque processus a sa
machine et est autonome, mais reli aux autres par un rseau de communications; les
combinaisons hybrides sont bien entendu possibles, en particulier le traitement distribu o,
 182

la diffrence du prcdent, les processus ne sont pas autonomes car l'un d'eux les commande
ou les contrle, au moins certains moments.

Nous travaillons, dans notre cas de recherche, sur une machine avec un ou plusieurs
processeurs. La notion thread nous permet d'encapsuler les oprations essentielles manipules
par l'ordonnanceur (par exemple, crer, dtruire, activer, dsactiver (bloquer) ou terminer un
processus, etc.). Diverses techniques d'ordonnancement temps rel existent: ordonnancement
circulaire, ordonnancement priorit, ordonnancement priorit avec des files multiples.
Dans la simulation, la technique la plus utilise est celle priorit. Ce type d'ordonnancement
permet de raliser des noyaux de synchronisation totalement indpendants du matriel (pour un
processeur donn). Les noyaux sont compacts et efficaces. Leur emploi est cependant limit
aux applications comprenant des processus qui ont peu de calcul et pas beaucoup
d'entres/sorties. C'est pour cela que pour la plupart des ordonnanceurs pour la simulation on a
choisi l'ordonnancement priorit.

ll.2 Relations entre Processus

TI est trs rare qu'un processus (une entit) soit isol des autres. Plusieurs processus s'excutent
en gnral d'une manire enchevtre et/ou simultane dans un ordre a priori indtermin. Cela
implique l'existence des relations de dpendance entre eux (mme si les processus ne se
connaissent pas entre eux: il n'y a pas de lien direct entre processus), puisque l'un peut a priori
intervenir sans le savoir pendant le laps de temps o un autre a temporairement suspendu le
respect des contraintes, donc trouver et/ou rendre un tat incohrent.

Les processus ne sont indpendants que si, et seulement si:

- ils n'ont pas d'environnement commun (ni ressource, ni activit extrieure. connue de
plusieurs processus la fois), pour que chacun soit seul responsable du respect des
contraintes,
- et ils ne se connaissent pas non plus entre eux, pour que ni leurs ressources ni leurs
activits intrieures ne puissent tre influences directement ou non, par aucun autre.

Ce qui revient dire qu'ils sont tous isols. Ce n'est pas le cas dans la ralit, surtout dans le
domaine de la production. Dans tous les autres cas, une relation de dpendance existe entre les
processus (mme si elle ne se manifeste pas chaque excution):

- qu'elle soit volontaire parce que les processus concourent une mme fonction
(coopration pure), par exemple, deux machines en cascade pour traiter une pice, sont
 183

en coopration et en dpendance videntes, sans qu'il soit ncessaire que l'une des
machines connaisse l'tat de l'autre.
- ou involontaire du fait des limitations _de l'environnement (comptition pure), par
exemple, plusieurs processus voulant acqurir la mme ressource partage un instant
sont en comptition pure.

On peut distinguer deux types d'influence entre processus: une influence directe et une
influence indirecte. Une influence directe ne peut provenir que d'un ou plusieurs processus
(mais non de ressources ni d'activits) et s'excute sur: 1) un ou plusieurs processus (l'arrt de
processus par un autre), 2) une ou plusieurs ressources par modification d'tat (l'utilisation
d'une ressource partage avec un autre processus), 3) une ou plusieurs activits par
conditionnement logique ou temporel. Des influences directes sur un ou plusieurs processus
peuvent se combiner en cascade pour constituer une influence indirecte.

Thorin [THORIN 90] a distingu neuf cas intressants d'influences entre les processus, les
ressources et les activits, c'est--dire de neuf types de relations de dpendance.

1). Un processus agit globalement sur des processus;

2). Un processus agit globalement sur des ressources;
3). Un processus agit globalement sur plusieurs activits;
4). Plusieurs processus agissent successivement sur un processus;
5). Plusieurs processus agissent successivement sur une ressource;
6). Plusieurs processus agissent successivement sur une activit;
7). Plusieurs processus agissent successivement sur des processus;
8). Plusieurs processus agissent successivement sur des ressources;
9). Plusieurs processus agissent successivement sur des activits

Les trois premiers cas d'influence ont en commun la caractristique d'tre globaux. La difficult
majeure de ces relations vient du fait qu'a priori d'autres processus pourraient agir (bien que
chacun soit ici vu un un) et rendre le tout incohrent, en se considrant chacun comme seul.
n faut donc que le processus puisse oprer par des actions primitives atomiques (des services
rendus par le processus). Cela dpend du temps excutif (modle de processus) utilis, du
langage de programmation choisi, etc.

ll.3 Communication et Synchronisation entre Processus

Les processus cooprent en vue de la ralisation des activits communes. On distingue deux
sortes de coopration, la coopration temporelle faisant intervenir les notions de blocage et de
 184

dblocage de processus, la coopration spatiale se rapportant l'change d'informations entre

processus. Ces deux types de coopration caractrisent respectivement la synchronisation et la
communication entre processus.

ll.3.1 Communication Interprocessus

Les processus ont besoin d'changer des informations pour cooprer l'excution d'une
application. Les formes de communication utilises en monoprogrammation telles que les
paramtres de procdure ou les rsultats de fonction ne sont pas adaptes au modle
d'excution pseudo-simultan des processus. La seule forme de communication possible semble
tre la communication par zone de donnes commune ou par des messages. Parce qu'il autorise
a priori des changes rciproques simultans, ce mode de communication conduit un type de
solution o tous les changes se font l'aide de mcanismes spciaux sous le contrle du
systme. Ces mcanismes revtent alors des formes multiples: messages, tubes, boites lettres,
signaux, smaphores, vnements, etc. Cette multiplicit s'explique par le fait qu'aucun
mcanisme n'est vraiment satisfaisant et ne permet pas de couvrir l'ensemble des besoins de
communication. Chacun est adapt un modle d'change particulier. Nous prsentons ici
deux modes les plus utiliss dans la simulation.

ll.3.1.1 Communication par zone de donnes commune

La faon la plus simple et la plus rapide de transmettre des donnes est de ne pas en
transmettre. TI suffit pour cela de disposer d'une zone de mmoire commune dans laquelle
seront dposes les donnes en libre accs. L'allocation de cette zone est ralise l'aide de
variables globales (ou statiques en langages C++) ou l'aide d'une requte spcifique.

n n'y a pas de problmes d'interblocage et d'exclusion mutuelle dans le partage de variables

(simples) globales ou statiques. Le concept d'encapsulation renforce encoreta scurit
d'exclusion mutuelle [BUHR et al. 92]. Cela dpend de la conception des classes d'objets
(attributs statiques, publiques, protgs ou privs) et de l'application (classes abstraites, classes
virtuelles, variables statiques).

Les problmes poss sont lis plutt l'accs des objets complexes et partags. Dans un
systme monotche, l'accs aux zones de donnes communes est squentiel. L'ordre dans
lequel il s'effectue est impos par la structure du programme. Dans un systme multitche,
l'accs aux objets partags est fonction de l'ordonnancement des processus. n existe donc des
accs concurrents o plusieurs processus lisent ou crivent des donnes partages, et o le
rsultat est fonction de l'ordonnancement des processus. La fiabilisation des programmes
comportant des accs concurrents est donc difficile voire impossible.
 185

Pour liminer les accs concurrents, il suffit de trouver le moyen d'interdire l'accs simultan
une donne (un objet) partage. Ce moyen s'appelle l'exclusion mutuelle. L'exclusion mutuelle
empche d'accder un objet partag ou un attribut d'un objet si celui-ci est utilis par un
autre processus. La partie du programme qui conduit un conflit d'accs est appele section
critique. Le problme de l'accs concurrent est rsolu si un seul processus est autoris
accder une section critique.

Diffrentes techniques existent pour assurer l'exclusion mutuelle ([BUHR. et al. 92],
[DORSEUIL 90], [SCIDPER 86]): exclusion mutuelle par masquage des interruptions,
exclusion mutuelle par variable ve"ou et attente active, exclusion mutuelle par smaphore,
exclusion mutuelle l'aide de la procdure moniteur, exclusion mutuelle l'aide d'un
gestionnaire de ressources, etc.

ll.3.1.2 Communication par messages (modle producteur/consommateur)

La communication par zone des donnes commune ncessite de grer les changes dans les
moindres dtails. La frquence d'utilisation des modles de communication par message
(modle producteur/consommateur ou modle botes aux lettres) incite raliser des
mcanismes d'changes d'informations de plus haut niveau. Ces mcanismes doivent permettre
l'change d'informations entre processus et mme entre machines distantes en vitant au
programmeur les dtails de l'exclusion mutuelle et de la synchronisation par les messages
(donnes). Ces procds s'appellent l'change par message.

Le modle producteur/consommateur est une gnralisation de l'change d'informations

travers une zone de mmoire commune aux deux processus (figure 5-5). La communication se
passe selon le schma suivant:

- le producteur produit des messages et les dpose dans une zone de mmoire commune
(une file d'attente des messages en gnral) aux deux processus;

- le consommateur prlve les messages et les utilise;

- les messages, dans la zone de mmoire commune, sont grs par la file d'attente et par un
vnement "File-non-Vide" gnr par le producteur si la file d'attente st vide ou un
vnement "File-non-Full" est gnr par le consommateur si la file est pleine.
 186

vnement

vnement
File-non-Vide

Figure 5-5 Modle Producteur-Consommateur

Les oprations (algorithmes) essentielles d'une telle structure peuvent tre schmatises dans la
figure 5-6. L'avantage de ce modle est l'indpendance rciproque de deux processus. Plus la
capacit de la file d'attente est grande, plus elle permet d'absorber des diffrences temporaires
de dbit entre le producteur et le consommateur. Un autre avantage est que cette file d'attente
nous permet de dfinir diffrentes stratgies de gestion des messages (gestion des flux
d'information ou gestion de transactions).

Algorithme du Producteur Algorithme du Consommateur

Rpter Rpter
mPLEINE (File) Alm mVIDE (File) Alm:s.
ATTENDRE (File-non-Full) ATTENDRE (File-non-Vide)
F.iiW. EWi

ENVOYER (message, file) RETIRER (message, file)

SIGNALER (File-non-Vide, Consommateur) SIGNALER(File-non-Full, Producteur)

Al'infmi A l'infini

Figure 5-6 Algorithmes du Modle Producteur-Consommateur

11.3.2 Synchronisation Interprocessus

Les processus d'une application n'voluent pas de faon indpendante. Nous. avons identifi
neuf relations temporelles entre les processus. On appelle aussi ces relations des
synchronisations. La synchronisation consiste imposer un ordre sur l'excution des
instructions des processus. Ce sont des mcanismes de communication o l'information
change est utilise dans le but de synchroniser les processus. On peut dire que l'exclusion
 187

mutuelle peut tre we comme un cas particulier de synchronisation: un processus ne peut

entrer en section critique qu'aprs la sortie du processus prcdent. La synchronisation de
plusieurs processus entre eux ncessite la construction d'un mcanisme permettant un
processus:

- d'activer un autre processus par un signal en lui transmettant ventuellement de

l'information Les activations peuvent tre mmorises ou non. Dans le cas des
activations mmorises, le signal peut tre reu tout moment ( condition que le
processus rcepteur soit cr) et sera pris en compte lors du retour du processus
rcepteur l'tat lu ou ligible. Dans le cas des activations non mmorises, le signal est
perdu si le processus ne l'attend pas. Diffrentes exceptions sont donc ncessaires
implmenter pour traiter ces phnomnes non prws;

- de se bloquer lui-mme ou d'en bloquer un autre par un message d'vnement;

- d'envoyer un signal de rveil vers un ou plusieurs processus. Selon que ce signal soit
mmoris ou non par le processus rcepteur, le processus metteur ne se bloque pas ou,
au contraire, se bloque en attendant que le processus rcepteur renvoie un message de
retour.

Le mcanisme de synchronisation est direct lorsque le processus envoie un signal en dsignant

directement le rcepteur ou lui-mme; il est indirect lorsque le processus agit par
l'intermdiaire d'un mcanisme qui lui seul conna.J."t les processus concerns par l'action dsire.

Dans la synchronisation directe, trois types de mthodes du processus permettent

d'implmenter ces mcanismes:

- La mthode bloquer {processus) ou interrompre {processus) envoie un signal permettant

de suspendre un processus dsign ou lui-mme si on ne prcise pas le rcepteur;
- La mthode rveiller {processus) ou reprendre {processus) envoie un signal vers le
processus dsign;
- La mthode suspendreO, dormir 0 ou terminer 0 suspend le processus y faisant appel.

Ces trois types de mthodes, en incluant les deux mthodes de changement de contexte
constituent le minimum de cinq primitives de la gestion des processus et elles sont
implmentes dans un objet abstrait Processus. La plupart des outils de simulation objets
fournissent ces mcanismes travers soit des primitives du langage, soit des classes d'objets
spcifiques.
 188

Dans la synchronisation indirecte, les noms des processus synchroniser ne sont pas
directement dsigns par l'opration. La synchronisation s'effectue par l'intermdiaire d'objets
communs travers des primitives assurant l'exclusion mutuelle de ces objets ([SCIDPER 86],
[GEHANI 88], [BUHR et al. 92]). Deux objets sont gnralement utiliss, les smaphores et
les variables d'vnements. Un troisime objet, appel variable de rendez-vous, apporte une
contribution originale en permettant une gnralisation de ce moyen de synchronisation
plusieurs processus.

rn Outils et Langages Orients Processus pour la Simulation Objets

Actuellement, les outils et langages objets pour la simulation se multiplient. ll est difficile de
faire une synthse de ces outils. Notre objectif de recherche est de construire une plate-forme
pour la simulation oriente-objets; il est donc naturel de construire notre outil autour d'un
langage plate-forme C++. On peut classifier, cependant, les outils de simulation que l'on
rencontre dans la littrature selon trois catgories:

-langages orients-objets avec des primitives de supports (ou constructions syntaxiques)

pour la simulation comme Smalltalk: [GOLDBERG et al. 83], Simula [BIRTWISTLE et
al. 73], ADA [BARNES 88], MODSIM II [BELANGER 90b], Extend [HILL 93], etc.;

- extensions des langages en incluant des primitives de communication et de

synchronisation entre processus pour la simulation comme Concurrent C++ [GEHANI et
al. 88], SIM++ [LOMOW et al. 90], SIM Plus Plus [ROSE 92], DEVS/Scheme
[ZEIGLER 89], etc.;

- construction des librairies des classes spcifiques pour l'ordonnancement des classes
d'objets "threads" ou des vnements comme la librairie des classes tches de AT&T
([STROUSTRUP et al. 87], [SHOPIRO 87]), Simple++, Interactor [LABRECHE 90],
Meijin++ [NICOLAS 93], PRESTO [BERSHAD et al. 88], etc.

m.l Langages avec des Primitives de Supports pour la Simulation

DE VETTOR [DE VETTOR 91] a fait une comparaison de diffrents langages qui fournissent
des primitives pour la simulation tels que Smalltalk, ADA, AlRIC, C++, Actor, etc. Puisque
nous avons commenc nos recherches partir du langage MODSIM II (un premier langage de
simulation objets), nous prsentons donc les caractristiques principales de ce langage et
expliquons pourquoi nous l'avons abandonn.
 189

Le langage modulaire de la simulation MODSIM n est un langage universel et modulaire, qui

fournit un support pour la programmation oriente-objets et la simulation vnements
discrets. Ses syntaxes et structures sont trs similaires celles des langages Modula 2 et ADA
L'approche de la simulation adopte est l'approche par processus comme dans le langage de
simulation SIMSCRIPT ll.S. Les concepts d'encapsulation, d'hritage simple et multiple, les
mcanismes polymorphisme et liaison dynamique sont aussi supports par ce langage.

Les classes d'objets sont spcifies et implmentes dans deux modules correspondants de la
librairie: les modules de dfinition qui dfinissent les attributs et les mthodes d'objets (dans
ces modules, il n'y a pas de code d'excution), et les modules d'implmentation qui
contiennent le code qui implmente toutes les procdures et les mthodes d'objets. Les objets,
les procdures, ou les variables mentionns dans les modules de dfinition peuvent tre
imports par les autres modules. Par contre, les variables ou procdures dclares dans le
module d'implmentation ne sont pas accessibles par les autres modules. Tout module peut tre
compil sparment. Un programme de MODSIM n est compos donc de trois types de
module: un module principal et plusieurs modules de dfinition et d'implmentation.

La simulation est supporte directement par des "built-in" primitives. TI fournit ainsi une
librairie des classes d'objets prtes tre utilises. Pour dfinir une mthode synchrone, par
exemple, on peut utiliser la mthode suivante:

ASK objet TO mthode (liste des paramtres)

Une mthode asynchrone est dfinie comme suit:

TELL objet TO mthode (liste des paramtres) <IN temps>

Pour dfinir une mthode asynchrone avec l'objet TriggerObj afin de synchroniser deux objets
travaillant en parallle, on utilise la primitive WAIT:

W AIT triggerobject TO File

TELL triggerobject TO File

Pour interrompre une mthode asynchrone, on peut utiliser les primitives Interrupt (objet,
nom de mthode), InterruptMethod ACTID ou Terminate. Les classes d'objets pr-
construites avec ces primitives dans la librairie de MODSIM ll pour la simulation
 190

comprennent: diffrentes files d'attente (QueueObj, StackObj, RandObj), l'objet ressource

(ResourceObj), les objets statistiques (StatQueueObj, SINTEGER, SREAL, ... ),etc.

Le mcanisme d'ordonnancement peut tre structur comme indiqu dans le schma suivant
(figure 5-7): une liste des objets actifs, et pour chaque objet actif, on garde une liste de ses
activits parallles.

1'~----------- PendingList----------'>

A
c
t
-----+
1
v
i Act87 Act1 Act65 Act98
t 7.5 13.5 23.6 126.9
y

~~~;51
L Act8
i 154.9
s
t

~
Figure 5-7 Structure des Files d'Attente d'Objets Actifs et ses Activits

Malgr ses qualits, ce langage n'est pas retenu pour le dveloppement de nos applications
pour les raisons suivantes:

1) La visibilit de controle de temps du systme est cache de l'utilisateur. Nous ne faisont

intervenir que l'horloge du systme travers quelque primitives prdifinies. n est donc
difficile de construire des classes d'objets autonomes.

2) Nous voulons travailler sur une plate-forme de simulation sur micro-ordinateur. Bien qu'il
existe des logiciels graphiques (GRAPIDCS) pour MODSIM: ll sur des stations, ils
restent inutilisables sur des PCs.

3) MODSIM: ll nous semble difficile adapter pour des projets complexes ([YE 93],
[ROSE 92]). La compilation est trs lourde et le temps de dveloppement assez long.
 191

Puisque le langage de programmation C++ est devenu le standard pour le dveloppement d'une
plate-forme tant au niveau du modle qu'au niveau d'interface, nous avons dcid de
dvelopper notre simulateur en utilisant ce langage ds le dbut de l'anne 1992. Nous avons
tudi plusieurs bibliographies avant de prendre cette voie ([SHOPIR.O 87], [STROUSTRUP
et al. 87], [GEHANI et al. 88], [BERSHAD et al. 88], [LABRECHE 90], [BUHR et al. 90],
etc.). Le premier logiciel acquis de l'extension du C++ pour la simulation est une librairie
scientifique avec des objets threads: Meijin++ [NICOLAS 91]. Par la suite, nous avons obtenu
une extension du langage C++ pour la simulation: SIM Plus Plus [ROSE 92].

ll.2 Extensions des Langages pour la Simulation

Le progiciel SIM Plus Plus (SIM_P_P), une bibliothque de classes d'objets avec des
primitives pour la simulation, est un langage de simulation vnements discrets orient
processus, bas sur le langage de programmation C++. TI a t dvelopp l"Institute of
Telematics" l'Universit de Karlsruhe en Allemagne.

Le choix de l'approche par processus a t fait dans l'optique de simplifier la conception de

modles complexes, conception qui n'est pas toujours vidente avec la simulation vnements
discrets. Pour cela, le dveloppement de SIM_P_P a t fortement influenc par le langage
MODSIM TI. La diffrence entre ces deux langages est que SIM_P_P rend explicite la
dfinition du processus comme un objet: un objet coroutine (processus lger) qui permet
d'implmenter facilement des objets ayant un ou plusieurs processus.

Un objet dans SIM_P_Pest donc compos de trois types d'lments:

-"Data elements" qui dfinissent les caractristiques (attributs et relations) de la classe

d'objet. lls peuvent tre soit publiques, soit privs.
- "Metbods", ce sont des procdures identiques celles crites en langage C++, mais
elles ont le droit d'accder aux "data elements" des classes d'objets associes.
- "Process", ce sont des mthodes qui peuvent influencer sur le temps de simulation en
interrompant leur excution et en tant ractives aprs un laps de temps.

Les processus dans SIM_P_P doivent tre dclars dans une classe d'objet comme suit:

class <class name> {

Process (Proc name) (<parameters>);
}
 192

Puis dans une implmentation de la classe, la dfinition du processus se fait comme suit:

PROC (<class name>, <proc name>) (<parameters>)

{ (<local parameters>);
StartProcess (<process name>);
/*the code*/ ...
EndProcessO;
}

Les processus doivent tre activs pour qu'ils puissent tre "scheduled" et "maintained" par
l'ordonnanceur proprement, pour cela il y a deux manires:

- Activation asynchrone d'un processus: le demandeur (l'objet qui active ce processus)

n'attend pas que le processus en cours soit termin pour que sa requte soit satisfaite:
Activate (<proc name>, (<parameters>), double time = n);
le processus <proc name> sera dclench immdiatement au temps T = SimTime + n.

- Activation synchrone d'un processus: le demandeur est oblig d'attendre que le processus
<proc name> soit termin avant de poursuivre son excution et le processus en cours
verra son excution interrompue jusqu' la fin du processus <proc name>.
BOOLEAN WaitFor (<proc name>, <parameters>);

L'coulement du temps de simulation dans un processus peut se faire avec le primitive suivant:

BOOLEAN Wait (double time);

Ce processus est interrompu pendant une dure gale "time". L'arrt d'un processus se fait
par l'appel la routine Terminate Q. Tous les processus activs de manire synchrone et
concerns par ce processus seront termins galement.

On peut interrompre un processus. Pour cela il faut utiliser les primitives:

lnterrupt (<obj>, <obj class>, <proc>) pour interrompre un processus d'un objet;
ou
InterruptAII (<obj>) pour interrompre tous les processus d'un objet.

D'autres mthodes dfinies dans SIM_P_P qui permettent la gestion des processus sont:
 193

- CreateProcessQ: Crer un nouveau processus et sauvegarder son contexte;

- EndProcQ: La fin d'un processus (arriver son terme);
- CleanupQ: Dtruire les processus qui sont dans la liste de l'ordonnanceur ( la fin de la
simulation);
- MainTaskQ: C'est la premire tche effectuer lors d'une simulation, elle dclenche
l'excution des processus;
- StartSimulationO: Prcder Maintask dans la squence de dmarrage d'une excution
de la simulation;
- InsertEnvQ: Ordonnancer les processus en les insrant dans la liste des processus
d'attente "WaitList";
- RemoveProcQ: Dtruire un processus;
- NextTaskQ: Dterminer le prochain processus excuter.

Dans la bibliothque SIM_P_P, trois classes d'objets sont prdfinies pour grer la
synchronisation des processus: une classe "TriggerObj" identique dans le langage MODSIM
II, une classe "Rendez-VousObj" permettant d'avoir un mcanisme du type: un processus ne
sera dclench que quand tous les participants (invits au rendez-vous) seront prsents, et une
classe "Semaphore" servant grer les synchronisations au niveau des ressources partages.

Les autres utilitaires pour la simulation tels que les diffrentes files d'attente, les gnrateurs de
nombres alatoires, les classes statistiques et la reprsentation graphique des rsultats sont ainsi
dfinis. Le langage SIM:_P_P appartient la plate-forme du dveloppement: son architecture
est similaire celle que nous avons prsente dans le chapitre rn (figure 3-3). Une thse base
sur cet outil est en cours dans le dpartement [OUZOUT et al. 94].

Comme la dfinition des objets autonomes n'est pas dans la philosophie de base de ce langage,
il est difficile d'implmenter les concepts d'objets autonomes (agents) du chapitre IV. Notons
qu'il y a des diffrences entre la notion d'objet actif et d'objet autonome ou contrle. Un objet
actif fait avancer le temps de simulation, et un objet autonome (contrle) a non seulement les
caractristiques d'un objet actif, mais galement son propre flot de contrle. Le concept thread
permet d'avoir plusieurs flots de contrle (c'est--dire qu'il a ses propres activits et ressources
(attributs)) dans le mme espace d'adressage. n est naturellement intressant d'implmenter la
simulation avec des outils qui supportent le concept thread.

ID.3 Librairies des Classes "Threads" pour la Simulation

Plusieurs librairies des classes bases sur le langage C++ et le concept thread (mmoire
partage et objets communiquants) existent: la librairie des classes bases sur la notion tche
 194

du laboratoire AT&T Bell, la librairie des classes PRESTO base sur la notion thread pour
crire des systmes en temps rel, l'excutive du temps rel Interactors bas sur la notion
thread, la librairie scientifique de Meijin+ +, etc. Ds reprennent tous la notion de co-routine .
que l'on trouve dans le langage C ou C++ ([BINDING 85], [SHOPIRO 87], [GEHANI et al.
88], [AKERBAEK 93]) et la enrichissent pour supporter le concept thread .. Une forte
tendance de concept multi-threads existe mme dans le futur systme d'exploitation
([VARHOL 94], [POUTAIN 94], [WAYNER 94]). Nous prsentons l'une de ces librairies
travers la librairie Meijin++ que nous avons exploit dans notre cas de recherche.

Le progiciel Meijin++ est une bibliothque scientifique de composants prts tre utiliss. TI
transforme le compilateur C++ en un outil puissant de modlisation et de simulation. Meijin++
reprsente un systme rel par deux types d'objets: objets actifs et objets passifs. Un objet actif
a une activit autonome, il est implment comme un processus "lger" (light-weight process)
et il interagit avec l'extrieur travers des messages. On l'appelle parfois "objet autonome" si
on ne prcise par leur flot de contrle interne. Dans un modle de simulation, l'objet actif est
manipul et maintenu par le noyau de synchronisation (Scheduler dans Meijin++) travers ses
mthodes (fonctions membres). Un objet passif n'est pas gr directement par le Scheduler, il
est cre, manipul et dtruit par des objets actifs.

Dans Meijin++, tous les objets actifs drivent d'un objet actif abstrait Thread qui est
implment comme un processus "lger" ou prcisment une coroutine dans la mmoire. La
structure d'objet Thread est la suivante (figure 5-8): elle inclue les attributs locaux comme
l'espace d'excution buffer, les attributs statiques (globaux) comme l'horloge clock, le pointeur
sur l'objet chancier scheduler, le pointeur sur le processus actif courant current, l'attribut de
l'adresse courante d'excution basePtr, l'attribut de l'tat de la machine env, etc., et les trois
mthodes: suspendre (switch_out), reprendre (switch_back), commencer (spawn). La
mthode virtuelle runO du Thread va tre surcharge et raffine dans les classes d'objets
drives pour dfinir leurs propres comportements temporels (mthode fonctionner).

En utilisant cet objet abstrait, on drive un objet processus Process qui ajoute des mthodes
membres pour synchroniser les activits des objets actifs et rsoudre d'ventuels conflits entre
deux objets dont les activits se recouvrent dans le temps. En fait, chaque processus peut tre
dcompos en plusieurs "segments" qui sont excuts squentiellement ou diffrentes tapes.
Un objet processus peut tre en diffrents tats. TI peut tre en:

- tat lu ou en cours (CONTROL),

-tat ligible ou prt (SCHEDULED),
-tat bloqu ou en attente (IDLE),
 195

- ou tat mort ou non-oprationnel (Kll..LED).

La communication entre les diffrents objets actifs dans le Meijin++ se base sur les trois
diffrents scnarios suivants:

Thread

*current )
(pointeur sur le processus actif) switch_out
(mthode pour susprendre l'excution)

s *rout
switch_back
(pointeur sur le module principal:
(mthode pour reprendre le contrle)

spawn
s *basePtr (mthode pour crer une coroutine et
(addresse de dpart d'excution)
dclencher l'excution de ce processus)

*scheduler )
C.___~(p~o~ite=u:!...r.::::SU:!..r.:::le:..::Sch=e~du~le::::!rt...)_ __,
reschedule
(re-lancer ce processus)

*buffer
(espace de pile occupe par cette coroutine)

v rank
(mthode virtuelle pour dfinir la

v
run

lgende: v
S: static store
V:virtual (mthode virtuelle pour enregistrer les valeurs d'objet)

Figure 5-8 Diagramme de Structure de l'Objet Thread

- Exclusion mutuelle pour le partage des ressources. Une ressource ne peut tre utilise
que par un processus la fois et elle sera libre quand le processus se termine.
 196

- Communication par des messages asynchrones avec une file d'attente commune.
Quand l'metteur (producteur) envoie une entit (un message asynchrone) dans la file d'attente
en aval, il va vrifier cette queue: si elle est vide, il va gnrer un message "File-non-Vide"
pour dbloquer le processus en aval; si elle est pleine, il se bloque lui-mme; sinon, il dpose
l'entit dans la file et continue son activit. Quand le rcepteur (consommateur) prend une
entit dans la file d'attente en amont, il va aussi vrifier cette queue: si elle est pleine, il va
gnrer un message "File-non-Full" pour dbloquer le processus interrompu en amont; si elle
est vide, il va se bloquer; sinon, il enlve l'entit de la file et poursuit son activit. On le dsigne
aussi comme mode producteur-consommateur (communication bloquante).

- Coopration directe entre les processus par des messages synchrones. Un processus
(client) se bloque par un autre processus (serveur) et attend d'tre rveill par son serveur. On
l'appelle souvent le mode client-serveur.

On enrichit donc les mthodes membres suivantes concernant la synchronisation, la

communication et la gestion du temps de simulation dans l'objet Process:

*Avancer l'horloge du systme par une priode fixe du temps en excutant:

Process: :delay(unsigned);

* Etre bloqu sans condition jusqu' la ractivation par un autre processus en excutant:

Pro cess:: block(Thread *);

* Etre bloqu jusqu' la terminaison d'un processus ou d'un ensemble de processus en

excutant:

Process: :pending_one(Thread**, unsigned)

ou
Process: :pending_all(Thread * *, unsigned);

* Bloquer le processus actif courant jusqu' ce qu'il se termine en excutant:

Process: :pre_emptyQ;

En combinant ces mthodes, on obtient le diagramme des transitions d'tat d'un objet actif
suivant (figure 5-9):
 197

.,____ _ _~ Process::block

~--------------~Th~r~e~ad~:~:e~n~t~s-----------

Figure 5-9 Diagramme des Transitions d'Etat d'Objets Actifs

A partir de ces deux classes d'objets de base, Meijin++ fournit trois classes d'objets actifs pour
dfinir des objets autonomes de la simulation: une classe Server qui sert dfinir un objet actif
qui a une file d'attente en entre et une file d'attente en sortie, une classe QNode qui an files
d'attente en entre et n files d'attente en sortie et une classe Timer qui sert dfinir des
mthodes qui vont arrter l'objet du type Server ou QNode (un processus de panne, par
exemple) pendant un laps de temps.

Les autres classes d'objets tels que les classes d'objets utilitaires/auxiliaires pour la simulation
comme les gnrateurs des nombres alatoires, les classes d'objets analyses et statistiques, les
classes d'objets d'application comme les diffrents ordonnanceurs (Heap, CalQueue, SortList,
... ), les classes d'objets mathmatiques, etc., sont ainsi prdfinies dans la bibliothque (figure
5-l 0). Meijin++ fournit aussi une bibliothque des classes d'objets d'interface graphique appel
Plots Video pour le MS-DOS.

Dans la suite, nous exploitons l'implmentation des objets dvelopps dans les deux chapitres
prcdents travers les classes d'objets du Meijin++: comment dfinir les services des objets
actifs smantiques identifis dans le chapitre rn partir des mthodes d'objets Thread et
Process. La hirarchie des classes d'objets passives (classes d'objets transactionnels et classes
d'objets dcisionnels) base sur la classe d'objet Item de Meijin++ est prsente la fin du
chapitre.
 198

=
Simulation InAouny

==~~c;r-E- 5:. on er rr
MemErr .---- ExpD ---;
ErlangD
ParetoD
ProcessErr Cauchy - - WeibuilD
1---BetaD ExtremeValueD
Memory 1---Norma!Fi
Terminate Distribution - - 1 - - - PoissonD
Unexpected
1--- g:~~FDistD
1---VonMisesD StudentD
Genera ....____ BernouilliD

Be~ FdistR
-----1CauchyR
--C
1 - - - - ChiSqR StudentR
r---PascalR
Random --i---NormalR ~ErlangR
---ExpR --a~~
1 - - - - PoissonR Lo~~cR
Complex t----UniformR We1builR
r---BinR

Kalman~P::es
r - - - - - Regression
r - - - - - Filter-- Smooth
.s------; Fffi: MoveAverage
FWmdows
r - - - - - Forecast Decompositionj
-----Moments
'------Hist
Hash
Dlist . _ r - - SortQ
PQu -E_SortList ~ SharedQ
T ~ue CalQueue
Containe---+-- ~:es
8 Heap
DynArray
Tracer -ducer
rator Consumer
Item--
B Thread
Message
--c:= ~~:s Server .
ode

Figure 5-l 0 Hirarchie des Classes d'Objets Prdfinies par Meijin++

 199

IV Simulation Oriente-Objets

IV.l Environnement du Modle de Simulation

Nous avons propos, dans la section ill du chapitre N, une architecture de modles de
simulation constitue de trois modules: pr-simulation, simulation et post-simulation. Le
module de pr-simulation est utilis pour construire, configurer et documenter les modles de
simulation et les composants (classes d'objets) du modle. Le module de simulation gre
l'excution du modle et collectionne les rsultats de sortie dsirs qui seront analyss par les
objets du module de post-simulation. Popken [POPKEN 92] a propos une architecture de
dveloppement des modles de la simulation (figure 5-11) qui nous semble bien adapter notre
structure de dveloppement. Trois bases de donnes correspondantes doivent tre associes
avec ces modules: base de donnes de l'architecture du modle qui constitue l'ensemble des
classes d'objets du systme, base de donnes du modle de simulation courant qui constitue des
objets exprimentaux de la simulation et base de donnes auxiliaires qui constitue des objets de
statistiques et d'aides, etc., pour les modules pr/post-simulation.

Pr-Simulation
Simulation
Crer les Classes d'Objets de Simu.
Construire les Modles de Simu. Grer l'Excution de Simu.
Concevoir les Scnarios de Simu. Collectionner les Donnes
Construire le Projet l'Appli.)

Post-Simulation
Estimation des Paramtras
Test des Hypothses
Analyse de Sensibilit

Figure 5-11 Architecture du Noyau de Dveloppement de Modles de la Simulation

 200

Ce noyau de dveloppement est dcompos en six tapes dans le progiciel Meijin++:

Etape 1: Initialisation de l'excution en extrayant les donnes du scnario dfinies par le

module de pr-simulation (choix de la structure de l'ordonnanceur, des primitives
de commande, des gnrateurs de nombres alatoires, etc.);

Etape 2: Instanciation des classes d'objets passifs (pices, gammes, ateliers, etc.);

Etape 3: Instanciation des classes d'objets actifs (machines, transporteurs, processus de

commande, stations, rgles de management, etc.);

Etape 4: Excution de la simulation;

Etape 5: Analyse des donnes et valuation des performances;

Etape 6: Mise jours de bases de donnes et destruction des objets du modle de la

simulation courante.

Une interface graphique avec des menus de contrle facilite le travail des utilisateurs et rduit
les lacunes entre les modles conceptuels et ses implmentations. Puisque le modle de
simulation des systmes de production est complexe, divers utilisateurs peuvent intervenir dans
cette plateforme. Nous classifions ces intervenants en quatre niveaux d'utilisation (figure 5-12)
[YE 93]: 1) niveau dcideur, 2) niveau constructeur de modles, 3) niveau dveloppeur de
classes du domaine et 4) niveau concepteur et programmeur de classes lmentaires. Au niveau
dcideur, peu d'exprience de la simulation est ncessaire, les dcideurs ou les analystes
modifient simplement des paramtres sur des modles de simulation ou sur des outils
statistiques prdfinis. Au niveau 2, les constructeurs de modles slectionnent les classes
d'objets disponibles contenues dans la librairie des classes et les instancient pour construire un
modle de simulation. Les modles sont construits, tests et compils pour tre utiliss par les
dcideurs. Au niveau 3, les dveloppeurs de classes dfinissent, testent et valident de nouvelles
classes d'objets du domaine pour la simulation, ils enrichissent les classes d'objets smantiques
et les classes d'objets mathmatiques et auxiliaires, et valident ces instances pour bien couvrir
le domaine de l'application. Ces classes vont tre utilises au niveau 2. Enfin, au niveau 4, les
programmeurs utilisent un langage de programmation pour construire des classes de base pour
la simulation telles que les listes, les processus, le noyau de synchronisation des processus
(scheduler), l'interface graphique, les objets statistiques, etc.
 201

Les deux premiers niveaux correspondent aux tches des utilisateurs qui modlisent et utilisent
leur propre modle de simulation en instanciant et unissant les classes d'objets disponibles. Les
deux derniers correspondent aux tches des dveloppeurs ou concepteurs qui se concentrent
sur la mise jour des classes d'objets existantes et implm~ntent de nouvelles classes d'objets
du domaine qui seront utilises ultrieurement. Les classes d'objets du domaine (smantiques)
et de rsolution du problme (niveau trois) ont t abordes dans les deux chapitres
prcdents, nous dtaillons donc ici les liens entre les niveaux trois et quatre en nous basant sur
le progiciel Meijin++ pour implmenter la hirarchie des objets des systmes de production.

Niveau IV -Niveau Concepteur et Programmeur des Classes Elmentaires

Niveau II -Niveau Constructeur de Modles

Niveau 1-Niveau Analyse

(Niveau Dcideur)

Figure 5-12 Niveaux d'Utilisation du Modle de Simulation

IV.2 Hirarchie des Classes d'Objets des Systmes de Production

Avant de prsenter la hirarchie des classes d'objets de la production, quelques notions ou

techniques de programmation pour la hirarchisation des classes d'objets et son implmentation
doivent tre claircies. TI s'agit: de niveaux de modlisation pour dterminer les ports des
attributs d'objets, des notions d'encapsulation, de persistance d'objets, de directives de
prprocesseur, de constructeurs et de destructeurs des classes d'objets, etc.

Les constructeurs et les destructeurs dterminent la manire de crer, d'initialiser, de copier et

de dtruire les objets d'une classe. Un objet peut tre cr statiquement (une dclaration de la
classe) ou dynamiquement (utilisation de l'oprateur new), avec des arguments si on veut
initialiser certains attributs ou sans arguments s'il s'agit d'un constructeur implicite. Nous
 202

prconisons que chaque classe doive avoir un constructeur implicite qui fit appel une
fonction membre protge initQ pour initialiser les attributs structurels et conjoncturels
d'objets en extrayant les valeurs d'une base de donnes ou travers une intetface
d'interrogation graphique. Les directives du prprocesseur sont utilises pour amliorer la
petformance de simulation du modle. Par exemple, l'excution d'un modle avec la directive
M_SUIVI est plus longue que celle sans suivi, mais elle fournit des indicateurs de petformance
de sortie plus complets et plus dtaills. Pour qu'on puisse faire l'excution d'un modle de la
simulation de faon itrative, tous les objets smantiques doivent tre persistants, en d'autres
termes, chaque classe d'objet est capable d'enregistrer (ou de lire) dans un fichier ces attributs
concerns. La notion d'encapsulation sert contrler la visibilit des attributs d'objets,
modliser les niveaux d'abstraction (droits d'accs des utilisateurs), etc.

IV.2.1 Hirarchie des Classes d'Objets Actifs

Les classes d'objets actifs sont des classes drives directement ou par l' intermdiaire de l'objet
Process du Meijin++. Une machine, par exemple, est hrite directement de l'objet Process
avec des attributs dcrits dans le modle d'information de la machine (figure 3-22 du chapitre
Ill). Les services identifis lors de l'analyse sont concrtiss et implments par des mthodes
correspondantes qui sont illustres dans la figure 5-13.

delay(long) schedule()
block(Thread*) rank()
pending_one(Thread**, unsigned) exits(long)
pre_empty() spawn()
pending_all(Thread**, unsigned) run()
select_fromQO add_temps_reparation(t)
choisir_lot(Lot) add_temps_usinage(t)
choisir_mode_FAS(Mode) add-temps-attente(t)
set_mode (Mode) add_temps_panne(t)
add_compteur(i)
recevoir() valeur()
preparer()
transformer () temps-moyen-attente
expedier(Pice)
nombre-moyen-attente
traiter_panne() taux_occupation()
mthodes pour manipuler taux_rebuts()
les attributs loi_panne()
etc nombre_lot_fabrique()

Figure 5-13 Mthodes de la Classe Machine

 203

Les mthodes listes au-dessus de la ligne discontinue dans la figure 5-13 sont prdfinies dans
Meijin++. Les mthodes delay, block, pre-empty, pending-one et pending-all sont expliques
dans la section ill.3. Notons que la mthode pre-empty ne peut pas tre utilise pour dfinir
des processus pr-emptifs malgr la bonne volont des concepteurs du Meijin++, puisque le
mcanisme d'ordonnancement implment dans Meijin++ ne pennet pas d'interrompre un
processus thread (d'ailleurs, la notion thread n'autorise pas au fond d'installer des processus
pr-emptifs). La mthode schedule sert modliser la slection du prochain processus en tat
ligible et ventuellement l'avancement de l'horloge du systme. La mthode spawn est utilise
pour activer un processus l'tat non-oprationnel et la mthode exits est une mthode
surcharge de l'oprateur standard ::exits du C++ pour des objets de type processus. Toutes
ces mthodes systmes concernant des primitives de cration et de coopration des processus
ne doivent pas tre accdes et surcharges par les utilisateurs. Cependant, les mthodes rank
et run sont des mthodes virtuelles qui seront en gnral redfinir par les utilisateurs: la
mthode rank sert dfinir la priorit du processus dans l'objet ordonnanceur (schedule) en
combinant le degr d'urgence du processus dans le monde rel et sa prochaine date
d'vnement; et la mthode run (que nous avons nomm fonctionner dans les objets drivs de
Process dans les chapitres prcdents) est la mthode principale surcharger par l'utilisateur
pour dfinir le comportement temporel (cycle de vie) particulier de chaque machine.

Les mthodes listes au-dessous de la ligne discontinue dans la figure 5-13 sont des mthodes
ajoutes au niveau de la classe machine:

-Les mthodes telles que add_temps_reparation, add_temps_usinage, add_temps_attente,

etc., sont des mthodes accs du type lire et crire (s'il y a des attributs correspondants);
- Les mthodes telles que temps_moyen_attente, taux_occupation, taux_rebuts,
nombre_lot_fabrique, etc., sont des mthodes transformations du type calcul (sans
gnration d'vnement asynchrone pour bloquer et dbloquer les activits de la machine);
- Les mthodes telles que select_fromQ, choisir_lot, set_mode, etc., sont des mthodes
virtuelles, appeles par des processus (mthodes bloquantes) de la machine, pour dfinir la
gestion des activits (processus) en appelant des objets dcisionnels concerns. Par
exemple, la mthode select-fromQ modlise le choix du prochain lot (mais ne pas un
article) transporter d'une machine qui alimente la file d'attente amont de la machine
courante celle-ci. On peut, l'intrieur de la mthode, appeler la mthode choisir-lot
pour choisir des lots candidats transporter s'il y a plusieurs lots prts tre transports,
et la mthode select-fromQ va dterminer ultimement le lot transporter selon la
disponibilit des ressources et des transporteurs et lancer (activer) le processus du
transporteur slectionn.
 204

- Les mthodes recevoir, preparer, transformer, expedier et tranter_pnne sont des

mthodes bloquantes ou asynchrones qui ont t expliques prcdemment dans les
modles de processus de la machine du chapitre N.
- D'autres mthodes accs et test qui ne sont pas prcises dans la figure 5-13 comme la
collection des donnes et les mthodes statistiques sont triviales. Elles seront dfinies
selon les niveaux (dtails) et l'objectif de la modlisation de la machine.

La classe Station est un objet driv ainsi de la classe Process du Meijin++ avec des mthodes
en plus, telles que la gestion de ses serveurs, l'administration du temps de l'horloge, la gestion
de panne des serveurs, la configuration des serveurs, etc. Les serveurs sont des machines qui
effectuent rellement les oprations sur des articles; mais la gestion des processus des machines
est encapsule dans les processus de la station. En d'autres termes, la classe station est une
abstraction (un processus logique) des n machines qui ont les mmes comportements.

La classe d'objet Transporteur circule entre les n machines dans l'atelier. Elle a donc n files
d'attente amont qui sont des files d'attente aval de machines de l'atelier et n files d'attente aval
qui sont des files d'attente amont de machines (figure 5-14). Les mthodes ajoutes par rapport
la machine sont: les choix de trajet de transfert, la dtermination de la taille de lot de
transport, les choix de pices transporter s'il y a plusieurs pices prtes tre transportes,
etc. Le tableau 5-1 liste les mthodes principales installer dans l'objet Transporteur en termes
du domaine. Cet objet est driv d'une classe d'objet QNode prdfinie dans Meijin++.

mise en service choisir le lot transporter

acqurir des ressources
acqurir un trajet du rseau
charger des articles
dplacer des articles
dplacer vide
librer des ressources
traiter la panne
retourner la valeur actuelle du transporteur
... ...
mthodes mise iour des donnes
dterminer la taille du lot transporter
choisir le trajet de transfert
choisir des ressources
choisir la vitesse
calculer le taux d'utilisation
calculer le temps moyen d'attente
calculer la distance du trajet
calculer le temps de transfert
......
mthodes statistiques, etc.

Tableau 5-1 Mthodes d'un Objet Transporteur

 205

n faut prciser que l'utilisation de ces mthodes pour dfinir le comportement des transporteurs
dans la mthode fonctionner est trs subjective et diffrente selon le type de transporteurs:
convoyeur, chariot filo-guid, chariot libre, etc. La figure 5-15 illustre le diagramme gnral
des transitions d'tat d'un objet transporteur. On voit ici que les mthodes impliques sont
limites. n n'y a pas des appels des mthodes comme dterminer la taille du lot transporter,
choisir la vitesse, calculer la distance, etc. Cela dpend de l'application modliser.

Queue n+l
~ ' '
.~ Queue 1

Queuen+2 1 .. , . , 1 Queue2

Queue2n-1
f - - -_ ; ; ;~ - : ~ Transporteur k:-::. .. i
'
'
'
Queuen-~
,
Queue2n ~. '' 1 Queuen

Figure 5-14 Structure de la Classe Transporteur

Figure 5-15 Diagramme des Transitions d'Etat d'un Transporteur

La gestion de panne, la gestion de temps de prparation et le contrle technique d'un objet actif
sont raliss par des classes d'objets drives d'une classe Timer du Meijin++. Ces classes
consistent arrter un processus pour un laps de temps. On obtient donc une hirarchie des
classes d'objets actifs prsente dans la figure 5-16 qui couvre les objets smantiques minimum
dans les systmes de production. On voit qu'il n'y a pas l'objet atelier dans la hirarchie des
classes d'objets actifs. En effet, un objet atelier est un objet passif qui dfinit l'organisation des
 206

machines, des stations et des transporteurs. Le comportement de l'atelier est manrrest par ses
composants qui sont contrls par des rgles de management dfinies pour cet atelier. Bien
entendu, on peut dfinir une telle rgle comme un processus logique qui conduit directement
les processus physiques de chaque composant de l'atelier au lieu de les considrer comme des
objets passifs (rgles ou algorithmes). Mais comment peut-on les implmenter dans le sens
informatique. Nous n'avons pas tent de les implmenter avec le support du Meijin++.

/~
Operator /ead~

Consumer Macliine
r'~
Station QNode Produf
Timer
/\._

~ Rot ~C ~1~Product-~:: Control Breakdown

Product-Output FreeTrans QuideTrans

Figure 5-16 Hirarchie des Classes d'Objet Actifs des Systmes de Production

IV.2.2 Hirarchie des Classes d'Objets Passifs

Nous avons prsent, pour chaque objet actf: les processus essentiels de la production.
L'enchanement de ces processus est conditionn (mthode fonctionner), d'une part par leur
tat, d'autre part par les flux de production (matire) et d'information. Les contraintes
conomiques et les critres de performance exigent moins la prise en compte de chacun de ces
processus indpendants les uns des autres que leur bon enchanement au sein de la notion de
flux matire qui influence directement les performances de la production. En d'autres termes, il
faut intgrer les classes d'objets de transaction (au niveau d'atelier du modle) et des classes
d'objets dcisionnels (aux niveaux d'unit de production et de systme de production du
modle) afin de construire un modle global de la simulation. Ces deux types des classes
d'objets sont des objets squentiels ou passifs qui n'ont pas un comportement autonome.

Les classes d'objets passifs implmentes dans la librairie sont divises en deux catgories: des
classes d'objets drives de la classe d'objet Container et des classes d'objets drives de la
classe Item qui seront stockes dans des classes conteneurs. La figure 5-17 illustre la hirarchie
des classes d'objets passifs implmente avec le progiciel Meijin++. Les produits, les pices et
les objets manipuls par des objets actifs sont drivs de l'objet de transaction Item. Les
 207

diffrentes files d'attente qui arrangent les objets circulants sont drives de l'objet d'association
SortList. La gamme (OpList) et la nomenclature (PartList) sont des objets persistants qui
drivent respectivement des objets de listes simples et doubles.

lte Container
_______, ~t ~
Product
/
Mess~e

\ . Operation
i~ 1 \Part Resource Slist
t
~ue

'l'
Dift
'l'
ProductionOrd/r
Ba
ServerRes
OpList
SharedRe~
MargeQueue
t
SortList

SPrQueue
~
PartList

EDDQueue
Transformation Assemblage Transfert

Figure 5-17 Hirarchie des Classes Passives des Systmes de Production

Nous dtaillons ici seulement l'enchanement des flux des attributs et des mthodes d'un objet
pice dans le modle de simulation. La figure 5-18 liste le diagramme des transitions d'tat
d'une pice dans l'atelier. La diffrence de ces tats consiste dans le calcul des performances du
systme (cot de production, temps moyen d'attente, cot de stockage, etc.). Les transitions
d'tat de la pice sont manipules par des objets actifs tels que les machines et les
transporteurs. Par exemple, quand une machine prend une pice dans la file d'attente amont, la
mthode recevoir de la machine va d'une part modifier l'tat de la pice: tat stock ---> tat
production, d'autre part accder aux attributs de la pice comme l'accs du temps opratoire
dfinis dans la mthode tempsOpratoire de la machine illustre comme suit:

TIME Machine::TempsOpratoire 0 {
Part* pice;
OpList gamme;
Operation op;
pice= choisir_piceQ; //Slectionner la pice fabriquer dans la FAE
gamme= *(pice->gamme); //accder la gamme de la pice slectionne
op= *(gamme(pice->position)); //extraire l'opration courante de la pice
tempsOpratoire = op.tempsOpratoire; //accder au temps opratoire
retum tempsOpratoire;
}

La relation entre la machine, la pice, la gamme et l'opration est une implmentation de la

relation de l'application. L'utilisateur n'oblige pas de connatre ces dtails d'implmentation
 208

(encapsulation). D'autres structures peuvent aussi tre utilises dans la modlisation. Cela
dpend de l'outil choisi et de la prfrence du concepteur des classes d'objets.

Figure 5-18 Modle d'Etat d'une Pice

Un autre exemple d'utilisation de l'objet comme la nomenclature qui est un objet association
(arborescence) et qui est initialise avant le lancement de la simulation par les attributs
structurels et conjoncturels d'un objet produit (figure 5-19). Dans le module pr-simulation, on
dfinit une procdure pour ordonner les dates de lancement de ces composants dans le temps;
on obtient donc un schma du type PERT. Les donnes dduites de ce calcul constituent les
valeurs initiales des attributs conjoncturels des composants du produit pour dfinir les
scnarios de simulation. Diffrents algorithmes peuvent tre pr-installs dans la librairie.
Lorsque l'utilisateur (niveau dcideur) lance la simulation, il prend la responsabilit d'adopter
les algorithmes qui lui conviennent. On dit aussi que c'est une pr-simulation dans ce cas.

IV.2.3 Utilisation des Classes d'Objets dans la Simulation Concurrente

Nous avons test ces classes d'objets par diffrents modles suivants (les programmes
correspondants sont lists dans l'annexe 2):

- Modle 1: une machine avec un gnrateur de pices en amont et un consommateur en

aval (pour produire un rapport de sortie, par exemple);
- Modle 2: un variant de modle 1 en ajoutant des oprations de retouche (un processus
de feed-back pour la machine);
- Modle 3: deux machines travaillent en parallle avec un gnrateur de pices commun
et un consommateur en aval;
- Modle 4: une rduction du modle 3 dans lequel les deux machines sont remplaces par
un objet station;
-Modle 5: X machines ou stations en cascade (un atelier de type flow-shop);
-Modle 6: X machines ou stations en interconnexion par les files d'attente (un atelier de
type job-shop);
-Modle 7: deux machines avec des ressources partages, etc.
 209

Dlai
r--_,______
Cumul:5 14 10
Composant! Composant2 ComposantS
6 3 8
Dlai
Cumul:ll 9 14
9(_omencfature un Proauit avec Ce tzmps tfe Cycfe '1&nique tfes Composants

C'l
Dbut Composant 1
~1"'
1
1 Fin
a :::
Dbut l---,_:11---l Fin ~
.l!l ~

~ J
Dbut I--Co_m~po_san_t_2_-1Fin
..
:
1j
$0
Dbut ~Fin

i
Dbut 1----iJ----IFin
~

.,.,.1 ......_., Fin

Composant 6 Fin
Dbut 1

14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Figure 5-19 Utilisation de l'Objet Nomenclature dans la Prise de Dcision de Lancement

Nous avons surtout fait attention aux oprations de synchronisations temporelles entre les
processus. Les rsultats des modles sont utiliss pour valider les mthodes synchrones
installes dans les classes d'objets actifs. Deux types de dcisions ont t tests avec ces
modles: les modles 1, 2, 3 et 4 sont utiliss pour tester les rgles de priorit (rgles locales)
 210

et les modles 5 et 6 sont utiliss pour tester les rgles locales et globales (rgles de
management). La gestion des ressources pour la synchronisation entre processus est illustre
par le modle 7. L'objet actif transporteur est plus dlicat implmenter sans un modle de
simulation (une macro-structure du systme) avec le support du Meijin++. Ds que la
conceptualisation des processus de transporteur soit finie, nous essayons d'tendre notre
modle la gestion de transporteur au niveau d'atelier.

V Conclusion

Longtemps l'informatique a trait des problmes pour lesquels la ralit du temps qui s'coule
n'intervenait pas. Cette situation s'inverse maintenant parce que l'informatique entre dans la
rsolution de problmes qui, par nature, ne peuvent ignorer cette ralit du temps (la
simulation vnements discrets, par exemple). Dans ce chapitre, nous avons commenc par
les concepts de base de la programmation concurrente: la notion de processus et les
cooprations entre les processus en terme informatique. Ensuite, nous avons prsent trois
langages ou outils bass sur le langage de programmation C++ qui permettent d'implmenter
les modles de simulation concurrente. Enfin, nous avons choisi un outil parmi ceux-ci pour
illustrer comment nous avons implment les classes d'objets des systmes de production.

Cependant, l'intervention du temps dans les modles pose d'autres problmes difficiles. Cela
tient aux raisons suivantes [THORIN 90]:

1) La difficult de formalisation des problmes temporels. Cette difficult vient,

d'une part par la pauvret d'expression de concepts temps rel dans des langages de
programmation, d'autre part par le choix des modles de la reprsentation des concepts temps
rel (par exemple comment nous dfinissons des critres pour qualifier une entit du monde
rel comme un objet processus [GOMMA 84] dans le modle de simulation).

2) Les conflits causs par des ressources limites. Cette difficult est relle et
invitable. On se rencontre ces conflits trs frquemment dans la vie courante. En effet, si le
temps ne comptait pas, il serait concevable de traiter mme un problme trs complexe sur une
machine quelconque; mais le temps est lui-mme une ressource limite, et l'impossibilit de
srier compltement l'emploi de la ressource temps conduit des conflits d'emplois simultans.

3) La survenance alatoire d'vnements. Le hasard est une notion subjective tenant

l'ignorance des causes ou du moins l'impossibilit pratique d'en tirer des conclusions utiles.
La difficult est donc de se prmunir contre les consquences de l'ignorance de certains
vnements alatoires ou du moins de l'instant o ils surviennent.
 211

Ce chapitre a eu pour prsenter une synthse des problmes rencontrs dans la simulation des
systmes de production et de leurs solutions informatiques, savoir:

*la formalisation des objets actifs (comportements temporels des processus);

*la communication et la synchronisation entre objets actifs (des conflits entre objets);
*et la prise en compte de l'alatoire (dynamicit des processus).

Cependant la plupart des langages de simulation ne fournissent pas de moyens pour exprimer
naturellement ces concepts (ils ont dtourn la reprsentation de problmes par certains
lments ou prcisment certains blocs comme on les trouve dans les langages SIMAN,
SLAM, GPSS, etc.). Les langages objets sont choisis par leurs nombreuses qualits dans le
gnie logiciel, mais les concepts temps rel n'ont pas encore t intgrs dans la plupart des
langages objets. Les objets sont accessibles via des mthodes dfinies par une classe ou un
prototype. Dans le modle objets concurrents, chaque objet possde son propre flot de
contrle. L'extension des langages objets en des langages objets concurrents
(communicants) est propose dans la littrature ([CAROMEL 93], [MEYER 93], [THOMAS
92], [ISHIKAWA et al. 92]) pour les problmes d'implmentation. Nous avons prsent, parmi
ceux issus du langage C++ que nous connaissons, ceux qui rpondent la simulation
vnements discrets par l'approche processus: MODSIM ll, SIM Plus Plus et Meijin++. Enfin
nous avons choisi Meijin++ dans lequel chaque processus est un objet actif qui possde des
primitives de cration de processus et des mcanismes de communication et de synchronisation
entre eux comme un outil de base pour construire la hirarchie des classes smantiques pour la
simulation des systmes de production.

Pour conclure, l'utilisation des langages objets concurrents pour la programmation des
modles de simulation des systmes de production est puissante et attractive. Deux approches
existent pour unifier les concepts objets et concurrence dans les langages de simulation
objets:

* dans la premire approche, o la notion de processus est orthogonale celle d'objet, un

processus doit s'attendre chaque instant de son existence tre interrompu par un autre
processus comme nous avons prsent dans les langages MODSIM et SIM Plus Plus.

* dans la seconde approche, o les processus et les objets sont synonymes, les processus
interagissent en des points parfaitement dtermins: l o un message est mis et l o il
est reu comme on le trouve dans l'outil Meijin++.
 212

Cependant, la combinaison de la concurrence et de l'hritage est complexe, car les mthodes

des classes drives peuvent invalider les protocoles d'accs dcrits dans les mthodes des
classes suprieures. De nombreux auteurs concluent l'impossibilit de concilier concurrence
et hritage [AMERICA 89]. D'autres autorisent l'hritageen restreignant les mthodes hrites
et/ou la localisation des instructions de synchronisation. Dans Meijin++, c'est la mthode
virtuelle run (fonctionner) qui sert dfinir les activits squentielles pour les objets actifs, et
elle est la seule pouvoir tre redfinie pour les cooprations temporelles avec d'autres objets
actifs dans une classe drive.

TI faut noter que une tendance de plus en plus forte une conception de langage multi-
paradigmes: procdure, dclarative, logique, parallle/distribu, objet, etc., va certainement
modifier et faciliter la simulation objets concurrents. Nous ne avons pas prsent ces aspects
dans la mmoire, car il dpasse notre cadre de travail.
 Conclusions et Perspectives

1 Rsum du Travail

Depuis l'avnement de Simula et de Smalltalk dans le dveloppement de logiciels dans divers

domaines, de nombreuses recherches (mthodes d'analyse et de conception, langages de
programmation) ont t effectues afin de rendre les applications objets plus volues et plus
fiables et les dveloppements spcifiques moins coteux et plus volutifs.

Tout chercheur dans ce domaine sait que les systmes objets ne naissent pas dans un monde
vide. C'est pourquoi les mthodes, les langages et les outils voluent pour rutiliser et rendre
rutilisables les dveloppements entrepris, sous la forme de bibliothques de classes. Une
pression immense sur l'laboration de normes d'objets conduit la plupart des fournisseurs de
classes vers la standardisation d'objets [SNYDER 93]. Dans l'avenir, nous pouvons imaginer
que nous trouverons sur le march les briques de composants logiciels qui nous conviennent.
Mais les lments spcifiques d'un domaine ou d'un mtier seront toujours dvelopps sur
mesure. C'est dans cette optique que nous avons effectu notre recherche: essayer d'appliquer
les technologies objets pour la modlisation et surtout pour la simulation des systmes de
production.

Aprs avoir survol les systmes de production et les mthodes de la gestion de production
dans le chapitre 1, nous constatons que les systmes de production sont des systmes
complexes, dont la comprhension et la gestion (prvision) de comportement passent
ncessairement par une tape de modlisation. Car c'est partir d'une observation de l'existant,
dont on analyse la complexit en identifiant les composants reprsentatifs des systmes
manufacturiers qu'on labore les modles de ces systmes.

Modliser la structure des systmes permet de mieux comprendre ce qu'ils sont. Des modles
de structure (SADT, MERISE, GRAI, CIMOSA) ont t prsents dans le chapitre n. Or
pour un systme complexe tels que les systmes manufacturiers, il ne suffit plus de faire une
analyse du fonctionnent (mthode SADT et GRAI) de chacun de ses composants avant de les
assembler (mthodes MERISE et CIMOSA), il faut modliser le comportement global et local
des composants avant d'affecter un rle chacun de ces composants pour une application
 214

particulire, c'est--dire qu'il faut dcrire comment les composants (objets) doivnt fonctionner
avant d'expliquer comment un systme (modle) fonctionne. Cela nous conduit construire des
modles de simulation des systmes de production en utilisant l'approche par objet.

Les mthodes d'analyse et de conception objets se sont multiplies ces dernires annes.
Cette profusion s'explique par le fait qu'aucune approche n'est vraiment satisfaisante ni ne
permet de couvrir l'ensemble des besoins. En s'inspirant des techniques de l'analyse du domaine
et de la mthode SHLAERIMELLOR, nous divisons l'tape d'analyse en deux sous-tapes:
d'abord l'analyse du domaine dans laquelle on tablit le contexte du dveloppement (service,
application, architecture et implmentation) et les classes d'objets (physiques, rles, incidents,
interactions et spcifications) du domaine; ensuite l'analyse de l'application qui se concentre sur
une application particulire afin de transformer les modles du domaine (communication,
transition d'tat, information) en des modles de l'application. Ce qui constitue le chapitre m.

Dans le chapitre IV, nous sommes passs par une tape de conception de haut-niveau dans
laquelle nous avons construit une architecture de modles de simulation intgrs (composs de
trois modules: pr-simulation, simulation et post-simulation), ouverts (diviss en quatre
niveaux de modlisation: ressource, atelier, unit de production, G.P.A.O.) et flexibles (pour
l'intgration des objets dcisionnels), puis par une tape de conception de bas niveau:
conception des classes. Nous avons conceptualis une architecture ouverte et flexible d'objets
actifs et passifs. Les structures et mthodes de classes d'objets smantiques essentielles pour les
systmes de production (transactions, moyens de production et dcisions) ainsi que celles des
classes d'objets de rsolution (utilitaires/auxiliaires, mathmatiques, interface, application, etc.)
sont prsentes et conceptualises. Enfin, le modle d'objet actif est illustr travers le
comportement de deux classes d'objets smantiques de systmes de production: machine et
station.

Le chapitre V est consacr l'implmentation de modles de simulation concurrente objets.

En commenant par un rappel des concepts de la programmation concurrente: la notion de
processus et les cooprations entre les processus en terme informatique, nous avons tudi
trois langages ou outils bass sur la notion de processus lger: MODSIM: II, SIM: Plus Plus et
Meijin++, qui permettent d'implmenter les modles de simulation concurrente. Enfin, les
classes d'objets smantiques des systmes de production concernant surtout la partie physique
sont hirarchises et implmentes l'aide d'un outil de simulation Meijin++.
 215

II Contribution

Techniquement, l'approche objets est viable et concurrence dans toutes les tapes du cycle de
vie des logiciels, depuis l'analyse et la conception jusqu', la maintenance, les mthodes dites
classiques. Tous les utilisateurs actuels de l'approche objets s'accordent vanter la facilit de
modlisation qu'elle apporte et le temps gagn sur les charges de dveloppement et de
maintenance applicative: granularit fine, rutilisabilit maximale, encapsulation du
comportement, unit de communication. Tout serait faisable avec de la programmation
classique, mais avec un grand niveau de complexit.

Rutiliser plutt que refaire. Mais une librairie des classes d'objets reprsente une structure
hirarchique d'un domaine et non pas une boite outils remplie de choses disparates. Bien que
des classes d'objets standards existent (d'ailleurs c'est un critre trs important pour instaurer
un niveau de confiance suffisant dans l'industrie) dans la plupart des domaines [GAL 94],
l'offre d'une librairie des classes d'objets qui soit suffisamment gnrale et complte pour la
simulation des systmes manufacturiers n'est, notre connaissance, pas encore disponible (ou
plutt non assez crdible). Une bonne librairie des classes doit fournir un guide et une direction
pour la conception et le dveloppement du modle de simulation d'une application. C'est pour
cela que nous avons introduit une tape de l'analyse du domaine dans le dveloppement
objets. Le but de l'analyse est d'essayer d'aboutir un consensus sur le vocabulaire et la thorie
du domaine de la production. Un modle de simulation est constitu de quatre sous-domaines:
application, service, architecture et implmentation, dans lesquels cinq types d'objets
interagissent: physiques, rles, incidents, interactions et spcification. Ds qu'un utilisateur
dsire utiliser une des classes dans la librairie, il doit avoir accs l'ensemble des classes de la
librairie travers quatre modles d'objets: modle de communication, modle d'tat, modle
d'information et modle de processus. Chacun des objets fonctionnels de la librairie s'intgre
dans une perspective homogne et les composants interagissent de nombreuses manires.

La plupart des mthodes de conception objets permettent de dfinir des objets squentiels,
c'est--dire, des objets qui fournissent une encapsulation d'organisation (structure) et certains
services prts tre utiliss. Or la simulation concurrente est un modle dynamique: diffrents
objets peuvent excuter diverses activits en mme temps ou un objet peut excuter plusieurs
activits concurrentiellement. Nous avons introduit les concepts agents dans la conception des
classes d'objets. Le comportement des agents est dfini dans une mthode particulire
fonctionner par ses quatre types d'activits (mthodes): perception, cognition, dcision et
action. L'objectif de considrer un objet comme un agent est de dcrire comment l'objet doit se
comporter (e.x., volution des attributs d'objets: structurels, conjoncturels, instantans,
vnementiels, historiques et statistiques), mais non pas d'expliquer comment il fonctionne
(entres/sorties) dans le systme objets. Nous pouvons construire des modles objets
 216

distribus et volus avec ces agents (objets autonomes) qui rpondent bien la problmatique
pose dans l'introduction (modifiabilit des modles de systmes de production et flexibilit de
gestion de production).

La troisime contribution concerne l'implmentation de modles de la simulation concurrente.

L'intgration de la concurrence et de l'hritage semble tre une tche trs difficile. Le code des
synchronisations exprim un niveau de la hirarchie de classes ne peut prendre en compte les
mthodes ajoutes et les redfinitions qui apparaissent un niveau infrieur de cette hirarchie.
Afin de rsoudre ce conflit, les propositions existantes restreignent les objets actifs n'avoir
qu'une activit au plus en leur flot de contrle interne. La notion de thread est utilise pour
implmenter la squentialit de l'activit des objets concurrents qui s'excutent en quasi-
parallle dans un modle de communication inter-processus mmoire commune. Une
hirarchie des classes d'objets actifs et passifs pour la simulation concurrente des systmes de
production est propose et installe (ou en cours d'installation).

III Perspectives

Les propositions faites dans ce mmoire constituent un premier pas vers la simulation
concurrente objets pour les systmes manufacturiers. Un systme de production est compos
de trois sous-systmes: un sous-systme oprant, un sous-systme d'information et un sous-
systme dcisionnel. Nous avons construit des classes d'objets essentielles pour le sous-
systme oprant de la production en insistant sur la notion de processus avec l'esprit
d'ouverture pour intgrer des dcisions dans les modles de simulation. Mais les dcisions
modlises dans ce mmoire sont des dcisions locales reprsentes essentiellement par des
rgles de priorit; une extension des structures des classes dcisionnelles comprenant des
dcisions globales (rgles de management, par exemple) flexibles et ouvertes est tout fait
envisageable. Rellement, pour les technologies objets comme pour toute nouvelle technique,
c'est le premier pas qui cote le plus en investissement. Les concepts tels que les mthodes
virtuelles, les classes abstraites, les types gnriques ou les modles, la rsolution tardive sont
suffisant pour reprsenter et modliser les dcisions complexes dans la production; mais il faut
avoir une vision globale et pertinente de la gestion de production avant de les structurer en des
classes d'objets et hirarchiser ces classes dans une librairie comme nous l'avons fait avec les
classes d'objets physiques des systmes de production. Faute de connaissance sur la gestion de
production et de temps de dveloppement, nous n'avons pas pu nous investir plus dans cet
aspect. Une thse en cours dans l'quipe traite l'aspect de la structuration des classes d'objets
de gestion et de diagnostic de la production dans les modles de simulation concurrente objet
[OUZ 94].
 217

La complexit consiste, dans l'approche objets, d'une part dans l'identification et la

spcification d'objets, d'autre part dans l'unification des objets. Complexit est la somme de
diversit (multiplicit des objets) et complication (relations trop nombreuses entre les objets
pour tre apprhendes en mme temps par l'esprit humain). La dmarche de conception d'un
objet en diffrents niveaux: objet passif, objet actif (concurrent), objet autonome (agent,
contrle), objet dcideur, nous semble une voie prometteuse pour rduire la complexit du
systme objet. A cause de la difficult d'implmentation au sens informatique, les problmes
de l'intgration des objets dcideurs dans les modles de simulation ne sont pas bien rsolus
(ou on ne les a pas abords) dans ce travail. Les objets ont une dimension d'ordre sociologique.
Bien que l'objet est une faon de penser avant d'tre une technique, la question n'est pas de
savoir si nous allons vers l'objet, mais plutt comment appliquer ces techniques dans la
modlisation et la simulation des systmes de production tant au niveau de la conception qu'au
niveau de l'implmentation. Une intgration des concepts multi-agents issus de l'intelligence
artificielle distribue et des systmes multi-agents peut rsoudre des problmes d'intgration
des objets dcideurs dans les modles de la simulation concurrente objets des systmes de
production.

Enfin, une amlioration des hirarchies des classes d'objets smantiques (attributs et mthodes)
pour la performance et la comprhension, et l'enrichissement des classes d'objets dcisionnels
pour que la librairie soit plus complte, s'inscrivant dans le cadre d'une dmarche de
modlisation des systmes industriels de l'quipe "Etude et Modlisation des Systmes
Industriels" du Centre SIMADE pour aboutir un systme d'aide la dcision ouvert et
flexible, constituent les principales activits courantes autour d'un produit en dveloppement
appel SIM'3.
 REFERENCES

[ADAMA 84] ADAMA, F.B. "Contribution un Analyseur Informatique GRAI". Thse

Doct.: Universit de Bordeaux 1, 1984. 149p.
[AKERBAEK 93] AKERBAEK, T. "C++, Coroutine, and Simulation". The C User Journal,
1993, No. 3, p. 74-86.
[AMAR et al. 90] AMAR, S., CASTELAIN, E. et GENTINA, J.C. "Modlisation des Moyens
de Production par Langages Orients Objet en vue de la Conception de la Commande
d'un Systme de Production Flexible". Colloque International sur Productique &
Intgrations, Bordeaux, juin 12-14 1990. p.325-334.
[AMERICA 89] AMERICA P. "Issues in the Design of a Parallel Object-Oriented Language".
FormalAspectofComputing, 1989, Vol. 1, No.3, p. 366-411.
[AMICE 89] AMICE CIMOSA "Open System Architecture for CIM''. Berlin:
Springer_Verlag, 1989. 212p.
[ANDREWS et al. 83] ANDREWS, G.R. et SCHNEIDER, F.B. "Concepts and Notations for
Concurennt Programming". Computing Surveys, 1983, Vol. 15, No. 1, p. 3-43.
[AYEL 91] AYEL, J. "CIMES, Un Systme d'Intelligence Artificielle Distribue pour la
Supervision en Continu des Activits de Gestion de Production". Thse Doct.: Universit
de Savoie, 1991. 228p.
[BAILLY et al. 87] BAILLY, C., CHALLINE, J.F., FERRI, H.C., GLOESS, P.Y. et
MARCHESIN, B. "Les Langages Orients-Objets". Toulouse: CEPADUES-Editions,
1987. 223p.
[BALCI 90] BALCI, 0., "Guidings for Successful Simulation Studies". Proceeding of the
1990 Simulation Conference, New Orleans, Louisiana, decembre 9-12, 1990. p.25-32.
[BARNES 88] BARNES, J. "Programmer en ADA". Paris: InterEditions, 1988. 495p.
[BARAKAT 91] BARAKAT, O. "Contribution la Modlisation et la Simulation
Orientes-Objets des Systmes Flexibles de Production". Thse Doct.: Universit de
Franche-Compt, 1991. 156p.
[BARBIER] BARBIER, F. "Une Approche Objet Ddie la Fonction Production d'une
Entreprise Manufacturire: Application la Gestion de Production". Thse Doct.:
Universit de Savoie, 1989. 208p.
[BEL et al. 85] BEL, G. et DUBOIS, D. "Modlisation et Simulation de Systmes
Automatiss de Production". Revue APII, 1985, vol. 19, No. 3, p.3-43.
[BEL et al. 88] BEL, G., BENSANA, E. et DUBOIS, D. "Construction d'Ordonnancements
Prvisionnels: un Compromis entre Approches Classiques et Systmes Experts". 2me
Confrence Internationale Systmes de Production, Paris, avril 6-10, 1988. p. 709-726.
 220

[BEL 88] BEL, G. "Ordonnancement et Intelligence Artificielle". Colloque International

Productique et Robotique: les Apports de l'Intelligence Artificielle, Bordeaux, mars 15-
17, 1988. p.4-11.
[BEL et al. 90] BEL, G. et CAVAILLE, J.B. "Intgration de la Simulation dans la Conception
de Systmes de Production: Avantages et Dangers de l'Approche par Langages Objet".
Colloque International sur Productique & Intgrations, Bordeaux, juin 12-14 1990.
p.597-603.
[BEN-AR! 86] BEN-ARI, M. "Processus Concurrents: Introduction la Programmation
Parallle". Paris: Masson, 1986. 174p.
[BELANGER 90a] BELANGER, R "MODSIM II Reference Manuaf'. CACI Products
Company, La Jolla, CA, 1990. 336p.
[BELANGER 90b] BELANGER, R "MODSIM TI - A Modular, Object-Oriented Language".
1990 Winter Simulation Conference Proceeding, New Orleans, USA, decembre 9-12.
1990. p.118-122.
[BENASSY 90] BENASSY, J. "La Gestion de Production". Paris: Hermes, 1990, 251p.
[BENSLEY et al. 92] BENSLEY, E.H., GIDDING, U.T., LEIVENT, J.I. et WATRO, RJ. "A
Performance-Based Comparason of Object-Oriented Simulation Tools." The MITRE
Cooperation, Bedford, MA, 1992. 86p. Rapport Intem.
[BERANGER 87] BERANGER, P. "Les Nouvelles Rgles de la Production. Vers l'Excellence
Industrielle". Paris: Dunod Entreprise, 1987. 212p.
[BERSHAD et al. 88] BERSHAD, B.N., LAZOWSKA, E.D. et LEVY, H.M. "PRESTO: a
System for Object-Oriented Parallel Programming". Software-Pratice and Experience,
1988, Vol. 18, No. 8, p.713-732.
[BELT et al. 86] BELT, B. et BRUN, F. "La Mthode MRP-II: Grer 1'/nteiface Commercial
et Production". Paris: Cabinet BILL BELT S.A., 1986.194p.
[BINDING 85] BINDING, C. "Cheap Concurrency in C". SIGPLAN Notices, 1985, Vol. 20,
No. 9, p.21-26.
[BIRTWISTLE et al. 73] BIRTWISTLE, G., DAHLO, 0., MYHRHAUG, B. et NYGAARD,
K. "SIMULA Begin". New-York: Petrocelli Charter, 1973. 125p.
[BLANCHARD 79] BLANCHARD, M. "Comprendre, Maitriser et Appliquer le GRAFCET'.
Toulouse: Cepadus dition, 1979. 194p.
[BORGEN et al. 89] BORGEN, E. et STANDHAGAN, J. "An Object-Oriented Tool Based
on Discrete Event Simulation for Analysis and Design of Manufacturing Systems".
Optimization of Manufacturing Systems Design, Edit par D.L. SHUNK, Amsterdam:
North-Holland, 1989. p.195-220.
[BORLAND 93] "ObjectWindows pour C++: Guide de l'Utilisateur". Velizy Villacoublay:
Borland Internatonal, Inc., 1993. 449p.
 221

[BOOCH 92] BOOCH, G. "Conception Oriente-Objets et Applications". France: Addison-

Wesley, 1992. 588p.
[BOOCH 93] BOOCH, G. "Dveloppement Logiciel Orient Objets: La Mthode Bouch
Processus et Pragmatique". Gnie Logiciel & Systmes Experts, 1993, No. 30, p.4-13.
[BOUKACHOUR et al. 93] BOUKACHOUR, J., GALINHO, T. et PECUCHET, J.P. "Etude
Comparative entre Simulation et Placement en Ordonnancement". Revue API!, 1993,
Vol. 27, No. 5, p.561-585.
[BOURDICHON 93] BOURDICHON, P. "La Modlisation en Entreprise CIM-OSA et
Ingnierie Simultane: L'Ingnierie Simultane dans le Cycle de Vie des Projets".
Colloque Universit d'Et du Ple Productique Rhne-Alpes, sept. 13-17, 1993.
Aussois, France, 38p.
[BRAMS 83] BRAMS, G.W. "Rseaux de Ptri: Thorie et Pratiques". Paris: Masson, 1983.
Tome 1, 184p.
[BRAESCH 89] BRAESCH, C. "Approche de Modlisation du Systme de Production d'une
Entreprise Manufacturire". Thse Doct.: Universit de Franche-Comt, 1989. 202p.
[BRODIER 88] BRODIER P.L. "Une Autre Approche de la Gestion: la Valeur Ajoute
Directe". Paris: AFNOR Gestion", 1988. 165p.
[BROWN 78] BROWN, M.R. "Implementation and Analysis ofBinomial Queue Algorithms".
SIAM J. Comput., 1978, Vol. 7, No. 3, p.298-319.
[BROWN 88] BROWN, R. "Calendar Queues: A Fast 0(1) Priority Queue Implementation for
the Simulation Event Set Problem". Commun. of ACM, 1988, Vol. 31 No. 10, p.1220-
1227.
[BUHR et al. 90] BUHR, P.A. et STROOBOSSCHER, R.A. "The J!System: Providing Light-
Weight Concurrency on Shared-Memory Multiprocessor Computers Running UNIX".
Software-Pratice and Experience, 1990, Vol. 20, No. 9, p.929-964.
[BUHR et al. 92] BUHR, P.A., DITCHFIELD, G., STROOBOSSCHER, RA. et
YOUNGER, B.M. "J.LC++: Concurrency in the Object-Oriented Language C++".
Software-Pratice and Experience, 1992, Vol. 22, No. 2, p.137-172.
[CANALS 86] CANALS, D. "Ordonnancement d'Atelier par Simulation: Etude des Rgles de
Priorit et Aide au Lancement". Thse Doct. lng.: Ecole Nationale Suprieure de
l'Aronautique et de l'Espace de Toulouse, 1986. 326p.
[CARLIER et al. 88] CARLIER, J. et CHRETIENNE, P. "Les Problmes d'Ordonnance-
ments: Modlisation, Complexit, Algorithmes". Paris: Masson, 1988. 326p.
[CARO:MEL 93] CARO:MEL, D. "Toward a Method of Object-Oriented Concurrent
Programming". Commun. of the ACM, 1993, Vol. 36, No. 9, p.90-102.
[CASTELLANI 93] CASTELLANI, X. "Mthodologie Gnrale d'Analyse et de Conception
des Systmes d'Objets: l'Ingnierie des Besoins". Paris: Masson, 1993. 402p.
 222

[CAVAILLE et al. 87] CAVAILLE, J.B. et PROTH, J.M. " SIPRODIS: Pratique de la
Simulation en Production Discontinue". Nanterre: Colloques & Conseil, 1987. 333p.
[CHIT.,OUP-BEKAEPT 91] CHIT.,OUP-BEKAEPT, M.H. "Utilisation de la Notion d'Objets
avec Contraintes pour la Modlisation et la Simulation des Systmes de Production".
Thse de l'Universit de Lille Flandres Artois, 1991. 154p.
[COAD et al. 90] COAD, P. et YOURDON, E. "Object-Oriented Analysis". Englewood
Cliffs, N.J.:Prentice-Hall, 1990. 232p.
[COAD et al. 91] COAD, P. et YOURDON, E. "Conception Oriente-Objets". Englewood
Cliffs, N.J.:Prentice-Hall, 1991. 195p.
[COMMI 90] COMMISSARIAT GENERAL DU PLAN "L'Usine du Futur: l'Entreprise
Communicante et Intgre". Paris: la documentation franaise, 1990. 218p.
[COMMUN! 90] COMMUN!. OF ACM "Object-Oriented Design and Programming".
Communi. ofACM (Numro Spcial), 1990, Vol. 33, No. 9, p.35-146.
[COMMUN! 92] COMMUN!. OF ACM "Analysis and Modeling in Software Development".
Communi. ofACM (Numro Spcial), 1992, Vol. 35, No. 9, p.35-172.
[COMMUN! 93] COMMUN!. OF ACM "Concurrent Object-Oriented Programming".
Communi. ofACM (Numro Spcial), 1993, Vol. 36, No. 9, p.34-137.
[CRIBBS et al. 92] CRIBBS, J., MOON, S. et ROE C. "An Evaluation of Object-Oriented
Analysis and Design Methodologies". Raleigh {NC): SIGS Books-Alcatel Network
Systems, Inc. juin 29, 1992. 71p.
[CUGY 83] CUGY, A. "Organisation de l'Entreprise Moyenne. Initiation et Pratique". Paris:
Les ditions d'Organisation, 1983. 306p.
[DAVID 93] DAVID P.Y. "Bluffez Votre Entourage avec Vos Connaissance Temps-Rel".
Dossier Temps-Rel, Bulletin de la Liaison de TRIBUNIX, 1993, Vol. 9, No. 47, p.2-5.
[DE VETTOR 91] DE VETTOR, P. "Une architecture Logicielle Objets pour la
Conception d'Applications Industrielles Complexes" Thse Doct.: Universit de France-
Comt, 1991. 248p.
[DORSEUIL et al. 91] DORSEUIL, A. et PILLOT, P. "Le temps Rel en Milieu Industriel:
Concepts, Environnements, Multitches". Paris: Dunod, 1991. 296p.
[DOUMEING 91] DOUMEINGTS, G. "Mthodes pour Concevoir et Spcifier les Systmes
de Production". Colloque International on CIM: Integration Aspects, Bordeaux, France,
juin 12-14, 1990. p.89-103.
[DOUMEING et al. 91] DOUMEINGTS, G. et VALLESPIR, B. "Techniques de
Modlisation pour la Productique". Proceedings of the 23rd CIRP International
Seminar onManufacturing systems, Tome 1, Nancy, France, juin 6-7, 1991. 10p.
[DUFFAU et al. 84] DUFFAU, B. et BLOCHE, E, "La Simulation des Units de Production".
Intelligence Artificielle et Productique, 1984, Vol. 1, No. 1, p.19-24.
 223

[ERSCHLER et al. 85] ERSCHLER, J., FONTAN, G. et :MERCE, C. "Consistency of the

Dissaggregation Process in Hierarchical Planning". Operations. Researches, 1985, Vol
34, No. 4, p.464-469.
[EVAN 88] EVAN, J.B. "Structures of Discrete Event Simulation: An Introduction to the
Engagement Strategy". London: Ellis Horwood Limited, 1988. 279p.
[FERBER et al. 88] FERBER, J. et GHALLAB, M. "Problmatiques des Univers Multi-agents
Intelligents". Acte des 2me Journes du PRC GRECO Intelligence Artificielle,
Toulouse, France, 1988. Toulouse: TEKNEA, p.295-320.
[FRAMLING et al. 93a] FRAMLING, K. et HAMMARSTROM, L. "Object-Oriented Tool
for Modeling, Simulation and Production Planning in Petrochemical Industries". Actes de
la Reprsentations par Objets, Grande Motte, juin 17-18, 1993. p.169-180.
[FRAMLING et al. 93b] FRAMLING K. et HAMMARSTROM L. "A Distributed Heuristic
Expert System for Simulation and Production Planning in Petrochimical Industries".
Proceeding of the Workshop ''Knowledge-Based Production Planning, Scheduling and
Control" ofiJCAI'93, Chambery, France, aot 28- sept. 3, 1993. p.149-158.
[FRITSCHY 90] FRISCHY, D. "La Simulation Oriente Objet: Nouvelles Exigences en
Matire de Simulation Informatique et Temporelle des Flux d'un Systme Flexible et
Discontinu de Production". Colloque International sur Productique & Intgrations,
Bordeaux, juin 12-14 1990. p.587-598.
[GACHES et al. 93] GACHES, R., QUERENET, B. et VERNADAT, F. "CIMOSA: une
Architecture pour l'Intgration dans les Entreprises Manufactutires". Acte de Universit
d'Et du Pole Productique Rhone-Alpes, Aussois, France, sept. 13-17, 1993. 15p.
[GALISSON 94] GALISSON, Y. "NORMES: Sans Standarts, Point de Salut". 01
Informatique, Dossiers Spcials sur les Technologies Objets, 1994, No. 1298, p. 40.
[GEHANI et al. 88] GEHANI, N.H. et ROO:ME, W.D. "Concurrent C++: Concurrent
Programming With Class(es)". Sojtware-Pratice and Experience, 1988, Vol. 18, No. 12,
p.ll57-1177.
[GERSHWIN 89] GERSHWIN, S.B. "Hierarchical Flow Control: A Franiework for
Scheduling and Planning Discrete Events in Manufacturing Systems". Proceedings of the
IEEE, 1989, vol77, No. 1, p.195-209.
[GIARD 88] GIARD, V. "Gestion de Production". Paris: Economica, 1988. 1068p.
[GOLDBERG et al. 83] GOLDBERG, A. et ROBSON, D. "Smalltalk-80: the Language and
its Implementation". Massachusetts: Addison-Wesley, 1983. 715p.
[GOLDRATT et al. 86] GOLDRATT, E.M. et COX, J. "Le But: L'Excellence en Production".
Paris: Afnor Gestion, 1986. 238p.
[GO:MMA 84] GOMMA, H. "A Software Design Method for Real-Time Systems". Commun.
ofACM, 1984, Vol. 27 No. 9, p.938-949.
 224

[GONNET 76] GONNET, G.H. "Heaps Applied to Event Driven Mecanisms'i. Commun. of
ACM, 1976, Vol. 19 No. 7, p.417-418.
[GOVINDAR 90 et al.] GOVINDAR, T., MCGINNIS, L.F., PLATZMAN, L.K. et
MCGINISS, L.F. "Manufacturing Simulation Using Objects". Proceeding of the 1990
Summer Computer Simulation Conference, juillet 16-18, Calgary, Canada, 1990. p.219-
224.
[GUll..LARD 92] GUILLARD, S. ''Modlisation et Stratgies Auto-Organisatrices pour les
Ateliers de Production Modemes". Thse lng.: Institut National des Sciences Appliques
de Lyon, 1992. 235p.
[GUO et al. 90] GUO, D., NORRIE, D.H. et FAUVEL, O.R. "Object-Oriented Flexible
Manufacturing System Simulation". Proceeding of the 1990 Summer Computer
Simulation Conference, juillet 16-18, Calgary, Canada, 1990. p.225-230.
[HAMICID et al. 88] HAMICID, S. et KEIFFER, J.P. "L'implmentation d'une Gestion de
Production Informatise: du Projet la Mise en Route, les Progiciels et leurs
installations, Conseils d'Organisation, deux Exemples Dtaills et Comments". Paris:
Editions du Moniteur, 1988, 248p.
[HENDERSON et al. 91] HENDERSON-SHELLERS, B. et EDWARDS, J.M. "Object-
Oriented Systems Life Cycle". Commun. ofACM, 1991, Vol. 33, No. 9, p.142-169.
[HATLEY et al. 91] HATLEY, D.J. et PIRBHAI, I.A "Stratgies de Spcification des
Systmes Temps Ref'. Paris: Masson, 1991. 368p.
[HAX et al. 85] HAX, AA et MEAL, H.C. "Hierarchical Integration of Production Planning
and Scheduling". Studies in Management Sciences, 1975, Vol. I, 1975. p.53-69.
[IDLL 93] HILL, D.R.C. "Analyse Oriente Objets & Modlisation par Simulation". Paris:
Addison-Wesley, 1993. 362p.
[HOLLINGER 87] HOLLINGER, D. "Les Langages Orients-Objets en Spcification et
Simulation des Systmes Productiques". Joumes S1RRODIS 'Pratique de la Simulation
en Production Discontinue, Paris, juin 2-3, 1987, p.79-91.
[HOOGEBOOM et al. 93] HOOGEBOOM, B. et HALANG, W.A "The Concept of Time in
Software Engineering for Real Time Systems". 3rd International Conference on
Software Engineering for Real Time Systems, IEEE Conference Publication No. 344,
1993. p.156-163.
[IGL 89] IGL Technology "SADT: un Langage pour Communiquer". Paris: Eyrolles, 1989.
326p.
[ISIDKAWA et al. 92] ISIDKAWA, Y., TOKUDA, H. et MERCER, C.W. "An Object-
Oriented Real-Time Programming Language". IEEE Computer, Vol. 25, No. 10, oct.
1992. p. 66-73.
[JAIN et al. 90] JAIN, J., BARBER, K. et OSTERFELD, D. "Expert Simulation for On-Line
Scheduling". Commun. ofACM, 1990, Vol. 33, No. 10, p.54-60.
 225

[JAULENT 92] JAULENT, P. "Gnie Logiciel: les Mthodes". Paris: Armand 'Colin diteur,
1992. 294p.
[JAVEL 93] JAVEL G. "L'Organisation et la Gestion de Production". Paris: Masson, 1993.
328p.
[JEFFERSON 83] JEFFERSON, D. "Virtual Time". Proceeding International Conference on
Parai/el Processing, Silver Spring, Md., 1983. p.384-394.
[JULLIEN 91] JULLIEN, B. "Simulation des Systmes de Production". Ecole Nationale
Suprieure des Mines de St-Etienne, 1991. 172p. Support de Cours.
[JULLIEN 92] JULLIEN, B. "Un modle Conceptuel pour la Simulation Oriente Processus".
2me Journe Confrence FRA.NCOSIM, Villeurbanne, juin 18 1992. 15p.
[KELLERT 92] ILLERT, P. "Dfinition et Mise en Oeuvre d'une Mthodologie Oriente
Objets pour la Modlisation des Systmes de Production". Congrs Inforsid'92,
Clmont-Ferrand, mai 19-22, 1992. p.415-436.
[KRUEGER 92] KRUEGER, C. W. "Software Reuse". ACM Computing Surveys, 1992, Vol
25, No. 2, p.131-183.
[LABRECHE 90] LABRECHE, P. "lnteractors: a Real-Time Executive with Multiparty
Interactions in C++". SIGPLAN Notices, 1990, Vol. 25, No. 4, p.20-32.
[LEROUDIER 80] LEROUDIER, J. "La Simulation Evnements Discrets". Paris: Hommes
et Techniques, 1980.101p.
[LEVINE et al. 89] LEVINE, P. et POMEROL, J.C. "Systmes Interactifs d'Aide la
Dcision et Systmes Experts". Paris: Hermes, 1989. 335p.
[LISSANDRE 90] LISSANDRE, M. "Matriser SADT'. Paris: Armand Colin Editions, 1990.
219p.
[LOMOW et al. 90] LOMOW, G. et BAEZNER, O. "A Tutorial Introduction to Object-
Oriented Simulation and SIM++". Proceeding of the 1990 Summer Computer
Simulation Conference, juillet 16-18, Calgary, Canada, 1990. p.146-148.
[MAIRE 91] MAIRE, J.L. "OLYMPIOS: un Modle de Conception du Systme d'Information
d'une Entreprise Manufacturire-Application l'Audit". Thse Doct.: Uriiversit de
Savoie, 1991. 149p.
[MASINI et al. 89] MASINI, G., NAPOLI, A. COLNET, D. LEONARD, D. et TOMBRE, K.
"Les langages Objets: Langages de classes, langages de frames, langages d'acteurs".
Paris: InterEditions, 1989. 583p.
[MATHON 92] MATHON, A. "Appel d'Offre du Projet NADEGE: Renseignements
Scientifiques". Dpt. Stratgie du Dveloppment de l'Ecole des Mines de St-Etinne,
France, juin 1992. 22p.
[MCGREGOR et al. 92] MCGREGOR, J.D. et SYIS, D.A. "Object-Oriented Software
Development: Engineering Software for Reuse". New-York: Van Nostrand Reinhold,
1992. 352p.
 226

[MCLAREN et al. 88] MCLAREN, B.M., NEUSS, P.M. et GROOTE, O.D. "The Integrated
Modeling Package: An Object Oriented Module for Manufacturing Simulation". Proc. of
the European Simulation Multiconference, Nice, juin 1-3, 1988. p.231-236.
[MCPHERSON et al. 86] MCPHERSON, R.F. et WIDTE, K.P. "A Management Control
Approach to the Manufacturing Planning and Scheduling Problem". Proceedings of a
Symposium Held at the Nation Bureau of Standards on Real-Time Optimisation in
AutomatedManufacturing Faci/ities, Gaithersburg, MD, jan. 1986. p.145-165.
[MENGA et al. 89] MENGA, G., MORISIO, M. et LO RUSSO, G. "A Framework for Object
Oriented Design and Prototyping of Manufacturing Systems". Politecnico di Torino,
Italy, 1989. 26p. Rapport du Dpt. Automatique et Informatique.
[MELESE 79] MELESE, J. "Approches Systmiques des Organisation: vers l'Entreprise
Complexit Humaine". Paris: Hommes et Techniques, 1979. 158p.
[MEYER 88] MEYER, B. "Object-Oriented Software Construction". Englewood Cliffs, N.J.:
Prentice-Hall, 1988. 534p.
[MEYER 93] MERYER, B. "Systematic Concurrent Object-Oriented Programming".
Commun. ofACM, 1993, Vol. 36, No. 9, p.56-80.
[MILLE 93] MILLE, Y. "Juste--Temps et Productivit: une Dmystification Indispensable",
Revue Franaise de Gestion Industrielle, 1993, Vol. 12, No.1, p.53-70.
[MIRY et al. 91] MIRY, S., MATHON, A. et VINCENT, L. "Evaluation Economique d'un
Systme de Production par Simulation de Politiques de Gestion en Prsence d'Alas".
3me Congrs International Gnie Industriel, Tours, mars 20-22, 1991. p.635-645.
[MIRY et al. 92] MIRY, S., MATHON, A. et GIRARD, M-A "SIM'I: un Outil Pdagogique
en Gestion de Production". Congrs Inforsid'92, Clmont-Ferrand, mai 19-22, 1992.
p.553-562.
[MIRY 93] MIRY, S. "Contribution la Modlisation Globale d'Entreprise: Dcision et
Performances dans les Systmes de Production". Thse Doct. lng.: Institut National des
Sciences Appliques de Lyon, 1993. 306p.
[MIZE et al. 89] MIZE, J.H., BEAUMARIAGE, T. et KARACAL, C. "Systems Modeling
Using Object-Oriented Programming". Proc. of the 1989 International Industrial
Engineering Conference., Norcross, GA, USA, avri11989. p.13-18.
[MOIGNE 90] LE MOIGNE, J.L. "La Modlisation des Systmes Complexes". Paris:
EditionsDunod, 1990.178p.
[MONARCHI et al. 92] MONARCHI, D. E. and PUHR, G.I. "A Research Typology for
Object-Oriented Analysis and Design". Commun. ofACM, 1992, Vol35, No. 9, p.35-47.
[MORIN et al. 93] MORIN, P., GERBEAUD, M. et LAJOIE, M. "Ingnierie Simultane: un
Nouveau Cercle l'AFITEP". La Cible, 1993, Vol. 46, p.18-19.
[MULINS 93] MULINS, H. "Les Nouvelles Organisations Productives". Revue
Franaice de Gestion Industrielle, 1993, Vol. 12, No.3, p.S-30.
 227

[NELSON 91] NELSON, M.L. "Concurrency & Object-Oriented Programming". ACM

SIGPLAN Notices, 1991, Vol. 26, No. 10, p.63-72.
[NGUYEN et al. 92] NGUYEN, G.T. et RIEU, D. "Multiple Object Representations". Proc.
of the ACM Computer Science Conference, Kansas. City, mars 1992. p197-204.
[NGUYEN 93] NGUYEN, G.T. "SHOOD: Plate-forme pour la Conception Assiste".
Ingnierie des Systmes d'Information, 1993, Vol. 1, No. 3, p.393-414.
[NICOLAS 91] NICOLAS, P. "Meijin++, Reference Manuaf'. Network lntegrated Services,
INC, Santa Ana, CA. 1991.800p.
[NICOLAS 93] NICOLAS, P. "Object-Oriented Simulation Using C++". Bor/and
International Conference, San Diego, CA, USA, mai 1993. 2lp.
[O'GRADY 86] O'GRADY, P.J. "A Hierarchy of Intelligent Scheduling and Control for
Manufacturing Systems". Proceedings of a Symposium Held at the Nation Bureau of
Standards on Real-Time Optimisation in Automated Manufacturing Facilities,
Gaithersburg, MD, jan. 1986. p.IS-30.
[OLUMOLADE et al. 90] OLUMOLADE, M., NORRIE, D.H. et FAUVEL, O.R. "Object-
Oriented Integration and Simulation ofManufacturing". Proceeding of the 1990 Summer
Computer Simulation Conference, juillet 16-18, Calgary, Canada, 1990. p.249-252.
[ORLICKY 75] ORLICKY, J. "Material Requirements Planning: the New Way of Life in
ProductionandinventoryManagement". New-York: Mc Graw-Hill, 1975. 292p.
[OUZOUT et al. 94] OUZOUT, Y., YE, X.J., VINCENT L. et JULLIEN B. "Designing and
Implementing a Process-Oriented Simulation Environment". International Conference
on Concurrent Engineering and Electronic Design Automation, Bournemouth, U.K.,
avril 7-8,1994. p469-474.
[PANWALKER et al. 77] PANWALKER, S.S. et ISKANDER, W. "A survey ofScheduling
Rules". Operation Research, 1977, Vol. 9, No. 1, p.45- 61.
[PEGDEN et al. 90] PEGDEN, C.D., SHANNON, R.E. et SADOWSKI, R.P. "Introduction
toSimulation UsingSIMAN''. New-York: McGraw-Hill, Inc, 1990. 615p.
[PIERREVAL 90] PIERREVAL, H. "Les Mthodes d'Analyse et de Conception iles Systmes
de Production". Paris: Editions Herms, 1990. 62p.
[POPKEN 92] POPKEN, D.A. "An Object-Oriented Simulation Environment for Airbase
Logistics". Simulation, 1992, Vol. 59, No. 11, p.328-338.
[PORTMANN 87] PORTMANN, M.C. "Mthodes de Dcomposition Spatiale et Temporelle
en Ordonnancement de la Production". Thse d'Etat: Univ. de Nancy I, 1987. 315p.
[POUNTAIN 94] POUNTAIN, D. "The Chorus Microkemel". Byte Magasine, jan. 1994.
p.Bl-136.
[PRIETO 90] PRIETO-DIAZ, R. "Damain Analysis: an Introduction". ACM SIGSOFT
Software Enginneering Notes, 1990, VoliS, No. 2, p.47-54.
 228

[PRITSKER 86] PRITSKER, A.A. "Introduction to Simulation and SLAM If'. USA: Systems
Publishing Corporation, 1986. 839p.
[QUANG 89] QUANG, P.T. "MERISE/YOURDON". Revue Gnie Logiciel, No. 15, 1989.
p.22-39.
[RECHENMANN 88] RECHENMANN, F. "Shirka: un Systme de Gestion de Bases de
Connaissances: Manuel de Rfrence". Ecole Nationale Suprieure de l'Information et
des Mathmatiques Appliqus de Grenoble, juin 1988. 240p.
[RIEU et al. 91] RIEU, D. et CULET, A. "Classification et Reprsentation d'Objets". Congrs
INFORSID'91, Paris, France, juin 4-7, 1991. p.85-107.
[ROCHELD 93] ROCHELD, A. et BOUZEGHOUB, M. " From Merise to OOM". Ingnierie
des Systmes d'Information. 1993, Vol. 1, No. 2, p.151-176.
[RODDE 90] RODDE, G. "Les Systmes de Production: modlisation et performances".
Paris: Henns, 1990. 333p.
[ROLLAND] ROLLAND, C. "Indroduction la Conception des Systmes d'Information et
Panorama des Mthodes Disponibles". Genie Logiciel, 1986, No 4, p.6-11.
[ROSE 92] ROSE, O. "SIM Plus Plus, User Manual". University of Karlsruhe, Germany, juin
1992. 55p.
[ROY 70] ROY, B. "Algbre Moderne et Thorie des Graphes". Tome 2, Paris: Dunod, 1970.
759p.
[RUMBAUGH et al. 91] RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY, F. et
LORENSEN, W. "Object-Oriented Modeling and Designing". Englewood Cliffs, N.J.:
Prentice Hall, 1991. 354p.
[SCHERER 90] SCHERER, M. "Combat d'Ides Autour de la GPAO". revue Industries
Techniques, 1991, No. 3, p.46-47.
[SCHIPER 86] SCHIPER, A. "Programmation Concu"ente". Laussane: Presses
Polytechniques Romandes, 1986. 295p.
[Slll-AER et al. 92] SID.-AER, S. et MELLOR, S. "Object LifeCycles: Modeling the World in
States". Englewood Cliffs, N.J.: Prentice-Hall, 1992. 251p.
[SHOPIRO 87] SHOPIRO, J.E. "Extending the C++ Task System for Real-Time Control".
Proceeding and Additional Papers C++ Workshop, Santa Fe, NM, novembre 9-10
1987. p.77-94.
[SNYDER 93] SNYDER, A. "The essence ofObject: Concepts and Terms". IEEE Software,
jan. 1993. p.31-42.
[STROUSTRUP et al. 87] STROUSTRUP, B. et SHOPIRO, J.E. "A Set of C++ Classes for
Co-routine Style Programming". Proceeding and Additional Papers C++ Workshop,
Santa Fe, NM, novembre 9-10, 1987. p.417-439.
[TARDIEU 89] TARDIEU, H. "De Merise Metratech". Genie Logiciel, 1989, No. 15, p.40-
52.
 229

[TERSINE 88] TERSINE, R.J. "Princip/es of Inventory and Materials Management". New-
York: Elsevier Science Publishing Co., Inc, 1988. 553p.
[THORIN 90] THORIN, M. "Paralllisme: Gnie Logiciel Temps Rel". Paris: Dunod, 1990.
138p.
[THOMAS 92] THOMAS, L. "Etude Compare des Mcanismes de Synchronisation et de
Communication dans les lAngages Objets pour le Paralllisme". Thse Doct.:
Universit de Nancy I, 1992. 244p.
[TRACZ 92] TRACZ, W. "Domain Analysis Working Group Report - First International
Workshop on Software Reusability". ACM SIGSOFT Software Enginneering Notes,
1992, Vol17, No. 3, p.27-34.
[TSICHRITZIS 88] TSICHRITZIS, D. "Active Object Environments". Centre Universitaire
d'Informatique; Universit de Genve, Genve Switzerland, 1988. 236p.
[VARHOL 94] V ARHOL. P.D. "Small Kernels Hit It Big", Byte Magasine, jan. 1994. p. 119-
128.
[VINCENT et al. 92] VINCENT, L., MIRY, S. et DIRARD M-A. "SIM'1: une Pdagogie de
l'Intgration Productique". 1er Colloque Productique et Formation, Marseille, oct. 27-
28, 1992. p.145-150.
[VUILLEMIN 78] VUILLEMIN, J. "A Data Structure for Manipulation Priority Queues".
Commun. ofACM, 1978, Vol. 21, No. 4, p.309-315.
[XIE 89] XIE, X.L. "Contrle Hirarchique d'un Systme de Production Soumis
Pertubations", Thse Doct. Universit de Nancy I, 1989. 187p.
[WALDNER 90] W ALDNER, J.B. "Les Nouvelles Perspectives de la Production". Paris:
Dunod, 1990.165p.
[WALAS et al. 93] WALAS, M. et HUGUES, A.M. "Synthse et Classification de Langages
Parallles". Gnie Logiciel, 1993, No. 32, p.6-22.
[WAYNER 94] WAYNER, P. "Objects on theMarch". Byte Magasine, jan. 1994. p.139-150.
[WILLIAMS 90] WILLIAMS, S.A. "Programming Models for Para/le/ Systems". Chichester:
WILEY, 1990. 170p.
[WRITE et al. 88] WRITE, T. et GRZYBOWSKI, R. "Object Based Simulation: Foundations
and Implementation in Modula-2". Proc. of the European Simulation Multiconference,
Nice, juin 1-3, 1988. p.193-198.
[WYATT et al. 92] WYATT, B.B., KAVI, K. et HUFNAGEL, S "Parallelism in Object-
Oriented Languages: a Survey". IEEE Software, 1992, No. 11, p.56-65.
[YE 90] YE, X.J. "Automatisation de la Production: gamme d'usinage et ordonnancement."
Mmoire de DEA: Institut National des Sciences Appliques de Lyon, 1990. 92p.
[YE et al. 92a] YE, X.J., JULLIEN, B. et MATHON, A. "Scheduling by Object-Oriented
Simulation". Proc. of 3rd International Conference on Data and K.nowledge Systems for
ManufacturingandEngineering, Lyon, France, mars 17-20, 1992. p.llS-127.
 230

[YB et al. 92b] YE, X.J. et MATHON, A. "Manufacturing Management System Simulation:
an Object-Oriented Approach". Proceeding of 2nd Beijing International Conference on
System Simulation and Scienti.fic Computing, Pkin, octobre 20-23, 1992. p.30-34.
[YE 93] YE, X.J. "Une Plate-Forme pour la Simulation Oriente-Objets: Expriences et
Exigences". Expos dans le Groupe "Objet" du Ple Productique~ Grenoble, mars 21,
1993. 33p.
[YE et al. 93] YE, X.J., OUZROUT, Y. et MATHON, A. "Conception d'une Plateforme de
Simulation de Systme de Production par les Objets". Proceeding of Industrial Systems
Engineering, Marseille, France, decembre 15-17, 1993. p.189-196.
[YE et al. 94a] YE, X.J., JULLIEN, B. et VINCENT, L. "Concurrent Object-Oriented
Simulation for Manufacturing Applications". Proceeding of Western Multiconference,
Tempe, Arizona, U.S.A., jan. 24-27, 1994. p.3-8.
[YB et al. 94b] YE, X.J., MIRY, S., MATHON, A. et VINCENT, L. "Modlisation et
Simulation des Systmes de Production par les Objets". 3rd Maghrebian Conference on
Software EngineeringandArti.ficial Intelligence, Rabat, Maroc, avrilll-14, 1994.
[YE et al. 94c] YE, X.J., et FAVREL, J. "Production Flow Simulation". 4th International
Coriference on Data and Knowledge Systems for Manufacturing and Engineering,
HongKong, mai 2-4, 1994.
[YE et al. 94d] YE, X.J. et MATHON, A. "Objets-Oriented Process Simulation". Proceeding
ofEuropean Simulation Multiconference, Barcelone, Espagne, juin 1-3, 1994.
[ZEIGLER 76] ZEIGLER, B.P. "Theory of Modeling and Simulation". New-York: John
Wiley & Sons, 1976. 534p.
[ZEIGLER 89] ZEIGLER, B.P. "Hierarchical Modular Discrete-event Modeling in an Object
Oriented Environment", SIMULATION, 1987, Vol. 49, No. 5, p.219-230.
[ZHAO 89] ZHAO, X.I. "Contribution la Construction d'un Systme Expert d'Aide la
Conduite d'Ateliers Manufacturiers". Thse Doct.: Universit de Valencienne, 1989.
189p.
 ANNEXEl

OBJET, SIMULATION ET PROGRAMMATION

CONCURRENTE

ABSTRACTION ET ENCAPSULATION
Ces deux concepts sont complmentaires. L'abstraction se concentre sur la vue externe d'un
objet et l'encapsulation empche les clients de voir l'intrieur d'un objet, l o le comportement
de l'abstraction est implment. L'encapsulation procure les diffrentes abstraction.
AGENT
Une entit physique ou abstraite, qui est capable d'agir sur elle-mme et sur son environnement
et qui dispose d'une reprsentation partielle de leur environnement, qui dans un univers multi-
agents, peut communiquer avec d'autres agents, et dont le comportement est la consquence de
ses observations, de sa connaissance et des interactions des autres agents. On dit aussi un objet
autonome qui a son propre contrle).
ATTRIBUT (CHAMP)
Terme employ gnralement dans le cadre de reprsentation des connaissances. Les attributs,
outre un composant statique d'un objet auquel est associe une valeur, disposent d'informations
complmentaires concernant la manire d'utiliser cette valeur.
CHANGEMNTDECONTEXTE
Opration qui consiste remplacer le contexte d'un processus qui utilisait le processeur par
celui d'un autre processus qui doit devenir actif suite l'arrive d'vnement. Dans la vie
courante, c'est ce que nous posons une question sur un autre sujet.
CLASSE (MODULE, PACKAGE)
TI s'agit de la notion centrale de l'approche objet. Une classe est l'abstraction d'un ensemble
d'objets qui ont des proprits similaires. Les objets en sont la reprsentation concrte
l'excution du systme. Ce sont les instances de la classe. Une classe dfinit un ensemble
d'objets par leur comportement et leur utilit, mais pas par leur implmentation. Elle comporte
une reprsentation des donnes qui formeront l'objet (champs ou attributs) et des traitements
qu'il est possible de leur appliquer (mthodes ou routines).
CLASSE ABSTRAITE (VIRTUELLE)
Une classe abstraite est une classe qui n'a pas pour vocation d'tre instancie, mais de dcrire
abstraitement un concept dans le but d'organiser la hirarchie de classes ou de dfinir des
mthodes et des variables qui s'appliqueront aux classes de plus bas niveau. Les classes
abstraites servent ainsi de mcanisme de factorisation des caractristiques des classes..
 232

CONCURRENCE
Bel anglicisme qui signifie paralllisme. Ce faux ainsi est proscrire.
CONTEXTE
Somme de toutes les informations qui permettent un processus de savoir o il en est dans
l'excution d'une tche.
COROUTINE
Une coroutine est un objet, avec son propre tat d'excution, qui peut tre suspendu ou repris
par ces deux routines membres: reprendre et suspendre. La routine reprendre est utilise
uniquement par les mthodes membres de la coroutine; elle active toujours la coroutine dont
elle est lment et dsactive la coroutine appelante. La routine suspendre est utilise
uniquement dans le corps de la coroutine; elle dsactive cette coroutine et active une autre
coroutine. Une coroutine s'excute squentiellement son comportement dfini par une routine
membre sans paramtre appele fonctionner.
EVENEMENT
Un stimulus qui s'excute sur le systme, la manifestation de la vie du systme. TI peut tre
externe (venant de l'extrieur du systme) ou interne. TI sert de signalisation.
EXCEPTION
Deux sens trs diffrents identifient le mcanisme d'exception. Le premier sens est propre un
langage de programmation (ADA, C++, EIFFEL, ...), o l'exception fait rfrence un
vnement se produisant l'excution anormale de la mthode d'objet. L'autre sens rencontr
dans les problmes de reprsentation des connaissances, dsigne le moyen de dcrire des objets
marginaux sans rapport avec les autres.
HERITAGE
Une classe peut tre dfinie comme une extension ou une restriction d'une autre classe. La
nouvelle classe est alors appele "hritire" de l'autre. Chaque classe peut hriter de plus d'une
classe et mme plus d'une fois de la mme classe. L'hritage peut donc tre simple ou multiple.
C'est une premire forme de rutilisabilit.
HIERARCHIE
Rangement ou ordonnancement des abstractions. Les deux hirarchies les plus connues sont:
hirarchie de classes (relation gnralisation/spcialisation) signifiant "genre de... " et hirarchie
d'objet (relation agrgation/dsagrgation) qui, lui, veut dire "faire partie de".
INSTANCIATION
Processus consistant remplir le formulaire d'une classe gnrique ou paramtre afin de
produire une classe partir de laquelle on peut crer des instances.
INTERRUPTION
La partie la plus dlicate dans la conception d'un systme vnements. En effet, les
interruptions, signaux physiques donc de trs bas niveau, ont des rpercussions un trs haut
niveau. Pour viter le dsagrment d'tre interrompu, il est possible de masquer les
 233

interruptions. Rien voir avec un quelconque dguisement puisque le masquage correspond au

refus de se laisser interrompre.
LIAISON STATIQUE (DYNAMIQUE)
Mcanisme pour lequel un envoi de message est mis en .rapport avec une mthode. D existe
deux types de liaison. Dans un liaison dynamique, la mthode correspondant un message est
recherche lors de l'excution de l'envoi de message. En revanche, dans un liaison statique la
recherche est la mthode est effectue lors de la compilation des envois de message. Les
liaisons statistiques, plus efficaces, ne peuvent tre ralises que pour des langages disposant
d'un typage fort.
MESSAGE
Signal envoy par un objet un autre, qui demande l'objet rcepteur d'excuter l'un de ses
mthodes. Un message est constitu de trois parties: le nom du rcepteur, la mthode qu'il doit
excuter, et les paramtres ventuels dont la mthode peut avoir besoin pour remplir sa tche.
MESSAGE SYNCHRONE/ASYNCHRONE
Termes utiliss dans la programmation concurrente objets. Pendent l'envoi d'un message
synchrone, l'metteur attend ou se bloque jusqu' ce que le rcepteur ait reu le message. Dans
le cas d'envoi d'un message asynchrone, l'metteur continue son excution aprs avoir envoy
le message, mais sans attendre que le rcepteur le reoive. Les avantages de l'envoi des
messages synchrones sont le transfert bidirectionnel des informations, la comprhension, la
smantique, la synchronisation, l'indication des erreurs, etc., et les avantages de l'envoi des
messages asynchrones sont la flexibilit, la capacit d'expression, le paralllisme, etc.
METACLASSE
La classe d'une classe; une classe dont les instances sont elles-mmes des classes.
METHODE
Procdure dcrite dans une classe, qui est excute lors de la rception d'un message par l'une
des instances de cette classe. Les mthodes sont les composantes dynamiques des objets.
MODULARITE
Proprit d'un programme qui a t dcoup en modules. Scinder un programme en module
permet d'en rduire sa complexit.
MONITEUR
Un moniteur est une unit syntaxique analogue un module il permet de regrouper des
variables ainsi que les procdures agissant sur ces variables. Les variables moniteurs ne sont
accessibles qu' travers les procdures moniteur. En d'autre terme, un moniteur est une classe
pouvant tre excute tour tour par diffrents processus, mais en plus, le moniteur assure
l'exclusion mutuelle sur les procdures dclares dans le moniteur.
MONOMORPHISME
Un concept dans la thorie des types, selon lequel un nom peut seulement dsigner des objets
de mme classe.
 234

MULTIPROGRAMMATION (MULTITRAITEMENT, TRAITEMENT REPARTI)

On appelle multiprogrammation le cas o les processus se partagent une machine, y comprise
le processeur (il y a donc simultanit globale et entrelacement des activits, mais pas
simultanit relle un instant); multitraitement le cas o les processus se partagent les
mmoires, chacun ayant son processeur; traitement rparti le cas o chaque processus a sa
machine et est autonome, mais relies aux autres par un rseau de communication.
OBJET (INSTANCE)
C'est une entit qui prsente quelques comportements bien particuliers. Un objet se caractriser
par un tat (qui englobe toutes ses proprits), un comportement (faon dont il agit et ragit)
et une identit (ce qui le distingue des autres). La structure et le comportement d'objets
similaires sont dfinis dans une classe commune.
OBJET ACTIF (CONCURRENT)IPASSIF (SEQUENTIEL)
Un objet actif est un objet qui possde les trois proprits suivantes: 1) un objet thread qui est
un code d'excution qui s'excute indpendamment des objets; 2) un tat d'excution qui
contient les informations d'tats ncessaires l'excution concurrente de l'objet; et 3) un
contrle de l'exclusion mutuelle qui permet d'excuter une mthode sur une ressource et exclut
que d'autres mthodes agissent sur cette ressource.
OBJET AUTONOME (CONTROLE)
Un objet autonome est un objet concurrent qui a une activit autonome.
ORDONNANCEUR (SCHEDULER, NOYAU DE SYNCHRONISATION)
Module logiciel charg de grer les tches et les processus. On peut considrer qu'un
ordonnanceur est un concentr du systme d'exploitation dans lequel on retrouve le minimum
vital. ll existe en gnral deux approche pour ordonnancer les tches et les processus. La
premire est base sur la notion d'vnement, c'est--dire, le scheduler fournit des fonctions
lmentaires permettant d'ordonnancer les vnements dans le temps. La deuxime approche
est base sur la notion de processus: le modle simul est dcrit par un ensemble de processus
progressant dans le temps. Chaque processus est un objet concurrent dans ce deuxime
approche. ll est compatible donc avec l'approche objet.
ORDONNANCEMENT
Mthode qui permet tout moment de dcider quel processus utilise quel processeur.
PARADIGME
Manire de penser qui dirige, consciemment ou inconsciemment les penses et les actions. Les
paradigmes sont essentiels car ils constituent un rfrentiel collectif concernant la pense et
l'action. Toutefois, ils reprsentent un obstacle majeur l'adoption de nouvelle approches,
foncirement meilleures.
PERSISTANCE
C'est la proprit d'un objet selon laquelle son existence transcende te temps (l'objet continue
exister aprs la fin de l'excution du programme qui l'a cr) et/ou l'espace (c'est--dire que
 235

l'adresse de l'objet dans l'espace peut changer par rapport son adresse de cration). Cela est
trs important pour des systmes qui s'excutent sur un ensemble de processeurs distribus.
POINTDEVUE
Un point de we est une interprtation de tout ou partie des donnes d'un objet. Ce concept est
fondamental dans la problmatique de la reprsentation des connaissances o diverses
connaissances n'ont pas la mme signification dans des domaines de discours diffrents.
POLYMORPIDSME
Un concept dans la thorie des types, selon lequel un nom (par exemple une dclaration de
variable), le polymorphisme permet dsigner des objets de nombreuses classes diffrentes relis
par une superclasse commune. Ainsi, un objet dsign par ce nom peut rpondre de diffrentes
faons un ensemble commun d'oprations.
PREEMPTION
Action qui consiste interrompre un processus utilisant un processeur pour faire passer un
autre processus. En gnral, la premption est cause par le dclenchement d'un processus plus
prioritaire que celui qui a la main.
PROCESSUS
Unit atomique d'excution de tches (Le processus est virtuellement un processeur). Afin de
savoir o il en est dans l'excution de sa tche, le processus a un contexte. Un processus a
aussi un tat pour l'ordonnanceur: il peut tre lu (on dit alors qu'il a la main sur le(s)
processeur(s) sur le(s)quel il tourne), ligible (il attend la libration du processeur), bloqu (il
attend un vnement pour devenir ligible), termin (le processus a accompli sa tche).
PROCESSUS LEGER (POIDS PLUME)
La lgret d'un processus d'un processus est proportionnelle la lgret de son contexte. Un
processus lger est un modle de communication interprocessus par une mmoire commune.
PROGRAMMATION CONCURRENTE (PARALLELE, SIMULTANEE)
La programmation concurrente est le nom donn aux notations et aux techniques de
programmation exprimant que le paralllisme est possible; c'est--dire, l'utilisation d'outils et de
techniques de mise en oeuvre de processus concurrents fait partie de la thorie des systmes
d'exploitation. Elle rsout les problmes de communication et de synchronisation.
PSEUDO-PARALLELE/QUASI-PARALLELE
Dans un schma d'excution pseudo-parallle, le processeur est attribu aux diffrents
processus par un noyau, sans l'intervention du programmeur. Par contre, dans un schma
d'excution quasi-parallle, le langage de programmation ne comporte pas de noyau et ne
s'occupe pas de partager le processeur entre les diffrents processus. Dans le deuxime cas on
utilise souvent le terme coroutine la place du terme processus.
RENDEZ-VOUS
Le rendez-vous est un outil de synchronisation de plus haut niveau que le moniteur; en
consquence, il est ncessaire d'ajouter au mcanisme de rendez-vous proprement dit plusieurs
 236

syntaxiques permettant de rsoudre agrablement les diffrents problmes de Synchronisation

qui peuvent se prsenter.
SEMAPHORE
Un smaphore est une variable entire ne pouvant prendre que des valeurs positives (ou
nulles). TI fournit un mcanisme qui permet des processus d'tre faiblement synchroniss. En
effet, une synchronisation fort enchane gnralement une mauvaise utilisation des ressources.
Un asynchronisme complet est impossible et induit une cacophonie.
SIMULATION
La simulation est une technique de modlisation qui consiste reproduire le comportement
dynamique d'un systme sur l'ordinateur afin de mieux le connatre, de mieux matriser son
volution dans le temps dans un environnement donn.
SIMULTANEITE
Permet des objets diffrents d'agir en mme temps. Distingue un objet actif d'un objet qui ne
l'est pas.
SURCHARGER
Associer plusieurs significations au mme nom de mthode, ce qui permet un seul message
de dclencher diffrentes actions en fonction de l'objet qui le reoit et des paramtres qui lui
sont associs. Le langage slectionne automatiquement la signification approprie en regardant
le type de l'objet rcepteur et en vrifiant le nombre et le type de paramtres.
SYNCHRONISATION
Mcanisme qui permet de remettre les pendules l'heure entre plusieurs processus. Le rendez-
vous entre processus est un moyen de synchronisation.
SYSTEME SYNCHRONE/ASYNCHRONE
Un systme est qualifi de synchrone si les tches effectuer sont fortement couples. Dans un
systme synchrone, il existe en gnral un dispositif gnrant des vnements cycliques une
frquence fixe. Les autres vnements (en nombre gnralement trs restreint) sont
resynchroniss (ils sont traits cycliquement). Dans un systme asynchrone, les tches ont des
conditions d'activation faiblement couples. Cela conduit des systmes plus modulaires,
moins monolithiques que les systmes synchrones.
TACHE
Unit atomique de travail pour une machine. En gnral, dans le temps rel, les programmes
sont composs de plusieurs tches qui s'excutent en parallle. Une tche cyclique est une
tche o le travail faire est sempiternellement le mme.
THREAD
Littralement, il s'agit d'un fil. Ce fil est le fil conducteur de ce que l'on doit faire. TI y a aussi
une notion de "squentialit" dans ce terme qui rappelle le file de la vie d'une tche. Ds
permettent d'avoir plusieurs flots de contrles dans le mme espace d'adressage. On parle de
processus lgers; ils ont leurs propres activits et ressources (piles, donnes).
 237

~MENTENPARALLELE
Technique de programmation o plusieurs activits se droulent en mme temps. Lorsqu'on
l'implmente en se basant sur du logiciel, l'ordinateur simule des activits parallles en passant
rapidement de l'une l'autre. Lorsqu'on l'implmente en se basant sur du matriel, plusieurs
units de traitement prennent en charge diffrentes parties du programme et les traitent
rellement en parallle.
TYPAGE
C'est le fait d'imposer la classe d'un objet de faon empcher les objets de diffrents types
d'tre changs.
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
 ANNEXEll

PROGRAMMES EN TETES DES CLASSES D'OBJETS

Fichier "THREAD.HPP"

****************************** ~.FDPP ***********************************

Description
This structure is the abstract base class for a11 schedulable objects (or processes). It contains the data
structure and member fonction that manipulate registers value and the stack parameters.

Functionalities:
1- Implement scheduling decisions and implementation for a11 concrete process classes derived
from Thread.
2- Define data structures to manipulate stack parameters: stack pointers and base pointers.
3- Advance the virtual clock: clock
4- Perform context switch between Thread objects (processes).

Copyright(c) 1990-93 NETWORK IN1EGRATED SERVICES, Inc. Ali Rights Reserved

class Thread : public Item {

friend class Process;
friend class Tracer;
friend class Simulation;

public:
Thread(const char*); Il creates a thread and initializes its signature with a signature (string).
virtual -ThreadO; Il destructor.
int priorityO const; Il returns the priority of 'this' thread.
void priority(int); Il sets the priority levet of this thread.
void exits(long); Il overwrites the standard library fonction ::exits (int) for coroutines.
virtual void store(FILE&); Il saves "this" thread into a file object.
const char* get_keyO const; Il computes th identifier (signature) of 'this' thread.
void spawnO; Il initializes the envionment of "this" thread by performing a context switch
static TIME get_clockO; Il returns the virtua1 time of the scheduler.

protected:
static Thread* current; Il the thread currently active.
static void* basePtr; Il common stack base pointer for ali the coroutines.
static PQueue* scheduler; //polymorphie scheduling structure (priority queue).
DynArray* slaves; Il pointer to a dynamic array of threads blocked by 'this' thread.
enum States {
KILLED =1, Il the thread is inative (non-oprationel, cre).
CONTROL =2, Il the thread is currently loaded on the stack (lu, en cours).
IOLE =4, Il the thread stay inative until the scheduler or another thread wakes it up (bloqu).
SCHEDULED =8// the thread is scheduled to take control at a predefmed time.
}state; Il state of the thread.
int references; Il number of references to 'this' thread currently inserted in the sheduler.
const char* key; Il 'this' thread identifier (signature).
TIME releaseTime; Il the time 'this' thread is reactivated (scheduled) to take control of the stack.
 240

bool switch_outO; Il saves the portion of the stack that supports the thread into buffer.
void scheduleQ; Il pops the nexr thread from the scheduler and advances the virtual clock
Il if necessary.
virtual double rankO const; Il computes the rank value of 'this' thread.
virtuallong runO; Il executes 'this' thread body.
static void process_err(const char*); Il creates a procssErr exception with the attribute.

private:
Thread(const Thread&); Il copy constructor
Thread& operator=(const Thread&); Il member-wise assignment constructor

static Thread* root; Il pointer to the root Thread ( : :main(int argc, char **argv)))
static TIME clock; Il simulation time.
void* buffer; Il memory block to save the portion of the stack associated to 'this' thread.
size_t size; Il size in bytes of the above buffer (Thread::buffer).
jmp_buf env; Il buffer containing the thread environment (value of the registers).
int prty; Il 'this' thread's priority level.
static void (*action)(Thread*); Il pointer to a function defining the tracer routine.
void switch_backQ; Il restores the stack frame associated with "this" thread from memory.
}; Il THREAD_HPP

Fichier "PROCESS.HPP"

Il*********************** PROCESS.HPP **********************************

Process of a discrete event simulation model

Description
Processes are specialized, non pre-emptive threads that have a time generator and a set of variables
(info). The array 'info' contains data or parameters that represent critical information about the process.
This array cao be used, for instance, to visualize the process. Processes communicate through a basic
masterlslave protocol where a process A (known as slave process) depends on another one to change its
state. More sophiticated protocol, queues, are used by QNode abjects.

Copyright(c) 1990-93 NETWORK INTEGRATED SERVICES ,loc. AU Rights Reserved

class Process : public Thread {

public:
enum Mode {QUEUE, Il first-in-first-ouL
STACK, Il last-in-first-out.
PRIORITY }; Il the transaction are inserted according to their rank values.
Il mode of item insertion in the queue.
operator Generator*O const; Il returns a pointer to the timer generator (hatcher).
void block(Thread* =0); Il blocks "this" process until a thread reactivates it.
void set_generator(const Generator&); llinitializes the time hatcher with a generator object.

protected:
double* info; Il array of parameters produced by the process (statistics).
void allocate_info(short); Il initializes the attribute info.
void pending_one(Thread** T, ushort n =1); //blocks "this" process until atleast one of the
11 thread of the array T[n} is killed.
void pending_all(Thread** T, ushort n =1); Il blocks "this" process until ail the threads of the
Il array T[n] are ldlled.
void delay (TIME t =0); Il blocks "this" process fort units of time and reschedules it for time:
Il (clock += t).
long preemptsQ; Il blocks the process currently in control until "this" process is killed.
 241

virtual long runO; Il executes the coroutine associated to this thread .

Process(const char*, Generator* =0); //creates a process with a signature and a time generator
virtual -ProcessQ; //destructor
private:
Generator* hatcher; //time-advance generator
Process(const Process&); //copy constructor
Process& operator=(const Process&); 1/member-wise assignment constructor
}; //PROCESS_HPP

Fichier "MACHINE.HPP"

************************************* ~C~.HPP *********************************

Single input/output queue machine representation for job-shop workshop simulation models.

Description
A machine object acts as an automous object that receives (consumes) items from its input queue, transforms
the transactions and puts (produces) them into its output queue. A machine is characterized by six kinds of
attributes: structural, contingent, instantaneous, event, historie and statistic. Structural attnbutes characterize
fondamental aspects of machines such as the structure and the relationship with other objects. Contingent
attributes describe the production context. Instantaneous attributes mean current state and their evolution
depends on event attributes. Historie attributes permit to keep more or less the detail of the past. Statistic
attributes are computation results that permit to compact historie attributes to obtain machines functioning
laws. An automous object contains four types of methods: accessors, events generators, transformations
(computations and processes) and tests. The use of the methods is defined in the behavior method run of active
objects.

Copyright 1993-1994 YB Xiaojun, Ecole Nationale Suprieure des Mines de St-Etienne. Ali Rights Reserved
------------ ---------------------
class Machine :: public Process {
friend class Transporteur;
friend class Station;

protected:
double x, y; Il machine position in the workshop.
double machineValeur, initValeur; Il currentand initial machine value.
double prixUnitaire; Il unit cost of utilization.
int capaciteEntree; Il size of input queue.
int capaciteSortie; Il size of output queue.

Mode modeAmont; Il input queue character (management mode).

Mode modeAval; Il output queue character.
enum State { non-engage, Il machine is in non-active state.
disponible, Il machine is in free state.
pret-a-charger, Il machine is in ready to load item (prepared) state.
productive, Il machine is in productive state.
pret-a-decharger, Il machine is in ready to unload item state.
preparation, Il machine is in preparation state.
panne } Il machine is in breakdown state.
etat; Il machine state.
TIME tempsReparation; Il reparation time of machine.
TIME tempsPreparation; Il preparation time of machine.
TIME tempsUtilisation; Il operative time of machine.
TIME tempsEnPanne; Il Breakdown time of machine.
 242

TIMB duree; Il production (simulation) time

#ifdef M_SUNI
int stock; Il number of parts in the input queue
int counteur; Il number of manufactured parts by this machine.
int ordreLance; Il number of dispatched 'batches in the workshop.
int ordreTennine; Il number of tenninated batches.
int lotDebutDate; Il Dispatched date of the batch.
int lotFinDate; Il Tennined date of the batch.
#endif

#ifdef m_STATISTIQUE
double tauxRebuts; Il machine scrap rate.
double taux.Occupation Il machine utilization rate.
#endif

Panne* panne; Il pointer to breakdown treatment object.

Palette* palette; Il pointer to preparation process.
Transporteur ** transport; Il pointer to compatible associated transporters.
Generator* loi; Il time hatch generator

SHOW(
void showO const;) Il shows the value of machine attributes en mode text.
public:
SortQ* entre; Il input queue.
SortQ* sotie; Il output queue.
ResQ* ressource; Il resource queue.

Part** reference Il reference candidate of parts that this machine cao transfonn.
Part* piece; Il current part.
Batch* lot; Il current batch.
Machine(SortQ*, SortQ*, const char*, Generator* = 0); Il constructor
-MachineO; Il destructor.
double rankO const; Il method for computation machine priority.
void set_position(double, double ) ; Il set machine position.
void set_stock(int s) {stock= s;}
void add_reparation(TIMB r) { tempsReparation+=r;}
void add_panne(TIMB p) { tempsEnPanne += p;}
void add_utilisation(TIME u) { tempsUtilisation += u;}
void add_compteur (int t) {counteur += t;}
void set_prix_unitaire(double uu) { prixUnitaire = uu;}
void set_taux_rebut (doubler) { tauxRebuts = r;}
void set_loi(Generator* g) { loi = g;}
void set_palette(Palette* p) {palette =p;}
void set_transport(Transporteur* t) {transport= t;}
void machine_valeur_init(double v) { machineValeurlnit =v;}
void remise_counteur 0 { counteur = 0;}
int nombre_piece_fabriqueO const { return counter;} Il If we remove the keyword const in the
int nombre_piece_stock const { return stock;} Il folowing methods, we cao define other
TIMB temps_reparationO const { return tempsReparation;} Il methods that read or write attribute
TIMB temps_preparationO const { return tempsPreparation;} Il value of implicated objects.
TIMB temps_utilisationO const { return tempsUtilisation;}
double taux_utilisationO const { return tauxRebut; }
 243

double taux_rebutsO const { return tauxRebuts;}

double prix_unitairO const { return prixUnitaire;}
double get_xQ const { return x;}
double get_yO const { return y;}
Point& get-positionO; Il get machine position.
TIME temps_panneO const { return tempsEnPanne;}
Generator* loi_panneQ const { return law;}
Palette* get.,..PaletteO const { return palette;}
Transporteur* transportO const { return transport;}
double valeur_resterO {
machineValeur= initValeur- prixUnitaire*tempsUtilisation;
return machineValeur;
}

void store(File&); Il saves the value of machine attributes into a file.

virtual void next_fromQO;
virtual void next_toQQ;
virtual Batch* choisir_lotO;
virtual choisir_mode (Mode);
double nombre_moyen_attenteO;
double temps_moyen_attente O;
double taux_rebuts O;
double taux_occupationO;
#ifdef m_SEMI_PERSISTENT
void getf( File&);
void putf(File&);
#endif
Il choice of next batch to transfonn.
Il choice of next machine to transfonn this batch.
Il choice of next part.
Il choice of selection mode of parts in the input queue.
Il computes and retums mean number of waiting parts.
Il computes and returns mean waiting time.
Il computes and returns
Il computes and returns occupied rates.
Il restores the content of the machine from a flle.
Il stores the content of machine into a file.

protected:
Part* recevoirO; Il receives a part from input queue.
void transfonnerO; Il transfonns a part.
void preparerO; Il throws a preparation process for a batch.
void expedier (Part*); Il sends a part into output queue.
void traiter_panneO; Il throws a beakdown traitment process.
virtuallong runO; Il this routine must be redeftned in derived class. Machine::runO perfonns
Il only recevoir(), transfonnerO and expedier 0 methods. There is no
Il decision implication in the machine behavior. So users have to overload
Il their own decisions activities predeftned or redeftnied in deri~;ed objects.
private:
void initO; Il initialization method for the constructor.
#ifndef m_SIMULATION_SIZE
Machine (const Machine&); Il copy constructor.
Machine& operator= (const Machine&); Il member-wise assignment.
#endif
}; Il MACHINE_HPP

Fichier "PART.HPP"

***********************************PAJtT_HPP*********************************
Transaction part representation (passive objects) for workshop simulation models.
 244

Description

The transaction units circulated in a simulation model are constituted of products, batches (job orders) and
parts. The bill of material defines the link between products and its parts. In the presimulation module, we cao
defme some methods to deduct from the product the structural and contingent attributes of job orders and
parts. We choice to implement these transaction items as passive objects. So part is a passive object that
describes the structure (process plan) that will be manipuleted by active objects in the production system.

Copyright 1993-1994 YE Xiaojun Ecole Nationale Suprieure des Mines de St-Etienne. AU Rights Reserved.

class Part : public Item {

friend class Machine;

friend class Station;
friend class Transporteur;
friend class Palette;
friend class Panne;

protected:
TIME tempsTot, //time for scheduling
tempsTard;
TIME tempsEntre, //entry time for executing
tempsCommence// effective start time
int position; Il position in the plan

public:
enum State {
non-active,
stock,
attente,
transport,
production,
arret} etat; Il part state.
double priorite; Il part priority.
GSlist* gamme1; Il principal process plan.
GSlist* gamme2; Il second process plan.
TIME tempsCycle, Il parameters for the statistics
tempsAttente;
double valeurlnitial, Il raw material cost.
valeurCourant, Il current part value.
valeurAjoute; Il added value by the tranformation.
Part (const char*, GSlist* = NULL, double= 0.0);
Il constructor with the part name, part processing plan and priority
void set_nom(char* n) {name = n;}
void set_position(int n) {position= n;}
void set_temps_tot (TIME t) {tempsTot = t;}
void set_tempsTard (TIME d) {tempsTard = d;}
void set_temps_attente (TIMEa) {gamme1(position)->tempsAttente =a; }
void set_temps_cycle(TIME t) {gamme1(position)->tempsCycle = t;}
void set_preparation_time(TIME) (gamme1(position)->tempsPreparation = t;}
void set_gamme1 (GSlist* t) {gamme1 = t;}
void set_gamme2(GSlist* t) gamme2 = t;}

double rankO {return (double) (priorite +temps_opeatoire(position));}

 245

Il ici, on peut installer de diffentes methodes de gestion avec cette methode (fonction)
GSiist* gammelO const {retum gammel;)
GSlist* gamme20 const {retum gamme2;)
char* get_nomO const {retum nom;)
int get_positionO const {retum position;)

TIME temps_operatoire (int position) const

{retum (gammel->aperatorD(position)).tempsOperatoire;}
TIME temps_operatoire (int position) const
{retum (gamme2->aperatorD(position)).temps0peratoire;)

TIME temps_attente (int position) ; Il waiting time of part in a principle operation

TIME temps-attente (int position) ; Il waiting time of part in a secondairy operation
#ifdef m_SUIVI
TIME temps_suiviQ; Il returns used simulation time.
void add_temps-operatoireO; Il adds service time to conserve operation time.
TIME temps_a_lancerO; Il computes release time of part.
TIME temps_attenteO; Il computes total waiting time.
TIME temps-attente-secondaire O;// computes total waiting time if we use SGlist.
#endif

void set_tempsEntre (TIME t) { tempsEntre = t;}

TIME get_tempsEntreO const {retum tempsEntre;)
TIME get_tempsCommence 0 const {retum tempsCommence;)

void store(File& part); Il saves the value of part attributes into a fe.

#ifdef m_SEMI_PERSISTENT
void getf( File&); Il restores the content of the machine from a fe.
void putf(File&); Il stores the content of machine into a fe.
#endif

SHOW(
void showO const;) Il shows the value of part atttibutes en mode texl
private:
#ifndef m_SIMULATION_SIZE
Part (const Piece& p); //shallow copy constructor
Part& operator= (const Part& p); Il member-wise assignment
#endif

); //PART_HPP

Exemple Simplifi de la Dfinition du Comportement d'une Machine

*********************************MACHINE CPP ***********************
long Machine::runO {

for(;;) {
Part* piece = (Part*) recevoirQ;
TIMEt, tt;
t = Thread::get_clockO;
piece->tempsEntre = t;
TIME n = piece->tempsTot - t;
if (n > 0.0) //rupture d'approvisinnement
 246

block(this);
Il ici, on peut ajouter des service de Palette
tt= piece->tempsAttente = Thread::get_clockO - piece->tempsEntre;
piece->set_temps_attente (tt);

#ifdef m_PALETI'E Il on definit le processus preparation

(machine.conteur = 0) {
palette->timerO
tt= palette->(operator TIMEO const);
piece->set_preparation_time(tt);
add_temps_preparationO;
}
#end

int p = piece->get_positionQ;
TIME tempsOperatoire = piece->temps_operatoire(p);
delay{tempsOperatoire);
add_counteurQ;
Il piece->priority += lOOO.(piece-> -t); on remet jour la priorite de la piece.

add_temps_operatoire (tempsOperatoire);

(piece->position)++; Il avancer la position de la gamme.

piece->tempsCommence = Thread::get_clockQ; Il remettre le temps d'attente.
#ifdef m_TI'RANSPORT
Il on definit ici les interactions avec les transporteurs.
#end

expedier (piece);
}

#ifdef m_PANNE
' Il on definit ici le traitement de panne (non-pre-emptiple).
#end
retumTRUE;
} //MACHINE_CPP

Modle 1: modle pour tester les mthodes recevoire, transformer et expdier. Les objets
SortQ, Producer et Consumer sont des classes prdfinies par Meijin++.

Modle 2: modle pour modliser des oprations de retouche. L'objet Recycler est une
instance de la machine.
 247

Modle 3: deux machines identiques qui travaillent en parallle. Le but est de dfinir des rgles
de gestion_ de pices (dcisions locales) dans la file d'attente.

Modle 4: une simplification du modle 3. Les deux machines sont remplaces par un objet
d'un haut niveau Station (encapsulation).

Modle 5: atelier de flow shop, une extention de modle 1.

 248

Model6: atelier de job shop sans des opration de transport.

8'---....>lsh~dl ~
1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1

~ ~ sh~<IQI~I sh~iQJi' ~ sh~(QI~I sh~(Qii'

~ sh~iQI~I sh~dQ}(

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1

Mo del 7: modle pour modliser la gestion des ressources partages.