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.