Georges Habchi: Document de Synthèse

UNIVERSITE DE SAVOIE
Document de Synthèse
Présenté
par
Georges Habchi
Pour obtenir
L’HABILITATION A DIRIGER DES RECHERCHES
Date de soutenance : 5 décembre 2001
Composition du jury
M. Pierre LADET (Président jury) Professeur à l’INP de Grenoble

M. Henri PIERREVAL (Rapporteur) Professeur à l’IFM d’Aubière
M. René SOENEN (Rapporteur) Professeur à l’Université de Lyon1
M. François VERNADAT (Rapporteur) Professeur à l’Université de Metz
M. Alain HAURAT (Examinateur) Professeur à l’Université de Savoie
M. Alain COURTOIS (Examinateur) Professeur à l’Université de Savoie
LLP/CESALP – ESIA – Université de Savoie – BP 806 – Annecy Cedex

Partie 1
! " # $%
Partie 2
& ' $ $
! ( ) * ! !
$# #$
! +(
# %,
! (
% $+
! $( $ ,
*- ./ 0 !1 2
Partie 3
3 # 4
Partie 1
1. Etat civil 13
2. Cursus universitaire 13
3. Fonctions universitaires occupées à l’issue du doctorat 15
! " # $%
1. Activités pédagogiques 17
1.1. Actions à des fins pédagogiques_________________________________________ 18
1.2. Enseignements assurés de septembre 1985 à septembre 1988 _________________ 19
1.3. Enseignements assurés depuis octobre 1988_______________________________ 19
2. Activités de recherche et d’encadrement 23
2.1. Les thématiques abordées et les résultats obtenus __________________________ 24
2.1.1. La fissuration de solidification (mars 1982 – septembre 1986) ______________________ 24
2.1.2. La plasticité dynamique (octobre 1986 – septembre 1988) _________________________ 24
2.1.3. La modélisation et la simulation des SdPs (depuis octobre 1988) ____________________ 25
2.2. Activités d’encadrement _______________________________________________ 29
2.2.1. Encadrements et co-encadrements de DEA______________________________________ 29
2.2.1.1. La fissuration de solidification (octobre 1983 – septembre 1986) _______________ 29
2.2.1.2. La plasticité dynamique (octobre 1986 – septembre 1988) _____________________ 29
2.2.1.3. La modélisation et la simulation des SdPs (depuis oct. 1988)___________________ 30
2.2.2. Encadrement de thèses de doctorat en modélisation et simulation ___________________ 31
2.3. Activités scientifiques nationales et internationales _________________________ 32
3. Activités administratives et responsabilités d’intérêt collectif 33
3.1. Conseils et commissions _______________________________________________ 33
3.2. Responsabilités administratives _________________________________________ 34
4. Liste des travaux, publications et développements 35
4.1. Mémoires de DEA et de thèse de doctorat _________________________________ 35
4.2. Ouvrage____________________________________________________________ 35
4.3. Revues spécialisées ___________________________________________________ 35
4.4. Article invité (régional) _______________________________________________ 36
4.5. Congrès avec comité de lecture et actes ___________________________________ 36
4.6. Workshop et manifestations nationales ___________________________________ 38
4.7. Rapports de synthèse et de fin de contrats industriels________________________ 38
4.8. Projets Université/Industrie ____________________________________________ 39
4.9. Conférences invitées et séminaires ______________________________________ 39
4.10. Développement de prototype et de logiciel________________________________ 40
Partie 2
& ' $ $
! ( ) * ! !
$# #$
1. Introduction 47
2. Le système de production 49
2.1. Les composantes d’un système de production ______________________________ 49
2.1.1. Le système de fabrication ____________________________________________________ 49
2.1.2. Le système de pilotage _______________________________________________________ 50
2.2. La maîtrise des systèmes de production ___________________________________ 51
3. L’évaluation des performances des systèmes de production 52
3.1. Les mesures directes __________________________________________________ 52
3.2. Les méthodes analytiques______________________________________________ 53
3.3. La simulation pour l’évaluation des performances _________________________ 53
3.4. Méthodes analytiques vs simulation _____________________________________ 54
4. La simulation informatique 54
4.1. Définition de la simulation informatique _________________________________ 55
4.2. Le processus de simulation_____________________________________________ 55
4.3. Méta-modélisation, modélisation, logique de changement d’état et simulation ___ 58
4.3.1. Méta-modélisation et modélisation_____________________________________________ 58
4.3.2. Logique de changement d’état et simulation_____________________________________ 59
4.3.2.1. La logique orientée événements (event scheduling) __________________________ 59
4.3.2.2. La logique orientée activités (activity scanning) _____________________________ 60
4.3.2.3. La logique orientée processus (process interaction) __________________________ 60
4.3.2.4. L’approche orientée objets _____________________________________________ 60
4.4. Les langages de simulation ____________________________________________ 61
4.4.1. Classification des langages en fonction de la spécialisation _________________________ 61
4.4.2. Classification des langages en fonction de l’approche de modélisation _______________ 63
5. Etat de l’art actuel de la simulation dans les SdPs 64

5.1. La simulation pour l’analyse et la conception des SdPs______________________ 65
5.2. La simulation pour le pilotage, l’ordonnancement et la planification des SdPs ___ 66
5.3. Intégrations et approches hybrides de la simulation_________________________ 68
5.4. La simulation pour l’enseignement et l’apprentissage _______________________ 69
6. Quelques-unes de nos contributions à la recherche en simulation 69
6.1. Influence de la taille des lots ___________________________________________ 70
6.2. Intégration des plans d’expériences à la simulation_________________________ 71
6.3. Influence des règles d’ordonnancement __________________________________ 72
6.4. Etude de la variabilité des temps de processus _____________________________ 73
7. Conclusion 73
! +(
# %,
1. Introduction 75
2. Analyse des potentialités et des limites de la simulation des SdPs 76
2.1. Potentiels et apports de la simulation ____________________________________ 76
2.1.1. Apports de la simulation _____________________________________________________ 78
2.2. Limites actuelles de la simulation _______________________________________ 78
2.2.1. Limites liées à la modélisation ________________________________________________ 79
2.2.2. Limites liées à l’outil informatique_____________________________________________ 80
2.2.3. Conclusion ________________________________________________________________ 81
2.3. Critères d’efficacité de la simulation _____________________________________ 81
2.3.1. Critères liés à la modélisation _________________________________________________ 82
2.3.2. Critères liés à l’outil de simulation_____________________________________________ 82
2.4. Propositions d’améliorations ___________________________________________ 83
3. Analyse et conceptualisation du SdP du point de vue de la simulation 84
3.1. Analyse et conceptualisation du système de fabrication ______________________ 86
3.1.1. Structure hiérarchique du système de fabrication ________________________________ 86
3.1.2. Comportement d’une ressource du point de vue de la simulation ___________________ 86
3.1.3. Niveaux d’abstraction et états d’une ressource___________________________________ 87
3.1.4. Décomposition et caractérisation du flux physique _______________________________ 92
3.1.5. Le concept STP : Système de Transformation du Produit__________________________ 93
3.1.6. Comportement du STP dans un SdP dit « parfait » _______________________________ 93
3.1.7. Le concept EC : Entité Circulante _____________________________________________ 94
3.1.8. La ressource auxiliaire ______________________________________________________ 95
3.2. Analyse et conceptualisation du système de pilotage ________________________ 95
3.2.1. Des travaux existants autour de l'ordonnancement et la conduite d'ateliers ___________ 95
3.2.2. Structures de pilotage _______________________________________________________ 98
3.2.3. Notre choix d’une structure de pilotage hybride : une structure coordonnée hiérarchisée
_________________________________________________________________________ 100
3.2.4. Structure globale et tridimensionnelle du pilotage _______________________________ 100
3.2.5. Structure locale et typologie du pilotage _______________________________________ 102
3.2.6. Le concept CP : Centre de Pilotage ___________________________________________ 103
3.3. Informations d’échange entre STPs, ECs et CPs __________________________ 105
3.4. Proposition d’un cadre de simulation en fonction de la décomposition adoptée du
SdP ______________________________________________________________ 106
4. Conclusion 107
! (
% $+
1. Introduction 109
2. Description d’un reseau STP/CP 110
3. Formalisation du réseau STP/CP 111
3.1. Formalisation du Système de Transformation du Produit (STP)______________ 112
3.1.1. Liste des attributs du STP___________________________________________________ 112
3.1.2. Liste des fonctions du STP __________________________________________________ 113
3.1.3. Liste des indicateurs du STP_________________________________________________ 114
3.1.4. Liste des événements du STP ________________________________________________ 115
3.2. Formalisation de l’Entité Circulante (EC) _______________________________ 118
3.2.1. Liste des attributs de l’EC___________________________________________________ 118
3.2.2. Liste des fonctions de l’EC __________________________________________________ 118
3.2.3. Liste des indicateurs de l’EC ________________________________________________ 119
3.2.4. Liste des événements de l’EC ________________________________________________ 119
3.3. Formalisation du Centre de Pilotage (CP) _______________________________ 120
3.3.1. Analyse fonctionnelle du CP _________________________________________________ 120
3.3.2. Analyse comportementale du CP _____________________________________________ 122
3.3.2.1. Processus de pilotage du CP ___________________________________________ 122
3.3.2.2. Etapes du processus de pilotage du CP___________________________________ 123
3.3.2.3. Emission et réception des messages de coopération et de coordination entre CPs__ 124
3.3.3. Logique de pilotage du CP __________________________________________________ 127
4. Modélisation Orientee Objet du réseau STP/CP 129

4.1. La Simulation Orientée Objet (SOO)____________________________________ 129
4.2. La Programmation Orientée Objet (POO) _______________________________ 129
4.3. La Modélisation Orientée Objet avec UML_______________________________ 131
4.4. Les paquetages du modèle UML du réseau STP/CP________________________ 133
4.5. Les relations entre paquetages du modèle ________________________________ 140
5. Conclusion 141
! $( $ ,
1. Conclusions sur nos recherches 143
1.1. Conceptualisation du processus de fabrication____________________________ 144
1.2. Conceptualisation du processus de pilotage ______________________________ 145
1.3. Modélisation orientée objet du processus de production ____________________ 146
2. Perspectives de nos recherches 147
2.1. Evolution du modèle Apollo ___________________________________________ 148
2.2. Génération automatisée de processus de simulation________________________ 149
2.2.1. Contexte de la recherche ____________________________________________________ 149
2.2.2. Définition de la problématique _______________________________________________ 150
2.2.3. Des processus logiciels pour la génération et l’automatisation de processus de simulation
_________________________________________________________________________ 151
2.3. Modélisation et simulation du processus de pilotage selon une approche multi-
agents ____________________________________________________________ 152
2.3.1. Contexte de l’étude ________________________________________________________ 152
2.3.2. Définition de la problématique _______________________________________________ 153
2.3.3. Pourquoi l’approche multi-agents ?___________________________________________ 153
2.3.3.1. Le CP vu comme un agent _____________________________________________ 153
2.3.3.2. Conception d’un système multi-agents des CPs ____________________________ 154
2.3.3.3. Définition des mécanismes de coordination _______________________________ 155
*- ./ 0 !1 2
1. Ouvrages 159
2. Revues 160
3. Congrès 164
4. Mémoires 167
5. Rapports 168
Partie 3
3 # 4
Ce mémoire présente essentiellement une synthèse des différents travaux menés depuis ma
titularisation à l’Université de Savoie, en vue d’obtenir l’Habilitation à Diriger des
Recherches. Il comporte les trois parties suivantes :
• d’abord, un curriculum vitæ et une synthèse d’activités succincte,

• ensuite, les travaux de recherche et de transfert technologique,
• enfin, quelques publications réalisées.
Le curriculum vitæ et la synthèse d’activités ont pour objet de présenter de manière succincte
mon cursus universitaire, mes diplômes ainsi que ma situation actuelle. Aussi, je précise dans
cette partie les différentes activités que j’ai réalisées (pédagogiques, scientifiques et
administratives), mes expériences en matière de responsabilité collective, d’animation
scientifique et d’encadrement doctoral, ainsi qu’une liste des travaux et publications.
La deuxième partie est consacrée à mon activité en matière de recherche dans le domaine du
génie industriel et principalement sur la thématique de « la modélisation et la simulation des
systèmes de production (SdPs) ». Elle trace de manière plus détaillée les travaux réalisés, à la
fois, personnels et encadrés au sein de l’équipe « conception et optimisation des processus
industriels » du LLP/CESALP (Laboratoire de Logiciels pour la Productique / CEntre des
Sciences Appliquées à La Production) ainsi qu’une conclusion générale et une perspective des
travaux futurs. Une bibliographie relativement importante vient compléter cette partie.
La troisième partie propose de présenter, à travers quelques publications sélectionnées, un

aperçu des fondements proposés et des résultats scientifiques obtenus pendant ces années de
recherche au LLP/CESALP.
1. ETAT CIVIL
Nom et prénom : HABCHI Georges

Date et lieu de naissance : 1955 - LIBAN
Nationalité : Française
Adresse personnelle : Le Verseau
15 rue des cygnes
74940 Annecy-Le-Vieux
Tél. : 04.50.23.71.37
Fonction actuelle : Maître de Conférences – 1ère classe
Section 60 – Génie Mécanique
Etablissement : IUT d'Annecy-Le-Vieux (Université de Savoie)
Département « Organisation et Génie de la Production »
9 rue de l'Arc-en-Ciel
74942 Annecy-Le-Vieux
Tél. : 04.50.09.22.55 – 04.50.09.65.87
Email : habchi@univ-savoie.fr
2. CURSUS UNIVERSITAIRE
1974 BACCALAUREAT
Série : Mathématiques Elémentaires (éq. Série S)
Date : juin 1974
Etablissement : Collège des Apôtres, Jounieh, LIBAN
1975 DEUG
Option : Mathématiques/Physiques (1ère année)
Date : octobre 1974 – juin 1975
Etablissement : Faculté des Sciences, Université de Beyrouth, LIBAN
(Interruption entre 1975 et 1976, provoquée par les « événements au Liban »)
1978 DUT
Option : Génie Mécanique
Date : juin 1978
Etablissement : IUT, Nantes
1981 MAITRISE DE TECHNOLOGIE DE CONSTRUCTION

Option : Construction et Fabrication
Mention : Bien (1er / 14)
Date : juin 1981
Etablissement : ENSM (Ecole Nationale Supérieure de Mécanique de
Nantes), actuellement ECN (Ecole Centrale de Nantes)
1983 DIPLÔME D'INGÉNIEUR

Date : juin 1983
Etablissement : ECN
1983 DEA
Mention : Bien
Date : octobre 1983
Etablissement : ECN
1986 DOCTORAT
Spécialité : Sciences de l'Ingénieur
Mention : Très Honorable
Date : 18 septembre 1986
Etablissement : ECN
Directeur de thèse : Professeur Félix LE MAITRE
Membres du jury : F. Le Maitre, J.M. Haudin, C. Bouchy, S.K. Marya,
E. El Koury
1992 CPIM de L’APICS

Diplôme : Certified In Production and Inventory Management
Date : novembre 1992
Etablissement : American Production and Inventory Control Society
3. FONCTIONS UNIVERSITAIRES OCCUPEES A L’ISSUE DU DOCTORAT
d’octobre 1986 à septembre 1988 :
Assistant Associé au département « Génie Mécanique et Productique »

Institut Universitaire de Technologie
Université de Nantes
depuis octobre 1988 :
Maître de Conférences au département « Organisation et Génie de la Production »

Institut Universitaire de Technologie d’Annecy-Le-Vieux
Université de Savoie
! "
L’activité d’un maître de conférence est soumise quotidiennement à des sollicitations
multiples et variées. Elle se concrétise dans trois principaux domaines :
• l’enseignement,
• la recherche,
• l’administration.
Par conséquent, nous proposons de structurer cette synthèse conformément à ces trois
domaines qui conduisent conjointement à un enrichissement mutuel des individus et des
structures, à une efficacité par l’exigence d’organisation, à l’équilibre par l’ouverture
intellectuelle et à la rigueur par le transfert des connaissances. Aussi, une liste des travaux et
publications est présentée à la fin de cette synthèse.
1. ACTIVITES PEDAGOGIQUES
Les structures universitaires technologiques telles que les Ecoles d’Ingénieurs, les Instituts
Universitaires de Technologie ainsi que les Instituts Universitaires Professionnalisés (mis en
place ces dernières années) sont par nature des structures d’enseignement ayant un profil de
formation à compétences générales et techniques assez larges. De ce fait, l’enseignant dans de
telles structures est souvent sollicité dans des disciplines diverses. De plus, l’entreprise étant
en évolution permanente dans différents domaines (technologique, gestionnaire, économique,
décisionnel...), l’enseignant se trouve dans l’obligation d’adapter en permanence ses
connaissances et donc les enseignements qu’il effectue aux besoins industriels réels.
Plus précisément, dans un tel contexte industriel, la plupart des disciplines de la productique
et plus généralement du génie industriel, sont émergentes et variées, reprenant à leur compte
des théories aussi bien orientales qu’occidentales (juste à temps, kanban, qualité totale,
planification des besoins et des capacités, pilotage d’atelier, simulation des flux physiques,
sûreté de fonctionnement, maintenance totale productive...) et plus généralement la
modélisation en entreprise, la gestion de projets... Elles nécessitent une mise à jour régulière.
De ce fait, l’investissement à apporter en pédagogie est relativement important aussi bien en
enseignement qu’en encadrement.
Par ailleurs, outre les actions purement scientifiques (conférences, publications, projets...) sur
lesquelles tout maître de conférences s’appuie pour mettre à jour ses enseignements, il est
d’autres types d’actions menées en parallèle allant dans ce sens. Aussi, avant d’aborder à
proprement parler, les activités d’enseignement, résumons dans un premier paragraphe
certaines de ces actions.
1.1. Actions à des fins pédagogiques

Les participations aux différentes manifestations résumées ci-dessous ont été nécessaires pour
l’aide à : la définition du contenu du programme CPN1 au département OGP2, l’équipement
du département en moyens et outils d’enseignements adéquats, la formation personnelle à des
nouvelles disciplines, la mise en place des nouveaux modules enseignés...
Année Manifestation Objectifs

1990 Ecole d’été d’automatique organisée par le Réflexions sur la recherche en
Laboratoire d’Automatique de Grenoble sur génie industriel en général et
le thème : modélisation et évaluation des l’évaluation des performances en
performances des SdPs3. particulier.
1991 Formation APICS4 aux modules : Obtention du certificat CPIM
1. Material Requirements Planning (MRP). (Certified in Production and
2. Capacity Planning (CP). Inventory Management) par
3. Production Activity Control (PAC). validation des modules cités.
4. Inventory Management (IM).
5. Master Planning (MP).
6. Just-In-Time (JIT).
7. Systems And Technologies (SAT).
1992 Journées pédagogiques nationales du Participation à la refonte du
département OGP à Nice. programme CPN.
1993 Stage de formation sur « Prodstar2 Enseignement de la GPAO.
Migration ».
Stage de formation sur « Tool Box et Enseignement de la GPAO.
Contrôle Flux Matières ».
Journées pédagogiques nationales du Réflexions sur l’utilisation des
département OGP à Agen. outils informatiques (GPAO,
Simulation, Ordonnancement...) en
OGP.
1994 Journées pédagogiques nationales du Organisation du programme CPN
département OGP à Belfort. en modules.
2000 Journées pédagogiques nationales du Réflexions sur la mise en place

département OGP à Agen. d’outils pédagogiques en
statistiques, mécanique et
logistique.
1
CPN – Comité Pédagogique National.
2
OGP – Organisation et Génie de la Production.
3
SdP – Système de Production.
4
APICS – American Production and Inventory Control Society.
!
1.2. Enseignements assurés de septembre 1985 à septembre 1988
Les enseignements regroupés dans le tableau ci-dessous ont été assurés d’une part, en dernière
année de thèse de doctorat (de septembre 1985 à septembre 1986) au titre de vacations, et
d’autre part, dans le cadre de ma fonction d’Assistant Associé au département Génie
Mécanique et Productique à l’IUT de Nantes (de septembre 1986 à septembre 1988).
Année Matière enseignée Etablissement et niveau Nature des

enseignements
1985 à 1988 Résistance des 1. Ecole Centrale de Nantes Travaux Dirigés et
Matériaux (Bac+5) Travaux Pratiques
2. ISITEM de Nantes (Bac+5)
3. Départements OGP et GMP
de l’IUT de Nantes (Bac+2)
1985 à 1986 Métallurgie 1. Ecole Centrale de Nantes Travaux Pratiques
(Bac+5)
2. ISITEM de Nantes (Bac+5)
1986 à 1988 Mécanique Départements OGP et GMP de Cours et Travaux
Générale l’IUT de Nantes (Bac+2) Dirigés
1986 à 1988 Automatismes Centres de Formation Continue et Travaux Dirigés et
CNAM, Nantes (Bac+3, +4). Travaux Pratiques
Durant cette période, il m’a été possible d’encadrer différentes réalisations « clé en main »
(travaux réalisés sur dossiers APIES de l'ANVAR) pour équiper le laboratoire de recherche
FORSEM (Laboratoire de FORmage Sans Enlèvement de Matière) dirigé par le professeur
Maurice Leroy. A titre d’exemple, citons les deux réalisations suivantes :
• un traceur automatique de grilles piloté par micro-ordinateur permettant l'étude
d'embouties par ondes de choc (mars 1987),
• une machine d'essais de caractérisations rhéologiques de composites sandwichs (mars
1988).
1.3. Enseignements assurés depuis octobre 1988

Durant ces dernières années, le site annecien de l’Université de Savoie a connu une expansion
importante. Il est passé de quelques centaines d’étudiants à quelques milliers. Des nouvelles
structures et filières d’enseignements ont vu le jour. Dans ce sens, l’implication du corps
enseignant a été absolument nécessaire sur l’ensemble du processus de mise en place
(préparation, démarrage, suivi...).
Ainsi, mes diverses activités pédagogiques et administratives (définition des programmes,

participation aux enseignements, aux conseils et aux tâches administratives...) couvrent une
partie importante de ces structures, notamment :
• l’IUT (Institut Universitaire de Technologie) particulièrement au département OGP,
• la FAST (Faculté Annecienne des Sciences et Techniques) avant l’ouverture de l’école
d’ingénieurs, puis l’ESIA (Ecole Supérieure d’Ingénieurs d’Annecy) principalement en
Option Productique,
• le DESS–A2I (Automatique et Informatique Industrielle), transformé en DESS–AGIP
(Automatique, Génie Informatique et Productique) depuis septembre 1999,
"
• l’ITII 2 Savoies (Institut des Techniques d’Ingénieur de l’Industrie des 2 Savoies),
• l’IUP/GSI (Institut Universitaire Professionnalisé – Génie des Systèmes Industriels),
• le SUFCEP (Service Universitaire de Formation Continue et d’Education Permanente),
• le CUEFA Annecy en formation du soir,
• le centre de formation par alternance TETRAS en TEQ (TEchnicien de la Qualité).
Outre la mise en place des enseignements fondamentaux inhérents à ma formation

universitaire d’origine (Mathématiques, Mécanique, Automatique...), l’émergence de ces
nouvelles structures a nécessité la mise en place d’enseignements nouveaux, à toutes les
étapes (définition du contenu, élaboration du cours et des travaux dirigés, achat de logiciels et
des maquettes pédagogiques pour assurer les travaux pratiques) et niveaux pédagogiques (1er
et 2ème cycles). Ces enseignements nouveaux concernent la gestion de production, la GPAO5,
la pratique des SdPs...
Dans ce contexte, les deux principaux enseignements qui ont suscité et suscitent encore mon
intérêt et ma motivation sont : « la modélisation et la simulation des SdPs » et « la sûreté de
fonctionnement des systèmes industriels ». En effet, chose curieuse, dès la mise en place de
ces enseignements, je me suis « senti » de développer une dynamique conjointe enseignement
– recherche dans cette thématique. Nous verrons plus tard combien les contextes industriel et
scientifique m’ont donné raison dans cette motivation.
• La modélisation et la simulation des SdPs peuvent être définies comme étant « un

processus de conception de modèle de système réel puis de conduite d’expériences avec
ce modèle pour appréhender le comportement du système réel et/ou évaluer différentes
stratégies de production de ce système ». Le processus de simulation comprend une
dizaine d’étapes : la formulation du problème et la définition des objectifs, l’analyse des
données, la modélisation, la vérification, la validation, l’expérimentation, l’analyse des
résultats, l’implémentation et la documentation. Donc, enseigner la simulation, c’est avoir
des compétences étendues aux SdPs, à l’informatique, à la modélisation, à la structuration
des expériences, aux statistiques... J’ai accompagné l’enseignement de cette discipline par
des travaux de recherche depuis au LLP/CESALP, et validés par de nombreux échanges
industriels.
• La sûreté de fonctionnement des systèmes industriels est définie au sens large comme
étant « la science des défaillances : analyse, mesure, traitement, modélisation,
prévention... ». Elle comprend différents paramètres tels que : la fiabilité, la
maintenabilité, la disponibilité, la maintenance, la sécurité, la maintenance totale
productive (TPM)... La sûreté de fonctionnement couvre toutes les étapes du cycle de vie
d’un système : conception, fabrication, exploitation. Pour ma part, je n’ai eu de cesse que
lorsque j’ai concrétisé ma perception de la sûreté de fonctionnement par le développement
de l’outil informatique ADONIS pour modéliser et caractériser la fiabilité pendant les
phases de fabrication et d’exploitation d’un système. Ce logiciel est utilisé en
enseignement et en projets scientifiques et industriels dans différentes structures (ESIA,
IUT, ITII...).
Le tableau ci-après résume les enseignements dispensés jusqu’à ce jour.
5
GPAO – Gestion de Production Assistée par Ordinateur.
#$
Matière enseignée Année Etablissement et niveau Volume annuel
Modélisation et Depuis 1988 Département OGP 10 H Cours,
simulation des SdPs (Bac+2) 12 H TD,
(Responsable de 36 H TP.
module) Depuis 1992 DESS – A2I et AGIP 14 H (Cours et TD),
(Bac+5) 16 H TP.
Depuis 1995 ITII 2 Savoies (Bac+5) 20 H (Cours, TD et TP).
Depuis 1999 IUP/GSI (Bac+4) 14 H (Cours et TD),
28 H TP.
Sûreté de Depuis 1992 Département OGP 2*22 H (Cours et TD),
fonctionnement des (Bac+2) 2*16 H TP.
systèmes industriels De 1995 à ESIA – Option 18 H (Cours et TD).
(Responsable) 1999 Productique (Bac+5)
Depuis 1995 ITII 2 Savoies (Bac+5) 28 H (Cours, TD et TP).
De 1997 à TETRAS – Technicien 32 H (Cours, TD et TP).
1999 de la Qualité (Bac+3)
En CUEFA (Bac+3) 84 H (Cours, TD et TP).
1988/1989
Bases de la mécanique Depuis 1988 Département OGP 18 H Cours,
(Responsable) (Bac+1) 22 H TD,
3*15 H TP.
En 1989 Département GMP 46 H TD.
(Bac+1)
Bases de l’automatique De 1988 à Département OGP 8 H Cours,
(Coresponsable) 1999 (Bac+1) 18 H TD.
Pratique des SdPs – Depuis 1994 Département OGP 4*28 H TP.
Automates (Bac+1)
programmables
(Coresponsable)
Mathématiques Depuis 1988 Département OGP 30 H TD.
(Analyse, Statistiques) (Bac+1)
Gestion de Production De 1988 à Département OGP 36 H TP.
Assistée par Ordinateur 1999 (Bac+2)
Mécanique vibratoire, Depuis 1992 CUEFA (Bac+4) 76 H (Cours et TD).
Mécanique des milieux
continus, mécanique
numérique
(Responsable)
Un encadrement permanent d’étudiants en stages en entreprises et en projets scientifiques ou

industriels complète les enseignements dispensés. Nous résumons dans le tableau ci-dessous
quelques projets encadrés au département OGP, à l’ESIA, à l’ITII 2 Savoies et à l’IUP/GSI.
#
Année Etablissement Sujet de projet Objectifs
et niveau
1989 OGP (Bac+2) - Diminution de la taille des lots chez Amélioration de la
DASSAULT. réactivité.
1990 OGP (Bac+2) - Suivi de production chez SOMFY et Formalisation des
chez BOSCH. documents production.
1991 OGP (Bac+2) - Réalisation d’une maquette Equipement du hall de
généralisée de gestion de production. productique et
- Modélisation et simulation de la utilisation en travaux
cellule flexible d’OGP. pratiques.
1992 OGP (Bac+2) - Mise en place d’une GPAO chez Planification du calcul
SALOMON. de besoins.
1993 OGP (Bac+2) - Modélisation et simulation d’une Validation des règles
cellule d’assemblage chez SOMFY. de travail.
- Utilisation des plans d’expérience Automatisation des
avec la simulation. expériences.
1994 OGP (Bac+2) - Enquête sur les essais de fiabilité Détermination des
dans les entreprises de la région. types d’essais utilisés.
1995 OGP (Bac+2) - Création de procédures de contrôle Amélioration de la
chez ERDEM. qualité.
1996 ESIA (Bac+5) - Modélisation et simulation d’une Validation d’une
ligne de production chez ALCATEL. gestion en kanban.
OGP (Bac+2) - Influence des règles de pilotage sur Mise en place d’un TP.
un carnet de commandes.
ITII 2 Savoies - Mise en place de la TPM (Totale Formalisation de
(Bac+5) Maintenance Productive). certains indicateurs.
1997 OGP (Bac+2) - Etude de faisabilité d’un mode de Réduction des
production chez PAB Sud-Est. changements de série.
- Influence de la variabilité des temps Application de la
opératoires dans un SdP. simulation.
- Influence de la date de lancement et Mise en place de TP.
des règles de priorité en production.
- Réalisation d’une étude de cas sur la
fiabilité.
1998 OGP (Bac+2) - La TPM : fondements et applications Approfondissement du
dans les entreprises de la région. cours.
- Etude des SdPs gérés par kanban.
- Le Kaizen : mise en place dans les
entreprises de la région.
ITII 2 Savoies - Mise en place d’une GMAO chez Planification de la
(Bac+5) l’entreprise DAV. maintenance.
1999 OGP (Bac+2) - Etude de la fiabilité opérationnelle Mise en place d’une
des remontées mécaniques des maintenance
ARAVIS – Société SATELC. préventive.
- Comparaison entre différents types Approfondissement du
de gestion : les charges, les cours.
contraintes, le kanban.
##
2000 IUP/GSI - Réalisation d’un fichier d’aide Aide en ligne du
(Bac+3 et +4) dynamique du logiciel ADONIS. logiciel en TP.
- Modélisation et simulation d’un Réimplantation d’un
atelier chez RECTIPHASE. atelier.
OGP (Bac+2) - Réalisation de jeux d’essais pour Utilisation du logiciel
caractériser la fiabilité en phases ADONIS en TP.
expérimentale et opérationnelle.
2001 IUP/GSI - Réalisation d’un fichier d’aide Aide en ligne du
(Bac+3 et +4) dynamique du logiciel ADONIS. logiciel en TP.
- Etude bibliographique sur la Intégration dans une
génération aléatoire des nombres. plate-forme de
- Modélisation UML6 et simulation.
programmation objets d’une plate- Réalisation d’une
forme de simulation. plate-forme.
- Couplage des réseaux de neurone Intégration en
avec la simulation. simulation.
OGP (Bac+2) - Programmation d’une base de Approfondissement
données ACCESS pour la gestion des cours et gestion des
anciens étudiants OGP. anciens OGP.
2. ACTIVITES DE RECHERCHE ET D’ENCADREMENT
Cette partie présente une synthèse des travaux réalisés dans le cadre de mes activités de
recherche depuis 1982. Elle est structurée selon trois principaux paragraphes :
• d’abord, les thématiques et les résultats obtenus,
• ensuite, les activités d’encadrement en DEA et en thèses de doctorat,
• et enfin les activités scientifiques nationales et internationales.
Mais, avant d’aborder ces parties, revenons sur l’intérêt et la motivation, à l’origine de ma
thématique de recherche actuelle abordée depuis 1988 au LLP/CESALP ainsi que sur la
finalité de ces travaux. Il est largement connu, que les systèmes continus jouissent d’un cadre
méthodologique et de modélisation rigoureux et formel depuis plusieurs années. Cet aspect
est jusqu’à présent plus difficile à cerner pour les systèmes discrets et plus particulièrement
les systèmes manufacturiers. Il nous paraît donc essentiel de rationaliser et d’améliorer la
conception et le pilotage des SdPs manufacturiers. C’est dans ce contexte que nous voulons
inscrire notre contribution scientifique qui porte sur l’amélioration des modèles de simulation
pour l’évaluation des performances et le pilotage des SdPs manufacturiers. L’amélioration du
pilotage des systèmes manufacturiers passe également par la réduction des aléas et des
incertitudes donc, l’amélioration de la fiabilité des ressources de production. Ainsi, certains
travaux s’inscrivent également dans l’amélioration des techniques de traitement des données
pour la sûreté de fonctionnement des systèmes.
6
UML – Unified Modeling Language.
#%
2.1. Les thématiques abordées et les résultats obtenus
D’abord, nous présentons les travaux concernant la thématique de « la fissuration de
solidification » dans les alliages d’aluminium et les aciers inoxydables abordés entre mars
1982 et septembre 1986, ensuite les travaux sur la thématique de « la plasticité dynamique »
réalisés par magnétoformage sur des matériaux hétérogènes entre octobre 1986 et septembre
1988, et enfin essentiellement les travaux effectués et actuels sur la thématique de « la
modélisation et la simulation des SdPs » depuis octobre 1988.
2.1.1. La fissuration de solidification (mars 1982 – septembre 1986)
Les travaux de recherche menés durant cette période, au Centre de Productique de l’Ecole
Nationale Supérieure de Mécanique de Nantes (actuellement ECN), dirigé par le professeur
Félix Le Maître, concernent principalement mon DEA et ma thèse de doctorat, en Génie
Mécanique (Sciences Pour l’Ingénieur). La thématique de ces travaux porte sur
l’appréhension des phénomènes de fissurations provoquées pendant la phase de solidification
de la matière, lors d’une opération de soudage TIG (Tungsten Inert Gas). Les matériaux
choisis pour nos applications et sujets à cette problématique sont à haute performance et
utilisés dans des domaines à sécurité élevée (aéronautique, nucléaire, chimique...). Ils
comprennent certains alliages d’aluminium et certains aciers inoxydables austénitiques.
Ainsi, le mémoire de DEA porte sur le « traitement informatique des isothermes, des
contraintes et déformations de soudage ». L’objectif de ce travail est d’implanter sur Mini 6
un programme de calcul à même de présenter sous forme graphique en temps réel les cycles
thermiques du soudage ainsi que les contraintes et les déformations transitoires et résiduelles
qu’engendre toute opération de soudage. La thèse de doctorat porte sur une « étude
métallurgique de la fissuration de solidification de quelques aciers inoxydables austénitiques
et de quelques alliages d’aluminium en relation avec les paramètres de soudage TIG ». Dans
cette thèse un nouvel essai de fissuration rectangulaire est validé et l’influence d’une nouvelle
forme de la tête de l’électrode est étudiée. Les observations, d’une part fractographiques et
d’autre part macrographiques, réalisées sur plusieurs éprouvettes montrent que les fissurations
se propagent en présence d’un film liquide situé aux joints des grains quand des tensions
internes dues au gradient thermique sont appliquées sur le matériau. Durant cette période,
trois publications internationales dans des revues avec comité de lecture et dans des congrès
avec actes, ont été réalisées.
2.1.2. La plasticité dynamique (octobre 1986 – septembre 1988)
Au Laboratoire FORSEM (Laboratoire de FORmage Sans Enlèvement de Matière), les

travaux de recherche de cette période ont été plus appliqués dans la mesure où ils s’orientaient
essentiellement vers le transfert technologique et l’équipement du laboratoire en moyens
expérimentaux dans le domaine de la mise en forme des matériaux. La nouvelle thématique,
partagée avec 2 professeurs, alors s’inscrit dans le domaine de « la plasticité dynamique » où
la déformation de la matière s’effectue par impact à très grande vitesse de déplacement.
Principalement deux méthodes sont utilisées au Laboratoire FORSEM : la formabilité des
matériaux par effet électromagnétique et la formabilité par effet électro-hydraulique.
Différentes applications en découlent, notamment : le plaquage, le sertissage, et la soudabilité
#
réalisée par impact, sous l'action de champs magnétiques intenses de certains matériaux
hétérogènes tels que le cuivre et l’aluminium (matériaux non soudables en utilisant des
procédés classiques à cause de la différence qui existe entre les températures de fusion des
deux matériaux).
Dans le domaine de la soudabilité à très grande vitesse des deux matériaux : aluminium et
cuivre, des résultats très intéressants sont obtenus. En effet, les expériences effectuées sur des
tubes d’aluminium plaqués par effet électromagnétique sur des axes en cuivre, aboutissent à la
réalisation d’une soudure épaisse de quelques microns, mais suffisamment solide pour tenir à
un test d’arrachement lamellaire. Toutefois, aucune publication n’est réalisée sur ces travaux
pour des raisons de confidentialité (en vue d’une déposition de brevets, de transferts
technologiques en industries). Aussi, d’autres travaux sont effectués sur la conception de
bobines multiples (en série et en parallèle) pour démontrer la faisabilité industrielle de la mise
en forme par magnétoformage et électroformage. Ces travaux conduisent à la proposition
d’un prototype de six bobines montées en série et validé par des essais de sertissage
d’embouts de fusibles dans le cadre d’un contrat industriel avec la société FERRAZ à Lyon.
2.1.3. La modélisation et la simulation des SdPs (depuis octobre 1988)
La simulation, science empirique, est utilisée depuis des siècles voire des millénaires à chaque
fois que la théorie montre ses limites face à la résolution de certains problèmes. C’est ainsi
que la princesse tyrienne Didon fondatrice de Carthage résolut son problème, en utilisant la
simulation. « Fugitive de Tyr après la mort du roi son père, elle aborda donc un jour avec ses
fidèles, aux rives du pays des Libyens. Hostiles à l’installation de nouveaux venus sur leur
territoire, les peuplades de la région finirent par consentir à la princesse tyrienne et aux
siens, une aumône dérisoire : autant de terre qu’en pourrait délimiter une peau de bœuf.
Didon les prit aux mots, elle fit découper en lanières très fines le cuir de bœuf qui
permettaient d’enclore un terrain très vaste. Ensuite, elle eut l’idée d’entourer une surface
côtoyant le bord de mer et utiliser ainsi le moins de lanières. Enfin, pour résoudre un
problème mathématique simple mais sans fondement théorique à l’époque, elle simula avec
sa ceinture de lin d’enclore des surfaces géométriques variées pour envelopper la plus
grande surface (un cercle), étant donné un périmètre fixe ». Ce n’est qu’au siècle dernier,
qu’un théorème a démontré qu’un cercle englobe une plus grande surface que n’importe
quelle autre figure de même périmètre. Nous sommes toujours en quête de meilleures
solutions, nous utilisons tous les méthodes et les techniques de l’optimum : démonstrations et
expérimentations en font partie. Malheureusement, tout n’est pas démontrable, la théorie peut
demander des siècles de réflexion et l’expérimentation n’est pas toujours possible. C’est ici
que se place comme suppléant de la démonstration et de l’expérimentation, la simulation.
La simulation est principalement une technique d’optimisation et d’aide à la prise de décision.

Dans ce domaine, des méthodes théoriques récentes ont été développées depuis la deuxième
guerre mondiale (recherche opérationnelle, réseaux de Petri, réseaux de files d’attente...).
Toutefois, l’optimisation des systèmes dynamiques reste relativement complexe, du fait de la
complexité des systèmes, d’une théorie existante limitée, et d’une expérimentation en
grandeur nature souvent impossible. Parallèlement aux fondements théoriques, la simulation
informatique (les expériences sont réalisées à l’aide d’un modèle informatique), alliant théorie
et expérimentation, a connu des avancées très importantes depuis que l’informatique et la
technologie des ordinateurs ont été exponentiellement développés.
#
Dès mon arrivée à l’Université de Savoie, et dans un environnement pédagogique orienté
génie industriel, le choix de mes activités de recherche se porte principalement sur cette
thématique nouvelle qu’est « la modélisation et la simulation des SdPs ». Ainsi, l’intégration
du LLP/CESALP (Laboratoire de Logiciels pour la Productique du CEntre des Sciences
Appliquées à la Production) est effective dès sa création en 1988 avec l’arrivée du professeur
Alain Haurat. Le choix de cette thématique s’est fait pour des raisons diverses, mais la plus
importante étant la motivation personnelle et l’opportunité d’animer et de développer une
activité au sein du LLP/CESALP sur une thématique en pleine émergence et nouvelle à
l’Université de Savoie. Nouvellement créée, et co-animée par le professeur Alain Courtois, la
nouvelle équipe a commencé assez rapidement à tisser des liens étroits dans un cadre
industriel demandeur. Les besoins se sont manifestés sur plusieurs aspects (aide à la
conception de lignes de production, aide à la validation de certaines règles de gestion, aide au
choix entre différentes alternatives d’organisation...). De manière progressive, ces travaux
nous ont permis de :
• cerner les besoins industriels particulièrement en simulation et plus généralement en génie
industriel,
• publier certains articles dans des revues et des conférences internationales,
• et par la même occasion, promouvoir le LLP/CESALP, valoriser et renforcer les travaux
de recherche d’une nouvelle équipe auprès des industriels de la région.
Après la restructuration des équipes du LLP/CESALP en 1999, « la modélisation et la

simulation des SdPs » est une sous-activité de l’équipe « conception et optimisation des
processus industriels ».
Le processus manufacturier d’un SdP est composé d’activités de natures différentes. D’une
part, il y a les activités de nature physique telles que le stockage, le transfert, la
transformation, le contrôle... qui peuvent être groupées dans un processus de fabrication.
D’autre part, il y a les activités de nature logique (décisionnelle) telles que l’ordonnancement,
la définition de règles de priorité, la réaction à une perturbation, la programmation d’une
action préventive ou corrective... qui peuvent être groupées dans un processus de pilotage.
Simuler le processus manufacturier d’un SdP, c’est donc, simuler à la fois son processus de
fabrication et son processus de pilotage.
Face à une simulation réservée aux seuls spécialistes par manque de méthodologie et de
concepts accessibles à un utilisateur potentiel, et réductrice par manque de concepts capables
de modéliser le processus de pilotage, nos travaux de recherche se sont inscrits dans ce cadre
depuis plusieurs années. Ainsi, des concepts génériques ont été proposés pour la modélisation
du processus de fabrication en vue de sa simulation (thèse de Mohammed Bakalem), et
actuellement nous travaillons sur la finalisation des concepts génériques proposés pour la
modélisation du processus de pilotage en vue de simuler le processus manufacturier dans sa
globalité (thèse de Claire Berchet).
Dans le cadre de notre recherche, nous nous sommes particulièrement intéressés au problème
de la simulation de façon à pallier : le manque de méthodologie et de concepts accessibles aux
utilisateurs potentiels, la difficulté de réutiliser les modèles et les concepts existants, la
difficulté d’affiner des modèles existants sans les refaire entièrement, la non-prise en compte
du système de pilotage en tant que système à part entière, la modularité, la flexibilité...
L’approche proposée est fondée sur l’analyse des SdPs selon la perception qu’en ont les
utilisateurs potentiels dans une optique de simulation. Aussi, sur la base de cette analyse, nous
#
avons posé les premières hypothèses permettant de définir un concept standard et original
dénommé STP (Système de Transformation du Produit). Le STP est un processeur
présentant trois propriétés essentielles. La première est d'être un atome universel permettant
de construire tous les modèles, en regroupant la cascade naturelle des trois opérations d'une
ressource de production : la réception, la transformation et la fourniture. La deuxième
propriété est de synthétiser à la fois la ressource physique et son comportement. La troisième
propriété, la plus originale, est d'être une structure récursive permettant de développer des
modèles à différents niveaux hiérarchiques et d'abstraction. Cette propriété permet de pallier
le problème d'affinement progressif à la fois du comportement et du pilotage d'une ressource
de production. Suite à l'introduction du concept de STP permettant de représenter la ressource
de production, nous proposons une approche de modélisation articulée autour de trois
directions principales : une décomposition hiérarchique des systèmes manufacturiers en
cinq niveaux visant l'aspect statique et structurel de la modélisation, une formalisation par
graphes d'état en quatre niveaux d'abstraction et concernant les aspects fonctionnels, une
définition des horizons ou objectifs de la simulation conformément au cycle de vie d'un
système manufacturier et permettant de situer le degré d'affinement du modèle. L'évolution
comportementale d'une ressource de production a été prise en compte par l’introduction du
scénario qui traduit l’interaction de chaque STP avec les autres dans un environnement
donné. Le caractère générique du STP et son graphe d’état associé nous permet de proposer
des scénarii standards pour un niveau hiérarchique déterminé. La mise en œuvre de cette
approche de conceptualisation a été réalisée par le développement d'un modèle objet en
s'appuyant sur le langage UML. Pour valider l’approche, une 1ère implémentation a été réalisée
en utilisant le langage MODSIM II qui fournit à la fois un moteur de simulation discrète et des
fonctionnalités objet souples et complètes. Ces travaux ont donné lieu à la publication de
plusieurs articles ainsi qu’à la soutenance de thèse de Mohammed Bakalem en juillet 1996
avec la mention très honorable.
Conformément aux objectifs fixés précédemment, les préoccupations de notre équipe se sont
portées par la suite sur la modélisation et la formalisation du processus de pilotage d’un
système industriel, en vue de son intégration à l’approche de simulation adoptée. Suite au
choix d’une structure de pilotage coordonnée et hiérarchisée, une typologie de pilotage selon
la réactivité a été proposée. Cette typologie comprend les trois types suivants : le pilotage a
priori, le pilotage réactif pour anticipation et le pilotage a posteriori. Une unité de pilotage
baptisée CP (Centre de Pilotage) a été conceptualisée et modélisée. Le CP a été défini
comme étant : une structure autonome, mais dépendante de la stratégie globale de
l’entreprise, ayant un pouvoir décisionnel, associée à une entité à piloter et disposant d’un
ensemble de moyens nécessaires à la mise en place d’actions pour atteindre un ou plusieurs
objectifs définis dans le cadre global de l’entreprise. Le CP possède les composantes
suivantes : des acteurs décideurs, des référents, des objectifs, des informations endogènes et
exogènes, des outils d’aide à la décision, des outils d’évaluation et des ressources pour la mise
en place d’actions. Nous abordons également une typologie des liens existants entre CPs ainsi
que le processus de comportement interne. Deux types de structures ont été définis : la
structure globale qui organise les CPs entre eux selon trois axes (hiérarchie, temps et espace)
et la structure locale qui organise de façon macroscopique les trois types de pilotage autour
du système à piloter. Ces travaux complètent de manière structurée et homogène les travaux
précédents sur la modélisation et la simulation à l’aide du concept STP. Ils se sont concrétisés
par la thèse de Claire Berchet en contrat CIFRE avec l’entreprise CIT-ALCATEL à Annecy et
soutenue en décembre 2000 avec la mention très honorable. Nous travaillons actuellement sur
l’implémentation de ces concepts dans une plate-forme dénommée APOLLO, en utilisant le
langage JAVA après spécification à l’aide du langage UML. Cette implémentation devra nous
#&
permettre, dans une première étape, d’intégrer le processus de pilotage dans la simulation à un
niveau opérationnel. Notre approche s’est enrichie de manière continue, dans le cadre du
contrat CIFRE et du projet international CORIS à CIT-ALCATEL, qui a combiné l’évolution
des principaux processus de l’entreprise et la mise en place d’un ERP pour un nouveau
système d’aide à la décision (R3 de SAP).
D’autres travaux plus spécifiques, collectifs ou personnels (encadrements de DEA), sont aussi
réalisés. Ils concernent la simulation de certains systèmes manufacturiers pour : étudier
l'influence de la taille des lots dans une production job-shop, intégrer au modèle informatique
un plan d'expériences fractionnaire, optimiser un programme de production, étudier
l’influence de la variabilité des temps opératoires sur une production en ligne. La première
étude par exemple, a montré que le paramètre « taille des lots » agit sur le système de manière
complexe, joue un rôle essentiel sur l’utilisation du système et conditionne le délai client
(l’évolution n’est pas affine).
Aussi, certains travaux de recherche actuellement personnels sont réalisés sur la thématique
de « la sûreté de fonctionnement » des systèmes et produits et particulièrement sur la fiabilité.
Ainsi, dans le cadre des méthodes d’exploitation des essais suspendus, une nouvelle méthode
pour l’évaluation de la fiabilité expérimentale est proposée. Elle permet de calculer
l’incrément, différent de « 1 » dans le cas où un produit serait suspendu avant défaillance, et
ainsi estimer la défaillance des produits défaillants. En prenant la méthode de l’actuariat
comme référence, cette méthode a montré, dans 80% des cas testés, des résultats meilleurs
que ceux trouvés par les méthodes du « taux de hasard cumulé » et de « Johnson ». Aussi,
pour caractériser et évaluer la fiabilité des produits et systèmes, d’une part, dans leur phase de
fabrication et d’autre part, dans leur phase d’exploitation, le logiciel ADONIS a été développé.
A partir de données concernant les dates de défaillances ou les TBF (Temps de Bon
Fonctionnement) des systèmes (en fabrication ou en utilisation), et à l’aide de différentes
méthodes et techniques d’exploitation (actuariat, rangs moyens, rangs médians, Johnson, taux
du hasard cumulé, mort soudaine...), ce logiciel propose un modèle de fiabilité théorique sur
la base des distributions : exponentielle, normale et de Weibull. La caractérisation de la
fiabilité du système ou du produit concerné est déduite à partir du modèle retenu et de ses
paramètres déduits de l’exploitation des données. Dans un but de cohérence et pour modéliser
les défaillances qui surviendraient sur une ressource de production, il est prévu d’intégrer le
logiciel ADONIS à la plate-forme APOLLO.
La valorisation de nos recherches dans le milieu industriel s'effectue par :
• une participation au projet SIMPROD – SIMulation en PRODuction pour optimiser le

flux physique dans les ateliers en PMI/PME – de septembre 95 à septembre 96. Ce projet
est une collaboration du LLP/CESALP avec le Centre Technique du Décolletage
(CTDEC), l'entreprise 1P2 (Lyon) et le Centre Productique Haute-Savoie (CPHS).
• une collaboration étroite avec bon nombre d’industriels de la région Rhône-Alpes ou
Européens (NEYR, TEFAL, DAV, CIT-ALCATEL, SOMFY, STAUBLI, SNR,
RECTIPHASE...), qui, en nous soumettant certains de leurs problèmes (conception
d’ateliers, dimensionnement de systèmes de transfert, modification de la gestion...) nous
ont permis de valider nos approches.
• une collaboration avec l’entreprise CIT-ALCATEL dans le cadre du projet international
CORIS et de la thèse de doctorat de Claire Berchet en contrat CIFRE.
#!
Les perspectives envisagées pour nos travaux futurs portent sur :
• une collaboration universitaire autour du thème de la simulation avec le Laboratoire de

Logiciels Systèmes et Réseaux, Institut de Mathématiques Appliquées de Grenoble
(LSR/IMAG), ayant pour objet l’utilisation des concepts de frames et de patterns tels
qu’ils sont perçus en informatique pour les problématiques génie industriel,
• l’introduction des systèmes multi-agents pour la modélisation du système de pilotage,
• l’élaboration d'une bibliothèque de primitives de modélisation standardisées et dédiées à
la simulation des flux manufacturiers basées sur l’approche proposée,
• le traitement du problème d’agrégation et de désagrégation de l'information entre les
différents niveaux hiérarchiques,
• la génération automatisée de processus de simulation et l’intégration à la simulation de
certains outils et techniques tels que les plans d'expériences, les outils d'ordonnancement,
les outils d’aide à la décision...
2.2. Activités d’encadrement
2.2.1. Encadrements et co-encadrements de DEA
2.2.1.1. La fissuration de solidification (octobre 1983 – septembre 1986)
Co-encadrement avec le professeur S.K. MARYA et participation aux jurys de 2 DEA.
Année Sujet DEA Laboratoire d’accueil

et Université
1984/85 La mesure de la ferrite par méthodes magnétiques dans Centre de Productique
les cordons de soudures d'aciers inoxydables – ECN
austénitiques.
1985/86 La soudabilité des alliages de titane par procédé MIG. Centre de Productique
– ECN
2.2.1.2. La plasticité dynamique (octobre 1986 – septembre 1988)
Co-encadrement avec le professeur Maurice LEROY et participation au jury d’1 DEA.
Année Nom Sujet DEA Laboratoire d’accueil

et Université
1987/88 Koffi SOSSOU L'aspect énergétique en mise en forme Laboratoire FORSEM
des métaux par impulsions électriques. – ECN
#"
2.2.1.3. La modélisation et la simulation des SdPs (depuis oct. 1988)
Encadrement et participation à des jurys de DEA :

et Université
1993/94 Christophe L’étude de l'influence de la taille des LLP/CESALP – ESIA
LABRUNE lots sur la production d’un atelier job Université de Savoie
shop.
1994/95 Philippe Une démarche d’intégration des plans LLP/CESALP – ESIA

CARBONNE d’expérience et des systèmes experts à Université de Savoie
la simulation des SdPs manufacturiers.
1995/96 Prève L’intégration informatique des plans LLP/CESALP – ESIA

SÉNÉCLAUZE d’expérience avec la simulation d’un ENSGI – Grenoble
atelier job-shop.
1997/98 Claire La conception d’un système LLP/CESALP – ESIA

BERCHET d’indicateurs en vue de l’intégration INSA de Lyon
dans un modèle de simulation.
2000/01 Jean-Noël Modélisation avec UML et LLP/CESALP – ESIA

CHARPIN implémentation sur JAVA de la plate- Université de Savoie
forme Apollo pour la simulation.
2001/02 Laetitia Recherche d’une méthodologie de LLP/CESALP – ESIA

REVEL processus d’optimisation des flux de ENSGI – Grenoble
production et validation par simulation
2001/02 Benjamin Modélisation avec UML et LLP/CESALP – ESIA

GATEAU implémentation sur JAVA du Centre de Université de Savoie
Pilotage pour la simulation.
Participation à des jurys de DEA :

et Université
1994/95 Emmanuel Méthodes de traitement du signal LLP/CESALP – ESIA
DUCLOS appliquées à la maîtrise statistique des – Université de Savoie
procédés.
1995/96 Tarek Utilisation du fonctionnement LAMII/CESALP –

KASMIEH périodique pour la macro modélisation ESIA – Université de
et la commande des systèmes à Savoie
événements discrets.
%$
2.2.2. Encadrement de thèses de doctorat en modélisation et simulation
Co-encadrement avec le professeur Alain Courtois (mon taux d’encadrement pour chacune
des deux thèses peut être évalué à environ 85%) :
Année Nom Sujet de thèse – date de soutenance – Laboratoire d’accueil

spécialité – mention – jury et Université
1992 - Mohammed Sujet : modélisation et simulation LLP/CESALP – ESIA
1996 BAKALEM orientées objet des systèmes de – Université de Savoie
production manufacturiers.
Date soutenance : le 04-07-1996.
Spécialité : électronique –
électrotechnique – automatique.
Mention : très honorable.
Jury : Pierre Ladet, Jean-Paul Kieffer,
Jean-Pierre Pécuchet, Joël Favrel,
Alain Courtois, Georges Habchi.
1997 - Claire Sujet : modélisation pour la simulation LLP/CESALP – INP

2000 BERCHET d’un système d’aide au pilotage de Grenoble
industriel.
Date soutenance : le 21-12-2000.
Spécialité : génie industriel.
Mention : très honorable.
Jury : Bernard Grabot, François
Vernadat, Jean-Robert Compérat,
Pierre Ladet, Alain Courtois,
Georges Habchi.
M. Bakalem est depuis septembre 1996 enseignant chercheur à Alger.

C. Berchet est depuis janvier 2001 chef de projet à Alcatel Annecy.
%
2.3. Activités scientifiques nationales et internationales
• Reviewer pour la revue « Simulation », International Journal of SCSI7, San Diego –
USA, juin 1996.
• Président de session à la 1ère Conférence Francophone de MOdélisation et SIMulation
(MOSIM’97), organisée par l’INSA de Rouen les 5 et 6 juin 1997.
• Président du comité d’organisation, membre du comité scientifique, reviewer et
président de session de la conférence MOSIM’99, organisée par le LLP/CESALP à
Annecy du 6 au 8 oct. 1999.
• Coéditeur des actes de la conférence MOSIM’99.
• Organisateur et membre de la commission de sélection de l’organisateur de
MOSIM’01 (Sélection de l’Université Technologique de Troyes).
• Membre du comité scientifique, reviewer et président de session de FOODSIM’00,
International Conference on Simulation in Food and BioIndustries, conférence SCSI
organisée par l’ENITIAA à Nantes du 26 au 27 juin 2000.
• Membre du comité d’organisation des journées GRP’20008 organisées par le
LLP/CESALP à Annecy les 23 et 24 mars 2000.
• Reviewer de la 2ème Conférence Internationale MCPL’2000 (IFAC/IFIP/IEEE –
International Federation of Automatic Control), Management and Control of
Production and Logistics, organisée par le LAG à Grenoble du 5 au 8 juillet 2000.
• Membre du comité d’organisation, membre du comité scientifique et co-président de
session de la conférence QUALITA’2001 – Qualité et Sûreté de Fonctionnement –
organisée par le LLP/CESALP à Annecy les 22 et 23 mars 2001.
• Editeur invité d’un numéro spécial de la revue internationale SIMPRA portant sur 4
articles sélectionnés de la conférence MOSIM’99 (vol.8, n°5, décembre 2000).
• Proposition d’un numéro spécial pour la revue française RFGI portant sur 4 articles
sélectionnés par le comité scientifique de la conférence MOSIM’99 (un seul article a été
retenu par la revue RFGI pour manque d’application industrielle).
• Membre du comité scientifique, reviewer et président de session de la conférence
MOSIM’01 organisée par l’Université Technologique de Troyes du 25 au 27 avril 2001.
• Expert de projet en génie industriel/productique pour le Plan Productique Régional –
Pays de la Loire 2000 (septembre 2000).
• Membre du comité de sélection de l’organisme organisateur (Irlande) de FOODSIM’02,
2nd International Conference on Simulation in Food and BioIndustries.
• Reviewer pour la revue « Computers & Industrial Engineering », An International
Journal, Pergamon Press, Publishers, janvier 2001.
• Reviewer pour la revue « JESA », Journal Européen des Systèmes Automatisés, Hermès
Science Publications, avril 2001.
• Président de session à la conférence internationale GI’2001 organisée par l’IUSPIM et
l’ENSAM à Aix-Marseille du 12 au 15 juin 2001.
• Editeur invité d’un numéro spécial de la revue internationale SIMPRA portant sur 7
articles sélectionnés de la conférence MOSIM’01 à Troyes (numéro prévu pou décembre
2001).
7
SCSI – The Society for Computer Simulation International.
8
GRP – Groupement pour la Recherche en Productique.
%#
3. ACTIVITES ADMINISTRATIVES ET RESPONSABILITES D’INTERET
COLLECTIF
La fonction de maître de conférences induit assez naturellement une participation à la vie

collective des structures d’accueil (unité d’enseignement et laboratoire de recherche). Pour ma
part, cette participation s’est manifestée à travers une demande (et une élection)
d’appartenance à divers conseils et commissions. Elle s’est également concrétisée par la prise
de responsabilités pédagogiques. Ces activités peuvent paraître « ingrates », au premier abord,
mais elles sont nécessaires à l’épanouissement professionnel des individualités et donc de la
structure. Les paragraphes ci-après résument l’essentiel de ces activités.
3.1. Conseils et commissions

Année Conseil ou Commission Etablissement
De 1993 à 1997 Membre élu au Conseil ESIA – Ecole Supérieure
De 1997 à 2000 d’Administration. d’Ingénieurs d’Annecy
De 1995 à 1998 Membre élu à la Commission des Université de Savoie

Spécialistes 60-62 (vice-président du
collège des MCF.)
De 1998 à 2000 Membre élu à la Commission des Université de Savoie
Spécialistes 60-62.
Depuis 1997 Membre élu au Conseil du laboratoire LLP/CESALP (Laboratoire de

LLP/CESALP. Logiciels pour la Productique /
CEntre des Sciences Appliquées
à la Production) – ESIA
De 1995 à 1996 Membre élu au Conseil Pédagogique. Département OGP – IUT

Annecy
De 1990 à 1995 Elu président de la Commission IUT – Annecy

« Qualité de la Vie ». Commission
créée sur l’initiative du professeur
Dominique PACCARD, directeur de
l’IUT, pour veiller à l’harmonisation et
à l’amélioration continue de la qualité
de vie du personnel de l’IUT
(étudiants, enseignants et personnel
administratif).
%%
3.2. Responsabilités administratives
Rappelons qu’à mon arrivée à l’IUT d’Annecy, le département OGP, nouvellement créé, était
le 2ème en France après celui de Nantes. L’investissement à apporter en pédagogie et
promotion a été de ce fait important.
Année Responsabilité Etablissement
1988/1989 Secrétaire de l’Association ProGection IUT Annecy – département OGP

(PROmotion de la GEstion de
produCTION : association dont les
activités sont orientées vers des
échanges entre industriels,
universitaires et étudiants dans le
domaine de la gestion industrielle).
De 1988 à 1991 Directeur des stages et des projets Département OGP / 2ème année
De 1991 à 1994 Directeur des études Département OGP / 2ème année
Depuis 1995 Responsable de l’insertion Département OGP / 2ème année

professionnelle des étudiants OGP.
Responsable de la cellule emploi du
département de 1995 à 1999.
Responsable du suivi des anciens
étudiants depuis 1995.
%
4. LISTE DES TRAVAUX, PUBLICATIONS ET DEVELOPPEMENTS
4.1. Mémoires de DEA et de thèse de doctorat

[1.] 1983 G. HABCHI
Traitement Informatique des Isothermes, des Contraintes et Déformations de Soudage.
DEA soutenu en octobre 1983 à l’Ecole Centrale de Nantes.
[2.] 1986 G. HABCHI

Etude Métallurgique de la Fissuration de Solidification de Quelques Aciers Inoxydables
Austénitiques et de Quelques Alliages d'Aluminium en Relation avec les Paramètres de Soudage
T.I.G.
Thèse de doctorat soutenue en septembre 1986 à l’Ecole Centrale de Nantes.
4.2. Ouvrage
[3.] 1999 G. HABCHI et A. HAURAT
Modélisation et Simulation des Flux Physiques et Informationnels.
Editeurs des Actes de la 2ème Conférence Francophone de MOdélisation et SIMulation,
MOSIM’99, 6-8 octobre 1999. SCS Publication. ISBN 1-56555-176-1.
4.3. Revues spécialisées

[4.] 1986 G. HABCHI and S.K. MARYA
Effect of Electrode Geometry on the Weld Solidification Cracking of Two Stainless Steels in
G.T.A Welding.
Scripta Metallurgica USA, 1986, Vol. 20, n°2, pp. 207-212.
[5.] 1992 G. HABCHI and F. DELOULE

Study of Modeling and Simulation for a Chemical Production System.
Simulation, Vol. 58, Number 6, June 1992, pp. 366-374. Simulation Councils, Inc. Society for
Computer Simulation International, California, USA.
[6.] 1995 G. HABCHI and C. LABRUNE

Study of Lot Sizes on Job-Shop Systems Performance Using Simulation.
Simulation Practice and Theory Journal (SIMPRA), Elsevier, 2 (1995) pp. 277-289.
[7.] 1999 G. HABCHI et C. BERCHET

Le Pilotage Industriel : Concepts de Base pour une Approche Intégrée.
Revue Française de Gestion Industrielle (RFGI), Vol. 18, N° 2, 1999, pp. 55-72.
[8.] 2000 G. HABCHI

Modelling and Simulation of Complex Production Systems.
Editorial, Special Issue of SIMPRA, vol. 8, n° 5, December 2000.
Guest Editor – Selected Papers from the 2nd French Conference on MOdelling and SIMulation.
[9.] 2001 G. HABCHI

An Improved Method of Reliability Assessment for Suspended Tests.
Article accepté pour publication dans la revue internationale IJQRM – International Journal of
Quality & Reliability Management (à paraître).
%
[10.] 2001 G. HABCHI and C. BERCHET
A Model for Manufacturing Systems Simulation Integrating a Control Dimension.
Article sélectionné de la conférence MOSIM’01 pour un numéro spécial de SIMPRA prévu pour
décembre 2001.
4.4. Article invité (régional)

[11.] 1997 G. HABCHI
Simulation de flux.
Article invité, Pôle infos, Spécial progiciels’97, septembre 1997, n°50, 1997.
4.5. Congrès avec comité de lecture et actes

[12.] 1984 S.K. MARYA, G. HABCHI and F. LE MAITRE
Comparative Study of Solidification Cracking in Aluminum Alloys in Relation with
Macrostructures in T.I.G. Welding.
International Conference on Quality and Reliability in Welding, September 1984, Hangzhou
CHINA, Vol. 2, pp. B12 (1-6).
[13.] 1990 G. HABCHI and S.K. MARYA

Effect of Some G.T.A.W. Process Parameters on the Solidification Cracking of 304, 316L and
310 Stainless Steels.
5th International Symposium on Advanced Technology in Welding, Materials Processing and
Evaluation, April 17-19, 1990. Nippon Convention Center, Makuhari, Tokyo, JAPAN.
[14.] 1993 G. HABCHI and M. BAKALEM

A Dynamic Study Using Simulation to Well-Balance an Assembling Transfer Line.
SIMTEC’93, 1993 International Simulation Technology Conference, San Francisco, November
7-10, 1993, California – USA, pp. 132-137. SCS Publication. ISBN 1-56555-060-9.
[15.] 1994 M. BAKALEM, G. HABCHI and A. COURTOIS

An Object Oriented Approach for Production Systems Modelling.
ESM’94, European Simulation Multiconference, Barcelona, Spain, June 1-3, 1994, pp. 375-380.
SCS Publication. ISBN 1-56555-028-5.
[16.] 1994 G. HABCHI, M. BAKALEM and A. COURTOIS

The PPS: A Processor Object for Modelling and Simulation of Manufacturing Systems.
CISS’94, First Joint Conference of International Simulation Societies, ETH Zurich, Switzerland,
August 22-25, 1994, pp. 515-519. SCS Publication. ISBN 1-56555-031-5.

PPS: An Integrated Object Approach for Modeling and Simulation of Manufacturing Systems.
IEEE, SMC’94 International Conference on Systems, Man and Cybernetics, San Antonio, Texas,
USA, October 2-5, 1994, pp. 2184-2189. ISBN 0-7803-2130-8.

PPS: A Contribution for Manufacturing Systems Simulation.
SCSC’95, 1995 Summer Computer Simulation Conference, Ottawa, Ontario, CANADA, July
24-26, 1995, pp. 390-395. SCS Publication. ISBN 1-56555-081-1.
[19.] 1995 M. BAKALEM, R. DINDELEUX, G. HABCHI and A. HAURAT

Integrated Simulation Modelling Approach for Hierarchical and Multicriteria Control Model.
ESC’95, Eurosim Simulation Congress, Vienna, AUSTRIA, September 11-15, 1995.
%
[20.] 1995 R. GUETARI, M. BAKALEM and G. HABCHI
An Object Model for Simulation of Manufacturing Systems.
IEEE, SMC’95 International Conference on Systems, Man and Cybernetics, Vancouver,
CANADA, October 5-7, 1995.
[21.] 1996 G. HABCHI and P. SENECLAUZE

Computer Integration of Fractional Experimental Designs and Job Shop System Simulation.
SMC’96 SIMULATION MULTICONFERENCE, New Orleans, Louisiana, USA, April 8-11,
1996, pp. 117-122. SCS Publication. ISBN 1-56555-092-7.

Conceptual Frames for Physical and Control Systems Modelling in Manufacturing Simulation.
ESS’96 – 8th European Simulation Symposium, Genoa, Italy, October 24-26, 1996, pp. 319-323.
SCS Publication, ISBN 1-56555-099-4
[23.] 1997 G. HABCHI

La Simulation et la Conduite des Systèmes Manufacturiers – Optimisation d’un Programme de
Production.
MOSIM’97, Modélisation et Simulation des Systèmes de Production et de Logistique, Rouen,
France, 5-6 juin 1997, pp. 221-228. Edition Hermès. ISBN 2-86601-623-8.
[24.] 1998 G. HABCHI, M. BAKALEM and A. COURTOIS

Object Oriented Modeling and Simulation of Manufacturing Systems.
WMC’98, 1998 Western MultiConference, OOS’98, Object-Oriented Simulation Conference,
San Diego, USA, January 11-14, 1998, pp. 151-156.
[25.] 1998 G. HABCHI

Study of the Effects of Process Time Variability on the Production Flow of a Manufacturing
System.
ASTC’98, 1998 Advanced Simulation Technologies Conference, Boston, USA, April 5-9, 1998,
pp. 221-226. SCS Publication. ISBN 1-56555-144-3.
[26.] 1999 C. BERCHET, G.HABCHI, A. COURTOIS

Pilotage et Prise de Décision Industrielle.
3ème Congrès International de Génie Industriel, Montréal, Québec, 25-28 mai 1999, pp. 1955-
1964. ISBN 2-553-00733-7.
[27.] 1999 G. HABCHI and C. BERCHET

Some Concepts for Industrial Control Process Modelling.
DSI’99, 5th International Conference, Athens - Greece, July 4-7, 1999, Volume I, pp. 777-779.
New Technologies Publications. ISBN 0-9667118-1-5.
[28.] 1999 C. BERCHET, G. HABCHI, A. COURTOIS

Intégration du Processus de Pilotage à la Simulation des systèmes de production.
MOSIM’99, 2ème Conférence Francophone de MOdélisation et SIMulation, Annecy – France, 6-8
octobre, 1999, pp. 337-343. SCS Publication. ISBN 1-56555-176-1.
[29.] 2000 C. BERCHET, G. HABCHI

Modeling for Simulation of Manufacturing Systems Control.
EDA’2000, 4th International Conference on Engineering Design and Automation, Orlando –
Florida USA, July 30 – August 2, 2000.
[30.] 2000 C. BERCHET, G. HABCHI

The Control Centre: a Basic Concept for Modelling and Simulation of Industrial Control.
ASI’2000, the annual Conference of ICIMS – NOE, supported by the Commission of EC, DGIII.
Bordeaux, France, September 18 – 20, 2000.
%&
[31.] 2001 Georges HABCHI
Modélisation de la Fiabilité dans le Cas d’un Essai Suspendu – Proposition d’une Nouvelle
Méthode Probabiliste.
QUALITA’2001, 4ème Congrès International Pluridisciplinaire Qualité et Sûreté de
Fonctionnement, Annecy – France, 22-23 mars 2001, pp. 425-432. ISBN 2-9516453-0-9.
[32.] 2001 Claire BERCHET, Georges HABCHI

Formalisation du Centre de Pilotage pour la Simulation des Systèmes Industriels.
MOSIM’01, 3ème Conférence Francophone de MOdélisation et SIMulation, Troyes – France, 25-
27 avril 2001, pp. 451-457. SCS Publication. ISBN 1-56555-212-1.
(Cet article a reçu le prix jeune chercheur de la conférence et a été sélectionné pour être
publié dans un numéro spécial de SIMPRA).
[33.] 2001 Georges HABCHI

La Simulation Informatique en Génie Industriel : Etat de l’Art Actuel.
4ème Congrès International de Génie Industriel, Aix-Marseille – France, 12-15 juin 2001, pp. 685-
697. ISBN 2-9517004-0-7/5/3.
4.6. Workshop et manifestations nationales

[34.] 1994 G. HABCHI
Material and Capacity Requirements Planning.
International Item Writing Workshop (ETS) – Paris, France, September 19-20, 1994.
[35.] 2000 C. BERCHET, G. HABCHI, A. COURTOIS

Conception d’un Système d’Aide au Pilotage Industriel.
GRP’00, Journées du Groupement pour la Recherche en Productique, Annecy – France, 23-24
mars, 2000.
4.7. Rapports de synthèse et de fin de contrats industriels

[36.] 1988 G. HABCHI et P. LAGARRIGUE
Introduction aux Matériaux Composites – Constituants et Mise en Oeuvre.
Rapport de synthèse pédagogique, IUT – ISITEM Nantes, mars 1988.
[37.] 1988 G. HABCHI et M. LEROY

Etude de Faisabilité Industrielle de Sertissages Etanches, de Bagues de Faible Diamètre en
Alliages de Cuivre et d'Aluminium sur Corps Creux en Céramique par Magnéto-Formage.
Rapport de fin de contrat industriel, mars 1988.
Partenaires : Société FERRAZ (Lyon), Laboratoire FORSEM – ENSM (Nantes).
Durée : 6 mois – Budget : 40 KF.
[38.] 1989 G. HABCHI, A. COURTOIS et M. PILLET

Etude d’une Mise en Ligne de Fabrication Manufacturière en Production Poussée et en
Production Tirée.
Rapport de fin de contrat industriel, juin 1989.
Partenaires : Société STAUBLI (Faverges), LLP/CESALP – ESIA (Annecy).
[39.] 1989 G. HABCHI et A. COURTOIS

Etude de Dimensionnement et de Gestion de Flux d'une Cellule d'Assemblage.
Rapport de fin de contrat industriel, octobre 1989.
Partenaires : Société SOMFY (Cluses), LLP/CESALP – ESIA (Annecy).
%!
[40.] 1992 G. HABCHI
Etude Dynamique de Gestion des Ressources et des Files d'Attente pour Equilibrer la Charge et
Optimiser le Flux d'une Ligne de Production.
Rapport de fin de contrat industriel, juin 1992.
Partenaires : Société SOMFY (Cluses), LLP/CESALP – ESIA (Annecy).
[41.] 2000 G. HABCHI

Projet N7 : Modélisation et Simulation des Lignes de Production et des Moyens de Transport
chez NEYR Plastiques.
Rapport de fin de contrat industriel, juillet 2000.
Partenaires : Société NEYR Plastiques (Espagne), LLP/CESALP – ESIA (Annecy).
4.8. Projets Université/Industrie

[42.] 1990 Projet « CELLIER »
/1991 Etude de Dimensionnement et de Conduite d'un Atelier de Fabrication de Type Continu.
Partenaires : Société CELLIER (Aix-Les-Bains), LLP/CESALP – ESIA (Annecy), LGIS – US
(Chambéry).
[43.] 1995 Projet « SIMPROD »

/1996 Introduction de la Simulation de Flux dans le Secteur de Décolletage.
Partenaires : CPHS (Centre de Productique de Haute-Savoie, Annecy), CTDec (Centre des
Techniques de DEColletage, Cluses), LLP/CESALP – ESIA (Annecy), Société 1Point2
(Lyon), Société Gradel (Cluses), Société Bouverat (Cluses).
Durée : 12 mois – Budget : 200 KF + 1 salaire à temps plein pendant 1an.
[44.] 1996 Projet « DAV »

Etude Dynamique de Dimensionnement d’une Ligne de Production de Produits Assemblés.
Partenaires : Société DAV (Annemasse), LLP/CESALP – ESIA (Annecy).
[45.] 1996 Projet « TK RIZIERE/EMAIL »

/1997 Modélisation et Simulation de Lignes de Production,
Aide au Dimensionnement, au Pilotage et à l’Ordonnancement,
Modélisation et Simulation d’un Système de Transfert et de Stockage Dynamique.
Partenaires : Société TEFAL (Rumilly), LLP/CESALP – ESIA (Annecy).
[46.] 1997 Projet « CORIS »

/2000 Modélisation d’un Système de Pilotage pour l’Aide à la Décision Industrielle.
Partenaires : Société ALCATEL (Annecy), LLP/CESALP – ESIA (Annecy).
Durée : 36 mois – Budget : 180 KF + 1 salaire (bourse CIFRE sur 3 ans).
4.9. Conférences invitées et séminaires

[47.] 1993 G. HABCHI
La Simulation et la Maîtrise des Flux Physiques.
Conférence organisée par Progection (Association pour la PROmotion de la GEstion de
produCTION), Université de Savoie, 17 juin 1993.
%"
[48.] 1994 G. HABCHI
Modélisation et Simulation des Systèmes de Production, Lot Sizing & Approche Orientée Objet.
Séminaire organisé par le CESALP (CEntre des Sciences Appliquées à La Production), ESIA,
Université de Savoie, 24 février 1994.
[49.] 1996 G. HABCHI, S. BUTAUD

La Simulation de Flux – Un Garde-Fou dans vos Choix Industriels.
Conférence invitée, SIMODEC’1996, Salon International de la Machine Outil de Décolletage,
18-23 mars 1996, La Roche Sur Foron, France.
Conférence réalisée dans le cadre du projet « SIMPROD ».
[50.] 1996 G. HABCHI

La Simulation de Flux – Quand et Comment ?
Conférence invitée, 5 à 7 CTDEC/CPHS, 17 octobre 1996, Cluses, France.
Conférence réalisée dans le cadre du projet « SIMPROD ».
[51.] 1997 G. HABCHI

Modélisation et Simulation des Systèmes de Production.
Conférence invitée, entreprise TEFAL, 11 avril 1997, Rumilly, France.
Conférence réalisée dans le cadre du projet « TK RIZIERE / EMAIL ».
4.10. Développement de prototype et de logiciel

[52.] 1999 Logiciel « ADONIS » version 2.0
/2000 Caractérisation de la Fiabilité Expérimentale et Opérationnelle des Produits et Systèmes.
Type de fiabilité – expérimentale et opérationnelle
Produits – réparables et non réparables
Essais – complet, tronqué, censuré, interrompu, fractionné
Techniques d’exploitation – actuariat, mort soudaine, Johnson, Habchi, taux du hasard cumulé,
rangs médians, rangs moyens,…
Modèles théoriques – Weibull, exponentiel, normal.
Langage d’implémentation – Visual Basic
http://www.ogp-annecy.com (version 1.0 en démo).
[53.] 2000 Prototype « APOLLO »

/2001 Modélisation et Simulation des Systèmes de Production.
Type de systèmes – manufacturiers
Processus modélisables – opérationnels et décisionnels
Concepts utilisés – le STP, l’Entité Circulante et le CP
Langage d’implémentation – Java
(Prototype basé sur les concepts et modèles développés dans le cadre des thèses de M. Bakalem
et C. Berchet)
$
& '
Motivations et choix de la thématique de recherche :
Ingénieur ENSM (Ecole Nationale Supérieure de Mécanique de Nantes actuellement Ecole

Centrale), je possède un profil de formation en « Génie Mécanique et Productique, Spécialité
Conception et Fabrication » ayant des compétences générales assez larges. Une certaine
passion pour la recherche en général a été initiée pendant mes travaux de DEA et de thèse au
Centre de Productique de l’ENSM. Ces deux points vont faciliter et aider à la reconversion de
ma thématique de recherche à l’Université de Savoie.
A mon arrivée, au département OGP « Organisation et Génie de la Production » de l’IUT

d’Annecy, une reconversion de la thématique s’est avérée indispensable et nécessaire pour des
raisons diverses mais complémentaires. D’abord, je cite quelques-unes liées directement aux
contextes universitaire et industriel du site annecien de l’Université de Savoie.
• La 1ère raison est de nature pédagogique, liée à l’enseignement dans différentes structures
(OGP, ESIA, ITII, IUP/GSI...). Des compétences particulières en simulation et générales
en génie industriel sont indispensables pour assurer l’enseignement des deux modules de
« simulation des flux de production » et « sûreté de fonctionnement des systèmes
industriels » que j’avais en charge.
• La 2ème raison concerne le cadre de recherche disponible sur le site annecien. En octobre
1988, la poursuite des travaux antérieurs est quasi impossible. Les deux laboratoires qui
existaient, sont ; le LAMII (Laboratoire d’Automatique et de Micro-Informatique
Industrielle) et le LSM (Laboratoire des Sciences des Matériaux).
• La 3ème raison concerne la création de notre laboratoire actuel (le LLP/CESALP). Cette
création lancée par les professeurs Alain Haurat et Alain Courtois, s’est avérée
indispensable dans le domaine du génie industriel. En effet, d’une part les structures
diplômantes se prêtaient fort bien à ce domaine et d’autre part, certains enseignants
chercheurs convoitaient un cadre de recherche compatible avec leurs ambitions
scientifiques.
• La 4ème raison s’est manifestée dans un besoin ressenti par les entreprises de la région en
productique, particulièrement dans l’aide à la décision en conception et réimplantation
d’ateliers, pour la validation de nouvelles méthodes de gestion... La simulation se
présentait comme l’outil le plus efficace et le plus adéquat dans ce domaine.
' (
La recherche dans le domaine de « la simulation des SdPs » nécessite des compétences

multiples dans différentes disciplines. En effet, une compétence en simulation informatique
avec tous ses aspects (fondements théoriques, approches, modèles, techniques, processus,
outils...) est une condition nécessaire mais non suffisante. D’autres compétences sont soit
nécessaires soit utiles. Ainsi, des compétences liées au domaine d’application (les SdPs avec
toutes leurs composantes : physique, information, décision, gestion, organisation, pilotage,
risque, aléa...) et à d’autres domaines scientifiques (méthodes d’analyse, statistiques,
distributions aléatoires, plans d’expériences...) sont nécessaires. Et, certaines compétences
dans des domaines de recherche parallèles (méthodes analytiques, réseaux de Petri, chaînes de
Markov...) sont utiles et souhaitables. Cette compétence fondamentale et multiple est acquise
progressivement et continuellement, par l’implication dans des actions de natures diverses
(recherche, encadrement, conférences, enseignement, formation, conseil...) et dans des
structures de niveaux différents (Ecoles d’Ingénieurs, IUP, IUT, Formation Continue...) ayant
une population d’origines diverses (formation initiale, formation par alternance...).
L’implication sur le terrain, dans plusieurs études industrielles a permis : de faire une analyse
assez approfondie des SdPs, de dégager certaines limites de la simulation informatique (par
exemple au niveau de la réutilisation, de l’affinage, de la modularité, de la convivialité des
outils, de la simplification du processus de simulation...) et de proposer certaines
améliorations concernant des concepts nouveaux, naturels et proches de l’utilisateur potentiel.
L’approche que nous proposons est naturelle, en effet nous estimons qu’un responsable de
production non initié doit pouvoir utiliser un outil de simulation sans risque. Ce type de
démarche nécessite un rapprochement permanent du chercheur en simulation avec
l’entreprise. Ce rapprochement a été concrétisé par des études industrielles, des conférences et
des séminaires, ainsi que par le développement d’un projet avec des partenaires d’origines
diverses (LLP/CESALP, CPHS9, CTDec10, 1P211). Notre choix affiché pour cette thématique
et notre implication scientifique aux niveaux national et international, se sont traduits
dernièrement par l’organisation à Annecy, de la 2ème conférence francophone de modélisation
et de simulation (MOSIM’99) et par l’implication dans d’autres conférences.
Résumé du contenu de cette partie du mémoire :
Ainsi, la deuxième partie de ce mémoire est consacrée à un développement relativement

détaillé de nos activités de recherche menées au sein du LLP/CESALP depuis sa création en
octobre 1988, sur la thématique de « la modélisation et la simulation des SdPs ». Les
résultats de ces activités constituent un ensemble de travaux personnels mais surtout collectifs
que j’ai eu l’occasion d’animer dans le cadre de thèses de doctorat et de DEA au sein de
l’équipe « conception et optimisation des processus industriels ».
D’un point de vue pratique, cette partie est constituée de cette introduction, de trois chapitres,
d’une conclusion et des perspectives futures et d’une bibliographie attenante. L’essentiel de
cette partie a été co-encadré dans les thèses de M. Bakalem soutenue en juillet 1996 et de C.
Berchet soutenue en décembre 2000.
Le premier chapitre a pour objectif de positionner le domaine et la thématique scientifiques de

nos recherches. Ainsi, suite à une introduction succincte sur la problématique actuelle de la
9
CPHS : Centre de Productique de Haute Savoie (actuellement transformé en Thésame).
10
CTDec : Centre Technique de Décolletage – Cluses.
11
1P2 : Société de conseil en simulation et distributeur français du logiciel EXTEND – Lyon.
' (
modélisation et de la simulation dans un environnement relatif aux systèmes industriels, nous

décrivons d’abord le SdP ainsi que ses composantes essentielles : le système opérationnel et le
système de pilotage. Ensuite, nous abordons les principales approches d’évaluation des
performances utilisées : les mesures directes, les méthodes analytiques et la simulation. Nous
nous attardons sur cette science qu’est la simulation informatique (notre thématique
principale), notamment : sa définition, son processus, ses approches de modélisation, ses
logiques de changement d’état et ses langages. Enfin, nous terminons ce chapitre par un tour
d’horizon sur l’état de l’art actuel de la simulation en génie industriel et par quelques-unes de
nos publications personnelles ou collectives dans le cadre d’encadrements de DEA et de
thèses et dans le cadre de transfert vers l’industrie.
Le deuxième chapitre est principalement consacré à notre contribution en matière d’analyse et

de conceptualisation pour la modélisation et la simulation des SdPs. D’abord, à la lumière
d’une analyse de l’état actuel de la simulation des SdPs (potentiels, apports, limites), certains
critères d’efficacité ainsi que des améliorations possibles sont proposés. Ensuite, une analyse
du SdP du point de vue de la simulation, est réalisée. Cette analyse a permis de proposer un
cadre de conceptualisation et des concepts sur la base des critères d’efficacité définis. Le
cadre de conceptualisation du SdP se traduit par : une décomposition hiérarchique du système
de fabrication, un comportement standard d’une ressource du point de vue de la simulation,
une définition des niveaux d’abstraction d’une ressource, une décomposition du flux
physique, une structure globale de pilotage coordonnée hiérarchisée, une structure locale et
une typologie du pilotage. Les concepts développés concernent principalement : le Système
de Transformation du Produit (STP) permettant de représenter une ressource, l’Entité
Circulante (EC) permettant de représenter le flux physiques et le Centre de Pilotage (CP)
permettant de représenter une unité de pilotage. Enfin, le chapitre se termine par le
développement des liens d’échange qui pourraient exister entre STPs, ECs et CPs en vue de la
modélisation du comportement de l’ensemble.
Dans le troisième chapitre, nous proposons une description et une formalisation des concepts
développés en vue de réaliser une modélisation orientée objet des SdPs. Chacun des trois
concepts (STP, EC, CP) est formalisé d’un point de vue « objet », de manière à faire
apparaître ses trois parties essentielles : structurelle, fonctionnelle et comportementale. La
logique de simulation adoptée est celle orientée événement. Enfin, après quelques rappels sur
la simulation, la programmation et la modélisation orientées objets, nous proposons un
modèle UML composé de cinq paquetages de classes : le paquetage STP, le paquetage EC, le
paquetage CP, le paquetage réseau STP/CP et le paquetage Simulateur. Une plate-forme
nommée Apollo est actuellement en cours de programmation avec JAVA.
Une conclusion générale sur les travaux réalisés et des perspectives de recherche futures
constitue le dernier chapitre de cette partie. Ainsi, nous cherchons d’une part à faire ressortir
les points forts de notre activité de recherche et d’encadrement et nous proposons d’autre part
des projets de recherche permettant de constituer des nouveaux axes pour notre recherche
future, à court, moyen et long termes.
' (
! (
)
* ! !
1. INTRODUCTION
Durant les trois dernières décennies du 20ème siècle, l’entreprise a subi une mutation en
profondeur. Des changements notables ont modifié l’ensemble des composantes des systèmes
industriels. Les éléments à l’origine de cette évolution sont nombreux : évolution rapide et
importante de la technologie, rapprochement des frontières et des cultures, ouverture d’un
marché au niveau planétaire, mondialisation de l’économie... Les industries orientales ont
exploité avec réussite une technologie occidentale bien avancée, les industries occidentales
ont appliqué des méthodes et techniques orientales récentes et surtout pragmatiques. L’offre
surpassant la demande, le client est devenu la cible et la contrainte première de l’entreprise.
Subissant cette contrainte, l’entreprise modifie la structure de ses SdPs et met en place des
organisations de tout bord : sections homogènes, lignes dédiées, technologie de groupe,
structures orientées flux... Elle personnalise ses produits et utilise des modes de gestion et des
techniques adaptés : calcul de besoin, calcul de charge, juste à temps, kanban, management de
ressources globales, management total productif, qualité totale, production « amaigrie » (lean
production), systèmes de gestion intégrée, chaîne logistique globale... Face à cette évolution
en profondeur de l’entreprise, des techniques, des méthodes et des outils nouveaux ont
émergé pour assister l’utilisateur potentiel dans des domaines très divers de la production :
l’analyse, la conception, le suivi, la gestion, le pilotage, la décision, l’évaluation des
) *+ , -
performances, la qualité... Des méthodes, des techniques et des outils pour la modélisation et
l’évaluation des performances de ces systèmes sont développés, mis en œuvre et sont
actuellement en pleine expansion.
La simulation informatique, technique particulière de modélisation et d’évaluation des

performances des SdPs a été utilisée depuis le début des années soixante. Outil puissant
d’imitation des systèmes de toutes disciplines [Fishwick 1997], la simulation n’a cessé
d’évoluer et de s’étendre dans les laboratoires et les structures de recherche dans le monde
entier. Fondée sur des approches naturelles (événement, activité, processus, objet), elle permet
une reproduction quasi parfaite des flux physiques des SdPs. C’est aussi l’outil par excellence
de suivi et de traçabilité des flux informationnels des mêmes systèmes [Ballot 1997].
L’évolution exponentielle et permanente de la technologie informatique dans tous ses aspects
(processeurs, puissance de calcul, mémoires, langages...) ainsi que l’appropriation facilitée
par la chute des coûts, ont largement contribué à un développement croissant de cette
technique. La complexité des SdPs engendrée par la dynamique d’évolution des flux, le
caractère aléatoire et incertain de l’état des ressources, les incertitudes sur les données,
l’instabilité de prévisions non fiables... a rendu quasi-impossible l’utilisation des méthodes
analytiques et graphiques développées dans ce domaine. Ce dernier point a joué le rôle de
catalyseur et d’accélérateur dans le développement et l’exploitation de la simulation, même
chez les adeptes des méthodes analytiques, pour vérifier la fiabilité et l’exactitude des
résultats obtenus par les modèles analytiques. Malgré une diffusion et une utilisation
relativement importantes de la simulation, le champ de recherche dans ce domaine reste
encore largement incomplet sur différents aspects. En effet, le potentiel de la simulation est
beaucoup plus large qu’il l’est actuellement. Son rôle que nous caractérisons, aujourd’hui, par
le terme « passif » suite à une constatation et une analyse des résultats en fonction de
paramètres fixes a priori doit devenir beaucoup plus « actif » en introduisant dans les
modèles, des boucles rétroactives de pilotage et de décision. Des lacunes, des problèmes et
des difficultés subsistent encore aussi bien dans les approches de modélisation que dans les
outils, et par conséquent, l’exploitation par des utilisateurs potentiels non initiés reste
ponctuelle et limitée.
L’apport, si important, de la simulation dans cette évolution industrielle, réside dans ses
capacités d’imitation et de prédiction. En effet, elle fournit une aide appréciable dans la
conception, la gestion et l’aide à la décision. Elle peut être utilisée dans l’ensemble des phases
du cycle de vie d’un système : la conception, la mise en place, l’exploitation. Dès le
lancement d’un projet et l’analyse des besoins, elle sert à valider, justifier et quantifier les
investissements nécessaires [Habchi et al. 1992] [Chau et al. 1994]. Mais aussi, elle sert à la
réalisation de diagnostics, la détection de faiblesses, la réimplantation,… et permet d’anticiper
la mise en place de décisions et aider au pilotage du système [Habchi et al. 1995] [Bakalem
1996].
Toutefois, certaines lacunes subsistent dans son incapacité à modéliser des décisions
[Pierreval 1999] [Habchi et al. 1999] [Berchet et al. 1999b] [Berchet 2000], c’est à dire, le
processus de pilotage associé au processus piloté (processus de fabrication). De ce fait, il est
quasi-impossible dans l’état actuel, de modéliser le couple processus de fabrication /
processus de pilotage, en séparant l’un de l’autre ou même ensemble. Pourtant, pour qu’un
modèle soit satisfaisant il faut que le processus étudié soit modélisé avec toutes ses
composantes : opérationnelle, informationnelle et décisionnelle.
!
) *+ , -
2. LE SYSTEME DE PRODUCTION
Avant d’aborder la simulation informatique, il est important de présenter et de faire une

analyse du système que nous cherchons à modéliser et simuler : le SdP (système de
production) de l’entreprise. Nous verrons de manière assez succincte, ses composantes, ses
modes d’organisation, ainsi que les paramètres auxquels il est soumis.
2.1. Les composantes d’un système de production

D’un point de vue systémique [Le Moigne 1990], il est classique de décomposer le système
« entreprise » en trois sous-systèmes qui coopèrent :
• le sous-système physique représentant le système opérant,
• le sous-système d’information permettant l’acquisition, le traitement et la gestion des
données du système et de son environnement,
• le sous-système de décision qui pilote (identifie, analyse et corrige les dérives en
proposant des actions correctives ou préventives) le système physique.
Si cette décomposition est valable pour le système entreprise, et permet son analyse, elle est
moins adaptée pour le SdP et sa modélisation (nous rappelons que la simulation informatique
d’un système ne peut exister sans modélisation de ce système). Dans le SdP, les sous-
systèmes d’information et de décision n’ont pas d’existence propre, l’un sans l’autre. Ils
constituent ensemble ce que nous appelons le système de pilotage ou le système
d’information et de décision (SID) ou encore le système directeur [Rodde 1991]. Ainsi, il est
plus conforme à la réalité de considérer le SdP comme l’association d’un système de
fabrication et d’un système de pilotage.
2.1.1. Le système de fabrication
Dans une optique de simulation, le système de fabrication est composé de ressources et

d’entités. Les ressources comprennent les machines, les stocks, les opérateurs, les moyens de
transfert... et les entités comprennent les produits, les matières premières, les pièces, les lots...
L’analyse des composantes d’un système de fabrication montre que les ressources présentent
simultanément un aspect « machine » et un aspect « stock ». En effet, une machine peut
présenter un aspect « stock » dans des conditions de blocage. Les stocks et les moyens de
transfert présentent un aspect « machine » si le temps de transit n’est pas nul. Selon ce point
de vue, un système de fabrication est un ensemble de ressources qui effectuent des opérations
de transformation sur les entités.
Les ressources peuvent être identifiées par deux types :

• les ressources principales (machines, robots, moyens de transfert, stocks,…) qui sont
actives et qui ont une certaine autonomie vis-à-vis du reste du système. Elles peuvent
évoluer dans certaines limites, indépendamment du reste du système ;
• les ressources auxiliaires (outils, palettes,…) qui sont passives et qui permettent à des
ressources principales d’accomplir une opération. Ce type de ressource est caractérisé par
son exclusivité ou sa partageabilité.
"
) *+ , -
Dans certains cas, les opérateurs humains peuvent être considérés comme ressources
principales (opération de contrôle, de pesage, d’emballage,…) et dans d’autres cas comme
ressources auxiliaires (réglage d’une machine).
Les opérations de transformation réalisées par les ressources principales peuvent être de deux
types : les opérations avec valeur ajoutée (enlèvement de matière, déformation, assemblage,
emballage...) et les opérations sans valeur ajoutée (stockage, contrôle, transfert...).
2.1.2. Le système de pilotage
Avant de présenter et d’analyser le système de pilotage, essayons de rappeler la signification

du terme « pilotage » comme aperçue dans la littérature. Une bonne synthèse est proposée
dans la thèse de doctorat de Claire Berchet [Berchet 2000]. Néanmoins, nous présentons
quelques notions appartenant à des domaines de base d’origines diverses, tels que : la gestion,
la productique, l’automatique, le génie industriel, la gestion de production...
En 1972, Mélèse [Mélèse 1972] crée le concept de module de pilotage, entité comprenant
outre un décideur, des sous-systèmes programmés, décisionnels et d’évolution. Ce module
constitue la première apparition d’un formalisme spécifique dédié à la compréhension du
mécanisme de la prise de décision, en particulier dans la gestion de production. Des études de
fonctionnement décisionnel ont été menées à partir de ce module. Le Moigne [Le Moigne
1974] définit le concept de pilotage et introduit notamment dans le domaine de gestion de
production la notion de boucle fermée. Chez Breuil [Breuil 1984], nous retrouvons les
notions de partie opérative et de partie commande. Pour Doumeingts [Doumeingts 1984],
piloter c’est assigner à chaque partie du système un ou plusieurs objectifs à atteindre. D’après
Avenier [Avenier 1984], piloter un système, c’est choisir un objectif par rapport auquel il faut
définir la meilleure trajectoire… Selon l’APICS [Melnyk et al. 1987], le pilotage concerne le
domaine opérationnel, il est défini par un groupe d’activités directement responsable de la
gestion de la transformation d’ordres de fabrication planifiés en pièces sorties de l’atelier.
L’objectif principal de la fonction pilotage de la production est la bonne exécution du
programme prévisionnel de production par le système physique [Nagi 1991]. L’AFGI
(Association Française de Gestion Industrielle) [Afgi 1992] définit le pilotage comme un
mécanisme multi-niveaux, hiérarchisé et bouclé. Selon Lorino [Lorino 1992], piloter c’est
définir des règles de comportement cohérentes avec un objectif global de l’entreprise.
Trentesaux [Trentesaux 1996] définit le pilotage comme une structure de décision et
d’information associée à la gestion temps réel. Grabot et Huguet [Grabot et al. 1996]
[Grabot et al. 1997] considèrent le pilotage comme un ensemble d’activités permettant la
production court terme dans l’atelier d’être en accord avec les objectifs établis par la gestion
de production. Pour Youssef [Youssef 1998], le pilotage a pour but d’assurer la cohérence des
décisions entre des ordres issus de la gestion prévisionnelle et les actions exécutées au niveau
du SdP.
La liste peut être beaucoup plus longue. La multiplicité des définitions traduit la complexité à
définir en quelques mots le terme « pilotage ». Ce terme est abordé actuellement par un
groupe de travail dans le cadre du GRP (Groupement de Recherche pour la Productique).
Quant au système de pilotage, il peut être composé :

• de points de captage (les capteurs) pour la récupération de l’information,
$
) *+ , -
• d’un processus de décision pour l’analyse, le traitement de l’information, l’évaluation et la

génération de décisions,
• de points d’actions qui constituent les points de passage des ordres ou des actions vers le
système de fabrication.
La réactivité du SdP dépend en premier lieu de la capacité de réaction de son système de

pilotage. Cette capacité dépend de la qualité et de la quantité des points de captage et des
points d’action, d’une part, et de l’efficacité du processus de décision, d’autre part.
Suite à cette présentation des SdPs, nous proposons dans le chapitre suivant, une
décomposition hiérarchique et décisionnelle de ces systèmes, du point de vue de la simulation
permettant ainsi d’aborder des concepts génériques qui seront les fondements de notre
approche de modélisation.
2.2. La maîtrise des systèmes de production

Maîtriser un SdP c’est supposer que celui-ci est totalement contrôlé, appréhendé, piloté,… et
dont les résultats sont connus à l’avance. Un système qui subit une dérive, suite à l’arrivée
d’un aléa, et remettant en cause l’objectif initial, est un système dont la maîtrise n’est pas
complètement assurée. Ainsi, la maîtrise des SdPs consiste à assurer, en permanence, une
utilisation optimale de l’ensemble des ressources de production et une réalisation bonne et
dans les délais des produits. Cet exercice est guidé (piloté) par un ensemble de règles dont les
décisions dépendent des informations actualisées sur l’état du système à un instant donné.
Ainsi, la maîtrise d’un SdP passe nécessairement par une bonne acquisition de l’information
et une bonne capacité de prise de décision en cas de nécessité [Hill 1989].
La maîtrise du SdP est une tâche ardue et difficilement réalisable pour des raisons de natures
différentes (technologique, organisationnelle, décisionnelle, dynamique...). De ce fait, la
maîtrise du système est conditionnée par plusieurs paramètres et dépend généralement de
différents aspects :
• les paramètres qui conditionnent un SdP sont très nombreux. Il y a des paramètres
physiques liés aux ressources et produits, des paramètres organisationnels, des paramètres
décisionnels, des paramètres de gestion... ;
• la dynamique du SdP n’est ni linéaire ni permanente. Le système est soumis
continuellement à des risques et des incertitudes qui surviennent de tout bord (clients,
prévisions, pannes, absentéisme, délais, qualité...) ;
• le SdP est un système de type distribué où des tâches multiples sont réalisées
simultanément, des opérations de synchronisation et de partageabilité sont souvent
nécessaires à accomplir ;
• les objectifs des différentes fonctions du système sont souvent antagonistes. La
satisfaction d’objectifs élémentaires ne s’inscrit pas nécessairement dans la satisfaction
d’objectifs globaux.
Tout ceci rend le SdP difficilement appréhensible, dont la tâche de maîtrise est complexe,
nécessitant des méthodes et d’outils hautement sophistiqués. Dans ce sens, pour maîtriser les
flux de production, des approches et des techniques ; de modélisation, de pilotage, d’aide à la
décision, de planification, d’évaluation des performances... sont développées et mises en
place.
) *+ , -
3. L’EVALUATION DES PERFORMANCES DES SYSTEMES DE

PRODUCTION
Le recours à l’évaluation des performances d’un SdP est nécessaire avant toute prise de
décision, l’objectif étant l’optimisation de sa performance. Cette évaluation représente la
mesure de l’impact d’une décision sur le système ou l’influence de perturbations modifiant
son état. Les acteurs de la productique s’accordent sur le fait que, dorénavant, l’analyse, la
conception et l’exploitation des SdPs ne peuvent être menées à bien sans une assistance
méthodique [Pierreval 1990].
D’après [Caux 1993], évaluer signifie « déterminer une quantité par le calcul sans avoir
recours à la mesure directe ». Ceci suppose que l’évaluation soit effectuée à l’aide d’un
modèle qui peut être expérimental, mathématique, de simulation... Evaluer implique
également le recours à un objectif et un indicateur de performance qui fournit une donnée
quantifiée mesurant l’efficacité du système, donc son aptitude à générer une performance
[Berrah 1997].
Les trois approches classiques d’évaluation des performances des SdPs sont : les mesures
directes, les méthodes analytiques et la simulation informatique. Cependant, d’autres
méthodes sont parfois utilisées partiellement dans certaines phases du processus d’évaluation
par l’une ou l’autre des deux dernières approches. Ainsi, les modèles SADT (Structured
Analysis and Design Technique) et entité-relation [Pierreval 1987], ont été utilisés dans le
cadre d’un processus de simulation par l’approche orientée objet et les réseaux de Petri dans
une approche analytique. Ces méthodes permettent de réaliser une modélisation plus fine et
plus précise rendant cette opération moins empirique.
3.1. Les mesures directes

Les mesures directes sont pratiquées directement sur le système réel ou sur une maquette ou
un prototype physique représentant ce système. Les bassins de carène sont utilisés pour
simuler le comportement d’un bateau ou d’un navire à l’aide d’une maquette à échelle réduite.
Des expériences en soufflerie sont réalisées pour simuler le comportement d’un avion de
chasse soumis à une vitesse d’air supersonique. Des expériences réelles sont réalisées pour
mesurer la réaction au choc d’un véhicule contre un obstacle rigide. Ces simulations en
grandeur réelle sont réalisées quand elles ne peuvent être remplacées par des simulations
informatiques, le système étant très complexe pour être remplacé par un modèle fiable. Il est
inutile de rappeler que ces expériences sont excessivement chères et nécessitent des budgets
très importants pour leur mise en place. La réalisation de mesures directes sur des SdPs ne
peut être acceptée que dans le cas d’une démarche de progrès, d’amélioration continue ou de
pilotage par indicateurs de processus. Les mesures directes ne peuvent être pratiquées dans le
cas de systèmes non existants et si la réalisation de prototypes physiques coûte trop chère.
Dans plusieurs cas, les autres méthodes permettent avec des hypothèses suffisantes d’évaluer
la performance de ces systèmes avant que la réalisation soit engagée.
#
) *+ , -
3.2. Les méthodes analytiques

Les fondements des méthodes analytiques sont à la base d’outils assez pratiques,
fréquemment utilisés dans l’évaluation des performances des SdPs. Ces méthodes exigent
qu’un modèle mathématique soit d’abord trouvé pour représenter le système étudié et que l’on
dispose des outils mathématiques qui permettent d’étudier ce modèle. Une démarche
analytique se décompose en trois étapes :
• recherche d’une approche analytique adéquate (modèle mathématique qui s’adapte au cas
étudié),
• développement du modèle (émission des hypothèses adaptatives du système réel à la
théorie adoptée et déduction du modèle),
• implémentation, utilisation et exploitation du modèle.
Les techniques permettant d’étudier de manière analytique un SdP sont nombreuses [Proth et
al. 1987] :
• la programmation linéaire consiste à optimiser une fonction objective sous certaines
contraintes linéaires conduisant à une solution statique,
• la programmation dynamique consiste à trouver une solution optimale à partir de solutions
optimales partielles comme dans le cas d’un programme PERT,
• les chaînes de Markov sont utilisées dans la modélisation des systèmes stochastiques et
dans lesquelles on définit l’état d’un système par un comportement entièrement
probabiliste,
• les graphes potentiels tâches et l’algèbre des dioïdes [Cohen et al. 1983] nécessitent de
connaître les séquences d’activités pour tous les objets considérés au sein du système,
• la théorie des files d’attente consiste à représenter le système sous forme d’un réseau de
serveurs, de zones d’attente et de clients,
• les réseaux de Petri [David et al. 1988] constituent un outil graphique basé sur deux
sortes de nœuds, les places et les transitions. A partir de ce graphe, on déduit des
équations qui décrivent les caractéristiques du système (vivacité, synchronisation,…).
3.3. La simulation pour l’évaluation des performances

Parallèlement aux méthodes analytiques, s’est créée depuis les années soixante une technique
relevant d’une conception tout à fait différente. Il s’agit de la simulation, une technique qui
exploite une autre voie, la voie expérimentale. Les premiers langages de simulation
développés ont été principalement utilisés pour des projets financiers afin de déterminer des
coûts dans le cadre d’une unité de production mais rarement en ingénierie [Serin et al. 1996].
Elle a trouvé ensuite, une utilisation dans de nombreux domaines : la conception,
l’optimisation, l’évaluation des performances... Les applications sont nombreuses :
l’informatique, les réseaux de communication, la logistique, la fabrication, les stratégies
militaires, la manutention... Le recours à cette technique se fait principalement dans deux
types de situations : le premier correspond au cas où l’expérimentation directe serait
impossible à réaliser pour des raisons morales, d’impératifs temporels, de contraintes
budgétaires, d’obstacles naturels..., le second correspond au cas où on ne disposerait pas de
bases théoriques capables de modéliser la réalité dans toute sa complexité. La simulation peut
servir dans ce dernier cas de repère pour d’éventuels modèles théoriques et déterminer lequel
qui fournit la meilleure approximation. Il faut rappeler, que la simulation cherche plutôt à
atteindre des objectifs préétablis, alors que les méthodes analytiques cherchent à optimiser.
%
) *+ , -
Elle intervient souvent dans le cas de systèmes beaucoup trop complexes pour donner lieu à
un modèle mathématique fiable. Ceci est particulièrement vrai quand le système est soumis à
des phénomènes dynamiques et des situations aléatoires.
3.4. Méthodes analytiques vs simulation

Nous rejoignons certains auteurs [Dallery 1985] [Dijk 1999] en insistant sur l’absence
d’opposition entre les méthodes analytiques et la simulation informatique. Nous pouvons
même affirmer, que les deux approches sont complémentaires, pouvant intervenir, du fait de
leurs caractéristiques, à des étapes différentes du cycle de vie d’un SdP. Ainsi, les méthodes
analytiques semblent bien adaptées aux premières phases de la conception d’un système. En
effet, à ce niveau, les données sont peu précises et un grand nombre de configurations doit
être testé. De ce fait, il est préférable de disposer de méthodes rapides même si elles ne
calculent que des performances approximatives, l’imprécision sur les données étant
généralement beaucoup plus importante que sur les résultats. De plus, il est plus intéressant
d’utiliser les méthodes analytiques pour déterminer une configuration initiale qui servira de
base de départ à des configurations beaucoup plus précises à l’aide de la simulation. Ceci
s’explique bien par les spécificités de chacune des deux techniques.
Les méthodes analytiques se distinguent par les points suivants : elles nécessitent en général
des hypothèses simplificatrices sur le modèle, elles prennent en compte seulement les
phénomènes les plus importants (par exemple : pas de prise en compte de perturbations), elles
ne fournissent que des performances moyennes sur une longue période de temps, les résultats
sont exacts pour des modèles simples et de petites tailles uniquement, les résultats sont
approximatifs pour des modèles complexes, elles ne tiennent pas compte des événements de
synchronisation (attente, blocage, etc), la durée de traitement est courte...
Quant à la simulation, elle peut être caractérisée par certains faits : elle introduit des
changements dans le temps (technique temporelle), elle possède un processus de conception
de modèle logique et d’expérimentation, elle aide au choix de la politique la plus désirable,
elle est utilisée pour la modélisation de systèmes complexes (généralement stochastiques), le
modèle peut être détaillé sans contraintes jusqu’au niveau désiré, elle nécessite beaucoup de
données, la durée de traitement d’une simulation est souvent plus longue, elle tient compte
des phénomènes de synchronisation...
4. LA SIMULATION INFORMATIQUE
La simulation informatique est une science très familière largement utilisée dans le monde.
Les principales raisons de son utilisation sont : le manque de nécessité pour l’utilisation de
mathématiques poussées, la possibilité de réalisation de modèles réalistes, les résultats visuels
sont un support pour l’aide au développement du modèle et à son validation, ils sont aussi un
moyen de compréhension et de confiance à disposition du client, des options ou alternatives
différentes peuvent être considérées sans expérimentation directe sur le système, des systèmes
non existants peuvent être modélisés, les méthodes analytiques sont perçues comme des
techniques peu utiles par le management de l’entreprise ou peuvent nécessiter beaucoup de
simplifications... La simulation est appropriée à l’étude des systèmes complexes et de grande
taille, composés de plusieurs éléments en interaction. Elle permet de répondre à certains
) *+ , -
problèmes à chaque fois qu’un modèle mathématique ne peut être trouvé ou que
l’expérimentation en grandeur nature se révèle impossible et/ou trop coûteuse.
Dans les paragraphes suivants nous présentons une synthèse sur la simulation informatique,
thématique principale de nos recherches. Ainsi, après la proposition de quelques définitions,
nous développons son processus et les conditions de sa réussite, la modélisation, les logiques
de changement d’état, les langages utilisés ainsi qu’un état de l’art actuel en génie industriel.
4.1. Définition de la simulation informatique

La littérature propose plusieurs définitions de la simulation informatique. Ces définitions sont
parfois proches, équivalentes ou complémentaires [Ammar et al. 1985] [Pritsker 1986]
[Aghetta 1987] [Pierreval 1987] [Habchi et al. 1993] [Fishwick 1997]... Selon [Law et al.
1991] par exemple, elle peut être définie de diverses manières : « un moyen explicatif pour
définir un système, un vecteur d’analyse pour déterminer des résultats critiques, un
évaluateur de conception pour analyser et évaluer des solutions proposées... ». Une synthèse
de certaines définitions est proposée dans la thèse de Bakalem [Bakalem 1996].
A l’image de certaines disciplines telle que la sûreté de fonctionnement, par exemple, nous
proposons deux définitions à la simulation. Une définition au « sens strict » très limitative et
une définition au « sens large » scientifiquement plus complète.
Au « sens strict », la simulation peut être définie de manière abusive par « l’expérimentation
ou la réalisation d’expériences ». Cette définition est pour un spécialiste de simulation trop
limitative et ne peut être considérée sérieusement. Souvent, un non-spécialiste fait référence
(malheureusement !) à cette définition restrictive quand il s’agit de simulation.
Au « sens large », la simulation peut être définie comme étant « une science de reproduction
du comportement d’un système complexe difficilement contrôlable et soumis à des
phénomènes aléatoires ; le comportement du système réel avec toutes ses composantes
(physique, informationnelle, décisionnelle) est ainsi remplacé par un modèle virtuel ayant un
comportement analogue traduit ensuite en un programme informatique permettant de réaliser
des expériences afin d’appréhender le comportement du système réel, d’évaluer ses
performances et d’aider à l’anticipation d’éventuelles dérives ». D’après, cette définition,
nous comprenons que la simulation est une science disposant de méthodes pour l’analyse,
d’approches pour la modélisation, de techniques pour l’exécution, d’outils pour la
programmation, un processus pour l’intégration dans une démarche projet...
4.2. Le processus de simulation

Il est important de rappeler que la construction d’un modèle de simulation n’est qu’une étape
dans un processus. Il est connu que le temps de développement du modèle ne représente
qu’environ 30 à 40% du temps global de l’ensemble du processus. Un processus de
simulation peut être défini selon différents points de vue [Pritsker 1986] [Hoover et al.
1989] [Yucesan et al. 1992] [Musselman 1993] [Banks 1994] [Law 1994]. Ces points de
vue sont beaucoup plus divers que ceux concernant la définition de la simulation elle-même
ou les raisons de son utilisation [Lehaney et al. 1998]. Toutefois, à travers les différentes
) *+ , -
vues proposées, et sans pour autant donner une position absolue, quelques étapes émergent :
la définition et la formulation du problème, la collecte et l’analyse des données, la
modélisation et la programmation, la vérification et la validation du modèle,
l’expérimentation et l’analyse des résultats, la décision et l’implémentation.
La simulation se focalise sur une formalisation et une recherche de solutions en utilisant des
méthodes par tâtonnement [Davis et al. 1994]. En effet, le processus de simulation est un
processus itératif basé encore sur l’expérience individuelle. L’évolution dans ce processus ne
doit pas être interprétée comme strictement séquentielle, des transitions de retour peuvent être
attendues à toutes les étapes. Il révèle souvent le besoin pour des informations importantes et
fait apparaître des points nouveaux dans le problème. Pendant ce processus, les relations entre
le système à étudier et le modèle sont définies et redéfinies continuellement. Une recherche
fondamentale approfondie sur l’automatisation du processus de simulation est aujourd’hui un
besoin urgent et nécessaire surtout pour un utilisateur potentiel non confirmé. En effet, la
littérature manque cruellement de recherche sur plusieurs étapes du processus. Par exemple,
pour la collecte et l’analyse des données, nous retrouvons souvent dans la littérature des
suggestions non approfondies et sans directives, telles que : « les données qui étaient
réduites », « la réduction des données »... La situation est quasi similaire dans la plupart des
ouvrages de simulation, nous retrouvons par exemple : « As preliminary to the construction of
a simulation, it is necessary to abstract from the real system all those components (and their
interactions) that are considered important enough for inclusion in the model » [Mitrani
1982], « A model should contain only enough detail to capture the essence of the systems for
the purposes for which the model is intended », « the construction of a mathematical and
logical model of a real system for a given objective is still as much an art as it is a science »
[Law et al. 1991]... D’après Robinson [Robinson 1994], il y a une tendance à tout modéliser
sans s’arrêter pour reconsidérer exactement ce qui est nécessaire. De ce fait, la définition du
problème et la collecte et l’analyse des données restent un domaine non couvert par la
recherche. Pour la réalisation de ces deux étapes, les plus expérimentés utilisent intuition et
expérience. A ce sujet, Lehtonen et al. [Lehtonen et al. 1997] proposent une méthodologie
appelée « analyse de contrôlabilité en logistique » (controllability analysis in logistics) pour
la collecte et l’analyse des données dans un processus de simulation en logistique. Les auteurs
insistent sur le fait que l’identification et la définition du problème nécessitent l’identification,
la collecte, l’analyse et le traitement des données. En d’autres mots, la définition du problème
et la collecte et l’analyse des données ne sont pas deux étapes subséquentes mais plutôt
simultanées dans un processus de simulation.
Les systèmes industriels peuvent être modélisés en utilisant deux types de techniques : les
techniques temporelles (time based techniques) et les techniques non temporelles (non-time
based techniques). La simulation est une technique temporelle alors que les techniques non
temporelles comportent une série de techniques faisant partie de la recherche opérationnelle
(la programmation linéaire, la théorie des files d’attente, la théorie des graphes, etc). La
technique utilisée détermine le degré de simplification, fixe les hypothèses nécessaires pour la
construction du modèle, et impose le fait que si le caractère aléatoire des systèmes réels doive
être exclu du modèle (par exemple la programmation linéaire). L’une des caractéristiques les
plus puissantes de la simulation est sa capacité à modéliser le caractère stochastique d’un
système réel. Mais, aussi l’un des dangers les plus importants est l’utilisation d’une hypothèse
fausse en simulant un système à caractère aléatoire à l’aide d’un modèle ayant des données
déterministes. Dans ce sens, un article récent [Bekker et al. 1999] expose ce type de
problème. Ainsi, à l’aide de deux modèles de simulation représentant un système réel à
caractère aléatoire (l’un utilisant des données déterministes et l’autre des données
) *+ , -
stochastiques), les auteurs montrent à l’aide de résultats divers le risque engendré par le choix
du type de données. L’étape de modélisation nécessite un effort au préalable pour faire le
choix adéquat du logiciel ou du langage de simulation. A ce propos, certains auteurs [Davis et
al. 1994] proposent le processus hiérarchique analytique (AHP12) dans une étude de cas.
De manière relativement simplifiée, le processus de simulation peut être présenté selon la

figure 1.1. La modélisation fournit un modèle conceptuel (modèle de connaissance), la
programmation fournit un modèle exécutable (modèle d’action), la simulation ou
l’expérimentation fournit les résultats obtenus du modèle, l’analyse des résultats permet
d’évaluer le processus à modéliser.
Modèle
Modélisation conceptuel Programmation
Processus à Modèle
modéliser exécutable
Résultats
Analyse obtenus du Expérimentation
modèle
Figure 1.1. - Processus simplifié de simulation.
De manière plus détaillée, le processus de simulation peut être éclaté en dix étapes [Pritsker
1986] (figure 1.2) : analyse et formulation du problème, identification et collecte des données,
construction du modèle, transcription informatique du modèle, vérification du modèle [Balci
1994] [Balci 1997], validation du modèle [Balci 1997] [Sargent 1984] [Sargent 1999],
planification stratégique et tactique de la simulation, exécution de la simulation, analyse et
interprétation des résultats, recommandations et mise en place [Tucker et al. 1998].
Balci [Balci 1994] et Nance [Nance 1994] proposent un processus de simulation en « cycle
de vie », mais aussi en dix étapes. A part quelques-unes, le processus est identique au
précédent. Les étapes proposées sont : communication du problème, formulation du problème,
proposition de solution, formulation du modèle, représentation conceptuelle du modèle,
programmation du modèle, conception des expériences, expérimentation, analyse des
résultats, intégration du support de décision.
Comme nous avons déjà noté plus haut, des recherches sur l’informatisation et
l’automatisation de ce processus sont nécessaires pour intégrer des concepts « naturels »
(proches de l’utilisateur potentiel) à l’étape de modélisation, aider l’utilisateur à planifier les
expériences et analyser les résultats. Mais aussi, des travaux sont indispensables pour
simplifier, voire éliminer l’étape de programmation qui nécessite souvent des compétences en
informatique et réduit le potentiel d’utilisation de la simulation.
12
AHP – Analytic Hierarchy Process.
&
) *+ , -
Formulation du problème
Modélisation
Identification et collecte des données
Etapes à
Transcription informatique du modèle simplifier ou
à éliminer du
processus de
Vérification du modèle
simulation.
Validation du modèle
Planification stratégique et tactique de la simulation

Nombre
d’expériences
Exécution de la simulation
à réduire.
Analyse et interprétation des résultats
Modifications, documentations et développements futurs
Figure 1.2. - Processus de simulation selon Pritsker.
Certains chercheurs proposent l’utilisation d’une démarche projet en simulation et insistent

sur ses conditions de succès. En particulier, Kosturiak et al. [Kosturiak et al. 1998] proposent
douze conditions nécessaires pour réussir un projet de simulation. Ces conditions
appartiennent en partie au processus décrit précédemment. Nous citons quelques-unes de ces
conditions : choix du bon moment pour l’utilisation de la simulation, choix d’une approche
projet, compétence et expérience, choix d’un niveau de détail approprié du modèle, mise en
forme des données, communication et coopération de l’équipe de projet, outil de simulation
approprié, présentation et interprétation des résultats.
4.3. Méta-modélisation, modélisation, logique de changement d’état et

simulation
4.3.1. Méta-modélisation et modélisation
La méta-modélisation correspond à une phase d’abstraction de haut niveau. Elle permet de

mettre en place les concepts fondamentaux qui seront utilisés au niveau utilisateur dans la
phase de modélisation à l’aide d’un outil de simulation. Ces concepts de haut niveau peuvent
être basés sur des méthodes analytiques telles que les files d’attente et les réseaux de Petri, sur
!
) *+ , -
des primitives ou fonctions dédiées telles que celles mises en place par Pegden et utilisées
dans ARENA (Seize, Delay, Release...), ou sur le développement de nouveaux concepts tels
que le STP (Système de Transformation du Produit) et le CP (Centre de Pilotage) qui sont au
cœur de nos travaux et qui sont détaillés au chapitre suivant de ce mémoire. La modélisation
correspond à la phase d’utilisation des fonctions génériques ou objets mis en place à l’étape
de méta-modélisation pour développer un modèle de simulation représentant un système
donné. La complexité du modèle dépend évidemment du système à étudier mais aussi des
fonctions à utiliser. Plus les fonctions de base sont abstraites plus la modélisation est
complexe et restreinte à un cercle fermé de spécialistes. Et inversement, plus ces fonctions
sont naturelles plus la modélisation est simplifiée et le champ de simulation est ouvert à un
nombre plus élevé d’utilisateurs potentiels.
4.3.2. Logique de changement d’état et simulation
La dynamique du modèle est obtenue grâce à la logique de changement d’état qui traduit
temporellement et spatialement le comportement des objets, c’est à dire l’évolution des objets
du modèle dans le temps et dans l’espace. La logique de changement d’état est l’un des
facteurs qui conditionnent l’efficacité d’un outil de simulation en terme de rapidité
d’exécution. La simulation pilote le comportement du modèle en examinant et en mettant à
jour le modèle (à travers ses variables et ses attributs) quand il est connu qu’un changement
dans l’état du système doit arriver. De ce fait, la simulation comporte : des changements
instantanés à des points différents du temps et de l’espace, une série d’événements, une série
d’activités et des processus. Du fait que le comportement du modèle peut être piloté par les
événements et les activités ou orienté processus, il existe traditionnellement trois logiques de
changement d’état [Cernault 1988] [Peck et al. 1992] [Chung et al. 1994] [Habchi et al.
1994] : la logique orientée événements, la logique orientée activités et la logique orientée
processus. A ces trois logiques, nous pouvons rajouter l’approche orientée objet utilisée pour
décrire les objets physiques à travers des objets informatiques. Le comportement du modèle
dans une approche objet peut être piloté par l’envoi de messages entre objets.
4.3.2.1. La logique orientée événements (event scheduling)
La logique orientée événements discrets consiste à répertorier les différents types

d’événements (généralement inconditionnels) et à décrire la procédure de changement d’état
correspondante au déclenchement de chaque type d’événement. Aucune modification n’est
censée avoir lieu entre l’occurrence de deux événements successifs. Les événements sont
ordonnés dans un échéancier selon l’ordre chronologique de leur date d’occurrence. La
simulation évolue dans le temps en se déplaçant d’un événement à un autre en exécutant la
logique concernée. SIMSCRIPT et GASP IV sont deux langages orientés événements. Cette
logique convient bien aux systèmes dont les composants sont relativement indépendants, c’est
à dire qu’il existe peu de conditions à tester pour déterminer si un événement doit avoir lieu
[Hooper et al. 1982]. En effet, du fait que certains types d’événements sont générés par
d’autres événements, le modèle peut devenir difficile à maintenir. C’est en partie, pour cette
raison que cette logique a perdue de sa « popularité ».
"
) *+ , -
4.3.2.2. La logique orientée activités (activity scanning)
C’est une logique duale de la précédente. Elle consiste à recenser les différents types
d’activités et à décrire les procédures de changement d’état correspondant aux conditions de
début et de fin de chaque type d’activité. Pendant la simulation, les procédures décrivant les
conditions de début et de fin sont vérifiées par intervalle de temps fixe ou variable. Les
activités ayant les conditions vérifiées, sont ainsi enclenchées ou arrêtées. Si cette technique
est plus simple que la précédente, elle s’avère moins efficace, car à un instant donné, une
procédure peut être testée sans que les conditions de début ou de fin de l’activité ne soient
vérifiées. Cette technique est adaptée aux systèmes dans lesquels les composants sont
fortement dépendants [Evans 1988]. Certaines approches, combinées activités / événements,
ont été développées pour pallier ces inconvénients, par exemple l’approche trois phases ou
ABC. D’abord, l’une des bases de la simulation à événements discrets est le diagramme à
cycles d’activités (Activity Cycle Diagram – ACD). Il correspond à une approche de
modélisation du système réel, particulièrement adaptée pour les systèmes à files d’attente.
Ensuite, le diagramme à cycles d’activités contient des entités représentant les éléments du
système modélisé (pièces, opérateurs, machines, chariots...). Les entités peuvent être soient
occupées soient libres. Un rectangle modélise une activité. L’activité représente ce que
transforme l’état d’une entité et correspond à l’état occupé d’une entité. Un cercle modélise
une file d’attente et représente l’état libre d’une entité. Enfin, une activité démarre si les
entités nécessaires sont présentes et s’arrête à un moment pré établi à partir d’un temps défini
fixe ou par tirage sur la base d’une distribution de probabilité. Une activité peut avoir
différents types d’entités alors qu’une file d’attente ne peut contenir qu’un seul type.
4.3.2.3. La logique orientée processus (process interaction)
C’est une logique largement utilisée dans les langages de simulation. Elle cadre naturellement
les systèmes manufacturiers qui comprennent plusieurs parties devant interagir [Garzia et al.
1986], qui peuvent être décomposés en objets passifs et actifs (entités et ressources) [Peck et
al. 1992], ou qui ont souvent des processus identiques [Mébarki 1995]. Elle consiste à
décrire le fonctionnement d’un système comme une interaction de plusieurs processus, à
travers des primitives, des blocs ou des fonctions, conçus au préalable. Chaque type de
primitive (bloc ou fonction) décrit un processus élémentaire et générique du système à
modéliser. Souvent, on considère dans ce type de logique (modélisation) la notion de file
d’attente qui introduit certains problèmes dans la modélisation des systèmes sans stocks.
Quand un processus (de type entité) ne dispose pas de ressources suffisantes, il se met en
attente dans une file jusqu’à ce qu’un autre processus le réveille [Ye 1994]. Cette approche
combine la simplicité de description de l’approche orientée activité et l’efficacité de
l’approche orientée événement. Parmi les langages utilisant cette approche, citons SLAM
[Pritsker 1986] [Pritsker 1991] et ARENA [Pegden et al. 1990].
Certains aspects des systèmes discrets sont difficiles à modéliser en utilisant les précédentes
techniques. Ainsi, des techniques hybrides qui mélangent événements, activités et processus
ont été développées [Hooper et al. 1982] [O’Keefe 1985] [Peck et al. 1992].
4.3.2.4. L’approche orientée objets
L’approche orientée objets est de plus en plus répandue dans le développement des systèmes
[Booch 1991]. Le système est décrit par un ensemble d’objets qui communiquent par envoi de
$
) *+ , -
messages. La modélisation orientée objets se fait en deux étapes : la première concerne la

définition de la structure du système par la spécification des objets (attributs) et la seconde
concerne la définition du comportement dynamique du système en précisant les relations entre
objets ainsi que leur fonctionnement propre (méthodes). Cependant, à un système orienté
objet, il manque un mécanisme de haut niveau permettant le contrôle des envois de messages
dans le temps (comportement dynamique). Au sein du LLP/CESALP, des recherches ont été
menées dans ce sens, pour plus de détails sur ce sujet nous orientons le lecteur sur les travaux
de Guetari [Guetari 1995]. L’un des avantages de l’approche orientée objets est la
combinaison des avantages des langages généraux (flexibilité et champ d’application larges)
avec les avantages des outils spécialisés (objets paramétrables et construction simple des
modèles).
4.4. Les langages de simulation

Il existe dans la littérature, peu d’analyses théoriques comparant les outils de simulation ou
les approches de modélisation et de simulation. Les analyses empiriques sont encore moins
nombreuses. Lyons et al. [Lyons et al. 2000] comparent trois approches à travers trois outils
de simulation : WITNESS, SIMNET II et OME13. Même si les trois simulateurs sont différents
dans leur approche de modélisation, ils sont capables de modéliser et simuler les systèmes
choisis par les auteurs. Une autre étude assez récente a été réalisée par Baines et al. [Baines et
al. 1998]. Les auteurs ont utilisé plusieurs techniques statiques et dynamiques pour modéliser
les flux d’un SdP de moteurs diesels, l’objectif étant l’estimation de l’aptitude de ces
techniques à évaluer des stratégies de production. Dans un autre article, les auteurs proposent
un cadre pour l’évaluation des outils de simulation [Hlupic et al. 1999]. Quelques études
moins récentes existent. Dans une étude de cas [Davis et al. 1994], les auteurs analysent 14
logiciels de simulation à événements discrets. Ekere et Hannan [Ekere et al. 1989] évaluent 4
langages de simulation en utilisant 25 cas de simulation différents. D’autres études concernant
l’évaluation de certains logiciels de simulation et des approches utilisées, existent aussi
[Banks et al. 1991] [Hlupic 1994] [Hlupic et al. 1995].
Plus de 100 logiciels de simulation sont disponibles sur le marché. Certains auteurs [Davis et
al. 1994] classent ces logiciels en deux catégories : les logiciels pour la simulation à
événements discrets et les logiciels pour la simulation à variables continues. Si le second type
est applicable pour un flux continu de produit et d’information, le premier est beaucoup plus
applicable dans les systèmes manufacturiers (composants, assemblages...). Nous proposons
dans ce qui suit deux autres classifications : l’une basée sur la spécialisation du logiciel et
l’autre basée sur l’approche de modélisation.
4.4.1. Classification des langages en fonction de la spécialisation
La multiplication et la diversification des langages utilisés pour la simulation ont fait

apparaître plusieurs familles. Si nous nous centrons sur la spécialisation de ces langages, nous
pouvons les classer en quatre familles : les langages universels ou évolués, les langages
généraux de simulation, les langages spécialisés de simulation et les langages dédiés.
13
OME – a network-driven simulation language and queuing modelling using Operations Management Expert.
) *+ , -
1/ Les langages universels ou évolués sont des langages de programmation répandus tels que
VB, FORTRAN, PASCAL, C, ADA, C++, JAVA... Ils ont l’avantage de permettre une
simulation précise et fiable de tout type de système, quel que soit son niveau de complexité.
Ils permettent de développer des modèles fonctionnels ou logico-mathématiques, grâce à la
richesse de programmation qu’ils offrent. Cependant, ils nécessitent des compétences
poussées et affirmées en simulation, en informatique et en génie industriel. Ils présentent
l’inconvénient du temps de développement et par conséquent du coût de réalisation. Les
modèles sont dédiés et généralement inexploitables dans des extensions futures.
2/ Les langages généraux de simulation sont des langages enrichis par des primitives
dédiées à la simulation en général, comme les générateurs de nombres aléatoires, les
processeurs de base pour la programmation de certaines entités... Ils ont ainsi l’avantage de
présenter une couche de base permettant de développer d’autres primitives pour la réalisation
de modèles de simulation dédiés. Nous pouvons citer, entre autres, SIM++ [Rose 1992] et
MODSIM II [Modsim 1995].
3/ Les langages spécialisés de simulation présentent un compromis entre la rapidité de

développement du modèle et la rigidité liée aux concepts utilisés. Les concepts utilisés sont
généralement basés sur la théorie des files d’attente et des processus stochastiques. La
modélisation se fait à l’aide d’éléments symboliques. Les modèles résultants sont de type
réseau (SLAM) [Pritsker 1986], des blocs représentatifs de processus (ARENA, GPSS,
WITNESS, SIMNET II) [Taha 1997] [Lanner 1998] [Lyons et al. 2000], ou des diagrammes
de cycle d’activités (HOCUS). Ces logiciels nécessitent une formation et de l’expérience, et
sont souvent utilisés par les consultants et concepteurs qui ont souvent recours à la simulation
pour des systèmes différents. L’utilisation de ces langages est conseillée quand une évolution
du modèle est nécessaire [Hollinger 1987] [Carrie 1988] [Ogle et al. 1991].
4/ Les langages dédiés sont adaptés aux systèmes ayant des caractéristiques identiques, et
sont dédiés à un type de système au fonctionnement bien défini ou à une classe de problèmes
[Kuljis 1994] [Hlupic et al. 1994]. La modélisation est basée sur l’aspect topologique
(représentation du système physique) à travers des éléments représentatifs du système réel.
Ces outils très conviviaux sont limités à un usage répétitif dans un domaine restreint [Law et
al. 1991]. L’avantage principal de ce type d’outil est la facilité d’utilisation, alors que
l’inconvénient majeur est la rigidité des modèles. Parmi les langages dédiés, citons à titre
d’exemple MAP/1 et SIMFACTORY.
Le tableau de la figure 1.3. propose une comparaison des langages de simulation classés selon
la spécialisation, en fonction de différents critères [Kieffer et al. 1991].
Famille des langages

Universels Généraux Spécialisés Dédiés
Rapidité de Très faible Faible Bonne Très bonne
modélisation
Convivialité Très faible Faible Bonne Très bonne
Critères
Flexibilité Très bonne Bonne Faible Très faible

Fidélité du Très bonne Bonne Fiable Dépend du
modèle système étudié
Niveau de Analyste Analyste orienté Spécialiste Utilisateur
compétence classique simulation simulation occasionnel
Figure 1.3. - Tableau comparatif des langages de simulation selon la spécialisation.
#
) *+ , -
La figure 1.4. montre l’évolution du critère convivialité en fonction du critère complexité

pour les 4 familles citées.
Convivialité
Langages dédiés
Langages spécialisés
Langages généraux
Langages universels
Complexité
Figure 1.4. - Comparatif convivialité/complexité des langages selon la spécialisation.
4.4.2. Classification des langages en fonction de l’approche de

modélisation
Les langages de simulation peuvent être classés en fonction d’autres critères. Roberts et al.
[Roberts et al. 1998] proposent une classification basée sur l’approche de modélisation et la
logique de changement d’état. Ils distinguent trois types de langages : les langages orientés
processus, les langages pilotés par les données et les langages orientés objets.
1/ Les langages orientés processus tels que SLAM II [Pritsker 1986] et SIMAN [Pegden et
al. 1990] ont respectivement les deux environnements graphiques : AweSim et ARENA. Ces
langages ont réduit avec succès les frontières de programmation et ont probablement fait que
la modélisation en simulation soit accessible à plusieurs utilisateurs non informaticiens.
Généralement, les langages orientés processus appartiennent à la catégorie des langages
spécialisés présentés précédemment.
2/ Les langages pilotés par les données représentent une abstraction de haut niveau du
système. SIMFACTRY [Tumay 1987] et PROMODEL [ProModel 1991] sont des exemples
de langages où le modèle de fond est difficilement modifiable [Bensen 1996]. Ces langages
comprennent des objets prédéfinis capables de réaliser une série d’opérations. La
modélisation consiste à sélectionner, interconnecter et renseigner ces objets (station,
convoyeur...) qui représentent au mieux le système réel. Ce type de langages nécessite peu de
programmation de la part de l’utilisateur, mais en revanche, ils sont spécifiques et ont une
flexibilité réduite. La plupart des langages pilotés par les données, utilisent un calendrier
d’événements qui stocke l’état du système à travers les valeurs associées aux attributs.
3/ Dans les langages orientés objets, les objets physiques et logiques du système réel
(produits, ressources, gammes...) sont représentés par des objets informatiques. L’approche
objet cherche à combler l’écart qui existe entre un modèle de simulation classique et le
système à étudier. Parmi les langages orientés objets, citons SIMULA [Dahl et al. 1966]
[Birtwistle et al. 1973], CLOS [Hollinger 1987], MODSIM [Modsim 1995]. Les figures 1.6
et 1.7 présentent un exemple qui montre la différence de modélisation entre l’approche
orientée processus et l’approche orientée objet sur la base d’un système simple (figure 1.5.).
%
) *+ , -
Arrivée des Stock Ressource de Evacuation

pièces production des pièces
Figure 1.5. - Système à modéliser.
Create Queue Seize Delay Release Dispose
Lancement des Attente Réservation, occupation pendant un temps Evacuation des

pièces à produire dans stock de traitement et libération de la ressource pièces du système
Figure 1.6. - Modèle orienté processus (SIMAN).
Création de Calendrier
Pièce pièces événements
Requête pour Programmer

traitement l’événement de
fin de traitement
Générateur
Placer pièce Requête de nombres
Queue Ressource
dans stock d’un nombre aléatoires
aléatoire
Figure 1.7. - Modèle orienté objet inspiré de [Roberts et al. 1998].
5. ETAT DE L’ART ACTUEL DE LA SIMULATION DANS LES SDPS
Les systèmes manufacturiers de la nouvelle génération seront conçus à partir de groupements

de ressources (sous-systèmes ou cellules), relativement simples, distribués, autonomes mais
coopératifs et organisés comme des entreprises virtuelles [Gindy et al. 1998]. Le processus de
conception des cellules, est dynamique, piloté par les objectifs, auto-optimisé et auto-
organisé. Les ressources sont combinées en vue d’accomplir une tâche ou une fonction. La
formation des cellules repose sur une stratégie collaborative pour l’utilisation de ressources
suffisantes et la réalisation des objectifs fixés. Des unités de production génériques seront
modélisées à l’aide de ressources élémentaires et seront associées pour former des
groupements à des niveaux hiérarchiques différents et appropriés au niveau de détail de
l’application. Voilà en quelques mots, d’après les auteurs, comment le SdP du futur pourrait
être, ainsi que la manière de sa conception et de sa modélisation.
Dans un article récent [Rooks 2000], Brian Rooks présente une étude intitulée « Winning
ways for manufacturing » qui analyse les travaux de la conférence « Winning Ways’99 »…
Des techniques et des approches dont certaines ont déjà fait preuve de réussite pourraient être
à l’origine de changements futurs dans les systèmes industriels, notamment : les centres
d’excellence, la simulation, les compétences multiples, l’automatisation intégrée totale, le
) *+ , -
commerce par réseau internet (e-business), la « lean14 and agile manufacturing », etc…
Certaines des entreprises représentées ont témoigné de leur évolution actuelle. Par exemple,
TRW Aeronautics a : fortement amélioré sa productivité, doublé ses ventes, quintuplé la
rotation de ses stocks, diminué ses temps de production de 6 mois à 7 jours... Les SdPs ont été
réorganisés en centres d’excellence. L’approche « one piece at a time material flow » a été
adoptée. La simulation a été utilisée dans un rôle privilégié pour : identifier les processus
individuels, optimiser le flux à travers le système, aider au dimensionnement des centres
d’excellence, évaluer le comportement du système global... Elle a aussi servi de support pour
la formation des opérateurs à l’ensemble du processus de fabrication dans un centre
d’excellence… Certains industriels ont prôné les opportunités de la « lean and agile
manufacturing » que le secteur industriel peut en bénéficier pour améliorer le service client et
la rentabilité des processus… Une intégration automatisée et totale à partir de l’atelier jusqu’à
la direction est nécessaire. Cette intégration doit s’étendre à l’extérieur de l’organisation
interne de l’entreprise à l’aide des réseaux de l’Internet qui sont devenus possibles grâce aux
développements réalisés ces dernières années… Dans la suite, nous synthétisons certains des
travaux de ces dix dernières années, portant sur la thématique de la simulation informatique
dans le domaine du génie industriel.
5.1. La simulation pour l’analyse et la conception des SdPs

Le concept de simulation utilisé comme un outil légitime pour la conception et l’analyse des
systèmes manufacturiers qu’ils soient nouveaux ou existants a été bien documenté [Paul
1991] [Chan et al. 1995] [Trego 1997] [Habchi 2000]... Law et Kelton déjà en 1991 [Law et
al. 1991] résument le paradigme de la croissance de l’utilisation de la simulation par quatre
raisons. La 1ère est la compétition dans l’industrie qui a poussé les industriels à améliorer la
productivité et la qualité et à réduire les coûts. La 2ème est la réduction des coûts dans le
secteur de l’informatique. La 3ème est l’amélioration des outils de simulation. Et la 4ème est la
disponibilité de l’animation graphique facilitant la compréhension de la simulation.
L’utilisation de la simulation pour la conception et l’analyse des systèmes industriels est

toujours privilégiée puisque des articles nombreux et récents portent sur ce sujet. En effet,
certains avantages pour la simulation des SdPs peuvent être avancés :
• la simulation réduit les risques de conception de systèmes qui ne fournissent pas une
flexibilité suffisante,
• un modèle de simulation peut représenter des caractéristiques importantes d’un système et
de manière réaliste ; il peut notamment incorporer des interactions complexes pouvant
exister entre différentes variables du système,
• différentes alternatives de conception peuvent être facilement évaluées dans un
environnement bien contrôlé,
• un modèle de simulation est capable d’utiliser les mêmes indicateurs de performance
qu’un système réel utilise.
14
Lean manufacturing est définie selon l’apics [APICS 1995] par : a philosophy of production that emphasizes
the minimization of the amount of all the resources (including time) used in the various activities of the
enterprise. It involves identifying and eliminating non-value-adding activities in design, production, supply
chain management, and dealing with the customers. Lean producers employ teams of multi-skilled workers at all
levels of the organization and use highly flexible, increasingly automated machines to produce volumes of
products in potentially enormous variety.
) *+ , -
Plusieurs travaux existent dans ce domaine. Nous proposons ci-après une synthèse de certains
de ces travaux. Ainsi, l’objectif de l’étude de Polajnar et al. [Polajnar et al. 1995] est
l’analyse de la productivité d’un système composé de quatre centres d’usinage flexibles tenant
compte du système de transfert des pièces en simulant différentes alternatives de transport. Le
modèle est développé avec SIMFACTORY II.5. Trois alternatives de transport ont été testées
(chariots filo-guidés, chariots à rails, convoyeurs). Les résultats ont montré que la productivité
est meilleure dans le cas des convoyeurs. Dans l’article suivant [Welgama et al. 1995], la
simulation est utilisée pour l’aide à la conception d’un système de produits chimiques, géré en
kanban. Deux alternatives ont été comparées. Les taux d’utilisation des opérateurs ont été
estimés et les résultats pourront être utilisés pour la conception de systèmes équivalents.
Chakravorty et al. [Chakravorty et al. 1995] présentent une étude réalisée avec SLAM II qui
compare deux types de gestion (le juste à temps et l’équilibrage de charge). Le système est de
type fermé (encours constant). Les ressources sont soumises à des défaillances aléatoires avec
deux niveaux de variabilité. Il a été conclu que dans le cas d’une variabilité faible, le juste à
temps fournit un temps de cycle plus faible, sauf dans le cas de très faibles encours. Dans le
cas d’une variabilité élevée, les résultats montrent que quand le niveau d’encours est faible
l’équilibrage de charge fournit un temps de cycle meilleur alors que le juste à temps fournit un
meilleur temps de cycle quand le niveau d’encours est plus élevé. L’article suivant [Saad et
al. 1998] concerne l’analyse d’un système d’assemblage hybride et flexible15. Une étude de
simulation et une analyse de la variance sont réalisées pour identifier les facteurs qui affectent
les indicateurs de performance. Une classification de ces facteurs est ensuite réalisée. Dans le
but de généraliser les résultats, d’autres configurations et d’autres niveaux de facteurs ont été
examinés. Marin et al. [Marin et al. 1998] proposent une étude de simulation pour l’aide à la
conception d’un système automatisé de stockage aérien. Le système doit répondre à plusieurs
contraintes : espace, temps de recherche des pièces, besoins clients... L’étude présente le
processus de décision et les solutions adoptées pour répondre aux spécifications. Un outil de
simulation intégré et orienté objet est présenté. L’article de Chan et al. [Chan et al. 1999]
concerne la conception de cellules de fabrication et d’assemblage à l’aide de la simulation.
Les objectifs de l’étude sont : l’évaluation de différentes alternatives de conception, la
prédiction de la performance, la détection de problèmes potentiels, l’expérimentation avec les
paramètres du système réel et la détermination de la sensibilité du système en fonction de ces
paramètres. Dans l’article d’Irani et al. [Irani et al. 2000], une étude de cas est réalisée pour
démontrer l’efficacité de la modélisation et la simulation pour le re-engineering des processus
manufacturiers. Le modèle est utilisé pour évaluer les possibilités d’amélioration du flux à
travers différentes stratégies. Caron et al. [Caron et al. 2000] proposent une approche de
simulation permettant de dimensionner des zones de stockage dans un système de triage
manuel.
5.2. La simulation pour le pilotage, l’ordonnancement et la

planification des SdPs
Dans le domaine du pilotage, la simulation a été traditionnellement utilisée pour l’aide à la
décision hors ligne. Le temps généralement mis en œuvre pour collecter les données était
l’une des barrières de son utilisation en temps réel. En effet, les mots clés en pilotage temps
15
Un système d’assemblage hybride et flexible est une ligne partiellement automatisée comprenant à la fois des
stations complètement automatisées et d’autres complètement manuelles. Les stations manuelles sont
généralement affectées à des tâches à faible coût, ayant un caractère variable et les tâches de contrôle
nécessitant des aspects intellectuels.
) *+ , -
réel sont : acquisition de données, analyse rapide et réaction quasi instantanée. Ainsi, les
principaux composants des systèmes de simulation en ligne discutés dans la littérature
consistent généralement en un module d’acquisition de données, un modèle de simulation et
une cellule de pilotage. Parfois, des modules tels qu’un système expert sont inclus pour
remplacer l’être humain.
Ces dernières années un certain nombre d’articles a été publié en pilotage temps réel. Ainsi, la
simulation en ligne a été utilisée dans un mécanisme de lancement d’OF16 dans un système
manufacturier flexible [Muller et al. 1990]. Rogers et Flanagan [Rogers et al. 1991] ont
développé un cadre pour un système de simulation en ligne pour l’ordonnancement en temps
réel. Récemment, Spedding et al. [Spedding et al. 1997] ont utilisé un modèle de simulation
avec ARENA lié au contrôleur d’une cellule d’assemblage de claviers informatiques pour
effectuer un pilotage adapté en temps réel. Un PC contrôleur supervise les changements d’état
de la ligne d’assemblage et fournit en temps réel les données collectées au modèle de
simulation. Un système d’aide à la décision pour l’ordonnancement (DSS17 ou DSSMS18)
dans un environnement job shop est proposé dans [Jacobs et al. 1994]. L’étude concerne
l’amélioration de l’ordonnancement de ce type de système à l’aide d’un modèle réalisé avec
SLAM II. Abdallah [Abdallah 1995] utilise un modèle de simulation basé connaissance pour
l’ordonnancement d’un atelier job shop. L’objectif est de trouver le meilleur ordonnancement
des OF en vue de satisfaire différents indicateurs de performance. Différentes règles ont été
utilisées et d’autres heuristiques de sélection ont été également élaborées. Dans l’article
suivant [Leu et al. 1995], les auteurs réalisent une étude comparative de différentes règles
(FCFS19, SPT20, CR21, SOT22, EDD23) dans un système flow shop. L’article de [Goyal et al.
1995] traite aussi du problème d’ordonnancement et propose une analyse de certaines règles
(FCFS, SPT, LPT24, SOT, EDD) à l’aide de la simulation dans un système manufacturier
flexible. L’article de [Huq et al. 1995] traite du problème de sensibilité de combinaison de
certaines règles d’ordonnancement (SPT, EDD, FIFO ou FCFS, LIFO25) dans un SdP job
shop et hybride. Les quatre règles ont été combinées avec la règle de Johnson ou entre elles
pour former huit combinaisons différentes. Le modèle de simulation a été réalisé avec SLAM
II. Lloyd J. Taylor [Taylor 1999] propose une étude comparative de trois méthodes de
pilotage des flux (flux poussé par MRP26, flux tiré par le Kanban27 et flux hybride poussé/tiré
par la TOC28). L’analyse statistique des données associées à cette étude a été réalisée grâce à
la simulation avec SIMFACTORY. Haslett et al. [Haslett et al. 2000] développent une théorie
de règles locales en utilisant les travaux de Kauffman et Holland sur les architectures
appropriées. Les auteurs présentent les résultats de simulation de ces règles utilisées par les
managers dans un SdP piloté par kanban.
16
OF – Ordre de Fabrication.
17
DSS – Decision Support System.
18
DSSMS – Decision Support System for Machine Scheduling.
19
FCFS – First Come First Served ou premier arrivé premier servi connue aussi par FIFO – First In First Out.
20
SPT – Shortest Processing Time ou temps de processus le plus court.
21
CR – Critical Ratio ou Ratio critique.
22
SOT – Shortest Operation Time ou temps opératoire le plus court.
23
EDD – Earliest Due Date ou date de besoin la plus proche.
24
LPT – Longest Processing Time ou temps de processus le plus long.
25
LIFO – Last In First Out ou dernier arrivé premier sorti.
26
MRP – Material Requirements Planning.
27
Kanban – Méthode japonaise permettant de piloter le flux en fonction de la demande des clients.
28
TOC – Theory Of Constraints (Théorie des contraintes).
&
) *+ , -
Traditionnellement, les décisions d’ordonnancement les plus critiques et les plus importantes
ont été considérées dans les stratégies de chargement des FMS [Denzler et al. 1987] [Garetti
et al. 1990] [Rachamadugu et al. 1994]. Un article récent [Pelagagge et al. 1998] reporte
une comparaison par simulation entre un chargement périodique conventionnel et un
chargement par groupes de travaux. Cette comparaison fournit des différences négligeables
sur la performance du système. Un autre article [Tabucanon et al. 1998] utilise la simulation
pour évaluer une approche de sélection du type de pièce dans un lot dans les FMS. L’objectif
est la maximisation du nombre de types d’articles dans un lot en tenant compte des
contraintes liées à la capacité du magasin d’outillage et la disponibilité des outils nécessaires.
Les auteurs de l’article suivant [Gindy et al. 1998] présentent un cadre conceptuel pour la
représentation des machines outils et d’usinage à l’aide d’éléments appelés « resource
elements » ainsi qu’une formulation mathématique permettant de calculer la flexibilité du
système manufacturier. La simulation est utilisée pour examiner la performance du système et
comparer l’ordonnancement utilisant ces éléments avec des approches conventionnelles.
Hoyt et Huq [Hoyt et al. 1999] présentent un modèle de simulation du processus administratif
interne d’une compagnie manufacturière aérospatiale dans des conditions de saisonnalité et de
variation de tâches complexes. En effet, il est connu que les modèles de simulation des
processus organisationnels sont un moyen très efficace pour étudier l’efficience des politiques
appliquées [Hansford et al. 1992]. La compagnie en question a initié un effort majeur de re-
engineering avec deux objectifs : la réduction des coûts aussi bien fixes que variables et
l’amélioration du taux de service client. Le modèle est réalisé en deux étapes : d’abord la
formalisation de l’information et des relations entre activités selon IDEF0 et ensuite la
modélisation en utilisant SLAMII.
5.3. Intégrations et approches hybrides de la simulation

Dans un premier article [Disney et al. 1997], Disney et al. utilisent conjointement un modèle
de pilotage en production et la simulation. Le modèle de pilotage est un système de
planification MRP (Manufacturing Resources Planning). L’optimisation du programme est
réalisée à l’aide d’un algorithme génétique. Dans un autre article [Soon et al. 1997], les
auteurs proposent une approche d’ordonnancement hybride basée sur l’utilisation de la
simulation et les réseaux de neurone. A cet effet, des réseaux de neurone sont développés
pour analyser une information complexe concernant les OF et suggérer des règles
d’ordonnancement au modèle de simulation. Les auteurs de l’article suivant [Brennan et al.
1999] utilisent la simulation pour mettre en place un cadre de pilotage permettant de supporter
un système manufacturier à production « sensible ». Le cadre proposé combine à la fois
l’information transitoire et l’information stable. Il a été montré qu’une utilisation appropriée,
à base de logique floue et de la simulation, fournit des performances meilleures que celles
obtenues en se basant exclusivement sur l’une ou l’autre information. Dans l’article de
[Jahangirian et al. 2000] nous trouvons une proposition d’un cadre pour définir des
stratégies d’ordonnancement en deux modules couplés : l’un sur la simulation intelligente et
l’autre sur l’apprentissage incrémental piloté par un algorithme génétique. Pour générer une
solution, le module d’apprentissage conduit un processus incrémental et intercepte le
problème dans un espace de recherche étendu. D’autres travaux couplant simulation et
algorithmes génétiques existent [Pierreval et al. 1990]. Y. Ito [Ito 2000], considère dans son
article une application d’une politique de pilotage adaptative aux systèmes à entrées-sorties
dynamiques de l’industrie japonaise en utilisant les réseaux de neurone et la simulation.
L’article de Blosch et al. [Blosch et al. 1999] décrit une étude de cas concernant le système
!
) *+ , -
de planification de la marine royale, l’objectif étant de fournir une main d’œuvre suffisante
pour les engagements opérationnels et structurels. L’expérimentation réelle n’étant pas
possible, un modèle de simulation a été développé et les essais ont été mis en place grâce à un
plan d’expérience. L’étude montre comment les deux techniques ont été appliquées et des
variables de risque ont été identifiées. Spedding et al. [Spedding et al. 2001] proposent dans
un article récent une méthodologie systématique et informatisée permettant de configurer les
cartes de contrôle. Une ligne de production a servi de plate-forme de simulation pour
construire un système de cartes de contrôle à l’aide de plusieurs scénarios. La méthode ABC29
a été utilisée pour l’analyse des résultats.
5.4. La simulation pour l’enseignement et l’apprentissage

La simulation est l’une des disciplines les plus utilisées en science de management. Son
enseignement a traditionnellement impliqué le développement de modèles aussi bien
théoriques que pratiques. Avec l’avènement d’outils modernes, le développement de modèles
pratiques peut être entrepris, mais un certain niveau de connaissance en théorie de simulation
reste nécessaire. L’objectif de l’article de Lehaney et al. [Lehaney et al. 1998], est de montrer
que les utilisateurs ayant des faibles connaissances en simulation peuvent apprendre à utiliser
rapidement des outils tels que les « windows-based simulation software » pour le
développement de leurs modèles. Les auteurs clament que ce type d’outils est connu pour son
aide en réduisant la charge cognitive de l’utilisateur et en lui fournissant un certain niveau
d’auto-contrôle. Dans un article plus récent sur l’exploration de l’apprentissage à l’aide de la
simulation d’entreprise [Gopinath et al. 1999], les auteurs focalisent leur étude sur la
capacité des participants à traduire les stratégies d’une compagnie en une série de décisions
dans un modèle de simulation. Le caractère itératif et expérimental de la simulation renforce
les objectifs de l’enseignement considéré. Les résultats de l’étude montrent qu’il est
encourageant d’utiliser la simulation dans la prise de décision stratégique à long terme, la
simulation d’entreprise est un moteur d’apprentissage expérimental. Dans l’article suivant
[Altmyer 2000], l’auteur démontre comment des méthodes non traditionnelles créent un
environnement d’enseignement à réussite renforcée. L’exemple utilisé concerne la gestion de
stocks à l’aide de la simulation. Les participants travaillent par groupes et recherchent les
meilleures stratégies à appliquer. A travers la recherche de solutions, des idées critiques et un
raisonnement déductif sont développés. Aussi Doyle et al. [Doyle et al. 2000] utilisent la
simulation en tant que jeu de stratégie d’affaire pour fournir aux joueurs l’expérience dans le
développement et l’implémentation des stratégies. Les participants simulent leur compagnie
dans un environnement de compétitivité. Le jeu de simulation est international et il a été
appliqué par vidéoconférence entre des groupes se trouvant dans différents pays : France,
Irlande et USA.
6. QUELQUES-UNES DE NOS CONTRIBUTIONS A LA RECHERCHE EN

SIMULATION
La recherche en simulation connaît depuis le milieu des années soixante un essor mondial
important. En France, les travaux de recherche en simulation des SdPs, sont relativement
récents et sont restés pendant un certain temps « au coup par coup ». Néanmoins, ces
29
ABC – Activity Based Costing.
"
) *+ , -
dernières années, des équipes se sont mises en place dans plusieurs laboratoires et
s’intéressent de plus prêt à ce domaine.
De manière non exhaustive, nous pouvons citer certains de ces travaux. Ainsi, il y a ceux qui
portent sur la problématique de l’ordonnancement d’atelier par simulation déterministe,
utilisant une modélisation par objet et une approche par événements discrets [Boukachour
1992] [Boukachour et al. 1993], ou sur le développement d’un simulateur de gestion d’un
terminal à conteneurs en utilisant la simulation discrète par macro-processus et processus
complémentaires [Serin et al. 1996]. D’autres travaux portent sur la conception d’un système
intégré de simulation des SdPs [Lenclud 1993], où le concept d’UFP est développé (Unité
Fonctionnelle de Production). Certains travaux sont orientés sur la thématique de
modélisation, organisation et pilotage des SdPs [Pierreval 1987] [Pierreval 1990] [Paris et
al. 1998] [Pierreval et al. 1998] [Tautou et al. 1998] [Pierreval 1999]. Et d’autres portent
sur la conduite des systèmes manufacturiers flexibles, où une approche mixte objets / réseaux
de Petri a été développée pour la simulation et la conduite [Ait Hssain 1993]. Et encore
d’autres travaux étudient le comportement du temps dans les systèmes informatiques pendant
une simulation [André et al. 1993]...
Pour nous, la recherche effectuée dans le domaine de la simulation, n’est pas une fin en tant
que telle. Elle est effectuée dans un but précis : faire émerger et utiliser les potentialités de la
simulation de manière à contribuer plus largement à l’étude des SdPs. L’utilisation des
potentialités de la simulation ne se fait qu’à travers une recherche approfondie sur les
concepts de base et leur manipulation, sur la simplification et l’automatisation du processus
global de simulation. Les travaux réalisés dans le cadre des thèses de doctorat encadrés au
LLP/CESALP vont dans ce sens (thèses de M. Bakalem et C. Berchet). Une synthèse de ces
travaux de recherche sera développée dans les deux chapitres suivants.
Toutefois, avant de clore ce chapitre, nous présentons une synthèse succincte de différents
travaux de recherche personnels ou collectifs (projets, encadrements de DEA, applications
industrielles...). Ces travaux qui portent sur des sujets relativement particuliers (évaluation de
performances, étude de certains paramètres, aide au pilotage, intégration des plans
d’expériences...) montrent l’importance de l’apport de la simulation dans l’étude des SdPs et
font découvrir les lacunes qui existent dans cette discipline.
6.1. Influence de la taille des lots

L’influence de la taille des lots [Labrune 1993] [Habchi et al. 1995] sur les performances
des SdPs de type « job-shop » reste d’actualité. Ce sujet est un problème réel auquel sont
confrontés les responsables de production en particulier quand une politique de juste à temps
est adoptée. Ceci nécessite simultanément une réduction des tailles de lots et une
augmentation du volume de production. L’originalité de l’étude menée réside dans la méthode
utilisée pour analyser l’impact de la taille des lots et des changements de série sur la
conception et l’optimisation des systèmes manufacturiers à sections homogènes. Connaissant
certaines données concernant les produits et ressources (types, gammes, temps de traitement,
prévisions), il s’agit d’optimiser des tailles de lots qui permettent d’améliorer la conception du
système. Cette optimisation est réalisée en deux étapes : d’abord en considérant un système
mono-produit sans temps de changement de série et ensuite un système multi-produit à
gammes différentes et temps de changement de série. Les deux étapes sont effectuées dans le
cas d’un flux d’entrée supposé constant et dans le cas d’un flux variable. Pour déterminer une
&$
) *+ , -
taille de lot optimale, nous avons défini un critère de performance agrégé et basé sur les trois
critères suivants : production totale, temps de production moyen, taux d’activité moyen du
système.
L’étude a montré que dans les différents cas étudiés, il est possible de définir une taille de lot
optimale. A partir de cette taille, pour des tailles supérieures, les temps de production et les
stocks d’en-cours augmentent alors que la production totale et le taux d’activité du système
diminuent. Inversement, pour des tailles inférieures, la production totale et l’utilisation
moyenne diminuent rapidement entraînant des temps de production plus longs et des stocks
d’encours plus élevés. Aussi, cette étude a permis d’équilibrer la capacité des différents
centres de charge pour mieux concevoir le système.
6.2. Intégration des plans d’expériences à la simulation

La méthode des plans d’expériences [Kleijnen 1987] [Carbone 1994] [Sénéclauze 1995]
[Habchi et al. 1996] planifie de façon rigoureuse les essais en vue d’un objectif parfaitement
défini. Elle réduit le nombre d’essais en permettant une interprétation rapide et sans
équivoque des résultats des essais et en fournissant un modèle théorique du système étudié. Si
la simulation est associée à cette technique, nous pourrons éviter certaines opérations
répétitives et ainsi gagner en efficacité et en rapidité. Les avantages de la simulation sont
largement connus, cependant des problèmes apparaissent principalement dans la planification
des expériences et l’analyse des résultats. Les plans d’expériences et la simulation, pris
séparément, ont déjà fait leur preuve, mais ils sont rarement combinés. Par ces travaux, nous
cherchons à coupler les deux techniques de manière informatique et montrer ainsi les
avantages qui en découlent.
La méthodologie utilisée peut être décrite en trois étapes :

• configuration des plans d’expériences (choix des conditions initiales, des facteurs et de
leurs niveaux, des variables et indicateurs de sortie),
• modélisation du système, lancement des expériences selon l’étape précédente, et
enregistrement des résultats,
• exploitation et analyse des résultats (calcul des effets et interactions des facteurs, calcul de
la réponse théorique, calcul des résidus, analyse de la variance, transformation de la
réponse expérimentale, présentations graphiques des résultats).
Le SdP choisi pour l’étude est un système multi-produits à cinq sections homogènes. La
production par lots se fait sur trois types de produits. Le transfert entre les sections se fait par
lots identiques aux lots de traitement. Pour étudier la capacité optimale de chaque section en
fonction de la demande de production, nous avons défini un plan d’expériences de 5 facteurs à
3 niveaux chacun. Les facteurs représentent les sections et les niveaux représentent leurs
capacités. Normalement le nombre total d’expériences à effectuer est égal à 35, soit 243. En
négligeant les interactions d’ordre trois et plus, nous adoptons un plan d’expériences
fractionnel de 81 expériences (3 fois moins). Différents indicateurs élémentaires sont utilisés
pour mesurer l’impact de chacune des expériences : production totale, temps de production
moyen, taux d’activité moyen du système, encours en fin de simulation. Des indicateurs plus
complexes combinant ces indicateurs élémentaires sont également utilisés. Après réalisation
des expériences et analyse de la variance, nous avons déduit les facteurs significatifs pour
chacune des réponses et proposé une fonction transformée de la réponse expérimentale,
minimisant la variance résiduelle et montrant une distribution normale des erreurs. Du fait que
&
) *+ , -
les objectifs liés à certains indicateurs sont antagonistes (problèmes omniprésents dans les
systèmes industriels), plusieurs solutions sont possibles. En effet, une solution dépend du type
de l’indicateur ; par exemple pour augmenter le taux d’activité des sections il faut diminuer
leur capacité alors que pour réduire les encours il faut l’augmenter. Cette étude a montré le
rôle important de l’intégration d’un plan d’expériences à la simulation sur plusieurs points :
méthodologie et structuration des expériences, réduction des essais, analyse des résultats,
optimisation...
6.3. Influence des règles d’ordonnancement

Ce travail de recherche concerne une étude de simulation sur un système manufacturier à
sections homogènes évoluant dans un environnement à la commande [Habchi 1997]. La
simulation largement utilisée pour aider à la conception d’un système, valider une logique de
production, appréhender la dynamique du flux physique… est exploitée ici pour aider à
l’optimisation de la production d’un programme de commandes clients. L’optimisation
recherchée est basée sur l’utilisation combinée de certaines règles de priorité élémentaires à
caractère aléatoire, statique et dynamique (FIFO, date de besoin la plus proche, ratio critique,
marge la plus faible, temps de processus le plus court).
Dans le modèle réalisé, nous appliquons par combinaison des règles de priorité de portée
globale à l'ensemble du programme de production et de portée locale à chaque file d’attente
devant les centres de charge du système. A chaque arrivée d’une commande devant un centre,
une décision d’ordonnancement s’impose et l’ordre des commandes est remis en cause. La
décision est prise en considération par application de la combinaison des règles choisies. Le
classement du programme de commandes de portée globale est d’abord effectué avant le
lancement en fabrication, en utilisant l’une des règles citées précédemment. Ensuite, le
classement de portée locale est appliqué au niveau des files d’attente avant exécution des
opérations, en utilisant l’une des trois règles suivantes : groupement des lots par séries de
même type, temps opératoire le plus court, même règle utilisée au niveau global.
Les résultats des différentes stratégies de production ont été analysés par l’introduction d’un
nouvel indicateur fédérateur et normalisé utilisant des indicateurs aussi normalisés et
pondérés. Cette pondération permet à l’utilisateur de valoriser cet indicateur en fonction de
ses objectifs.
L’étude a permis de proposer un classement optimisé des ordres de fabrication et de trouver

des conditions améliorées pour une production à la commande. L’effet d’une règle peut varier
en fonction de la production et peut être également contradictoire en fonction du critère de
performance choisi. De ce fait, l’utilisation de l’indicateur agrégé qui combine des indicateurs
élémentaires est important dans le choix d’une stratégie de production. La dynamique de la
règle n’apparaît pas comme un élément prépondérant dans son choix, car la règle statique de
la date de besoin a montré des résultats identiques à la règle dynamique de la marge. La règle
dynamique du ratio critique a montré des résultats médiocres, parfois équivalents à ceux de la
règle aléatoire FIFO. La règle du temps de processus le plus court a fourni des résultats
moyens. Actuellement, le modèle a été amélioré par l’introduction de l’effet combiné de la
date de lancement des commandes et des règles de priorité, il est utilisé en enseignement.
&#
) *+ , -
6.4. Etude de la variabilité des temps de processus

La variabilité des temps de processus [Habchi 1998] sur des ressources unitaires, peut
entraîner des effets inverses à la régulation de flux (réduction des stocks devant certaines
ressources, augmentation devant d’autres) entraînant ainsi des ralentissements, des ruptures,
des surcharges, des délais longs... Nous avons focalisé cette étude sur l’influence de la
variabilité des temps de processus, dans le cas d’une loi uniforme, sur le flux d’une ligne de
production avec stocks. Le SdP modélisé est une ligne pouvant avoir jusqu’à 15 stations de
travail indépendantes. Toutes les stations sont similaires du point de vue temps de processus,
et un produit ne subit qu’une opération par station. Chaque station de travail possède un stock
d’encours en amont pour recevoir les produits à traiter.
L’étude est organisée en quatre étapes :

• étude de l’influence de la position, dans la ligne, d’une station ayant un temps de
processus variable, toutes les autres ayant un temps constant,
• étude de l’influence de l’étendue de variabilité, toutes les stations ayant la même étendue,
• étude de l’influence de la position d’une station dans la ligne ayant une étendue de
variabilité plus large que les autres,
• détermination des encours supplémentaires pour maximiser le taux d’utilisation des
stations, toutes les stations ayant la même étendue de variabilité.
L’analyse des résultats de l’étude a montré que :

• la variabilité des temps de processus réduit la production, augmente les encours et les
temps de production,
• la production d’une ligne est maximale si la station variable est en début de la ligne,
• lorsque toutes les stations sont variables, la production diminue si le nombre de stations
augmente et si l’étendue de variabilité augmente,
• la position d’une station ayant une variabilité supérieure aux autres n’a pas d’effet sur le
flux de production,
• pour maximiser le taux d’utilisation des stations, des encours supplémentaires augmentent
avec l’étendue de variabilité,
• des encours supplémentaires n’augmentent pas la production si l’étendue est très
importante.
7. CONCLUSION
Dans ce premier chapitre, nous avons cherché à positionner notre thématique de recherche à
travers une synthèse couvrant : d’abord, les systèmes de production et l’évaluation de leur
performance et ensuite, la simulation informatique et son état de l’art actuel dans le génie
industriel. Quelques travaux ponctuels (personnels ou collectifs) portant sur cette thématique
sont également avancés pour illustrer une partie de nos préoccupations scientifiques de
l’utilisation de la simulation dans les systèmes de production, et montrer aussi l’étendue des
problèmes industriels qui pourraient être étudiés à l’aide de cette technique.
Ce positionnement thématique centré sur la simulation informatique d’une part, et sur les
systèmes de production d’autre part, nous permettra dans le chapitre suivant, de réaliser
d’abord, une analyse des limites et des problèmes actuels et de proposer ensuite, certains
&%
) *+ , -
concepts que nous estimons capables d’exploiter encore plus de potentiels de la simulation.
En effet, ces concepts sont orientés d’une part, pour privilégier une utilisation potentielle par
des personnes non-spécialistes et d’autre part, pour permettre d’introduire un processus de
pilotage que nous estimons nécessaire à toute modélisation efficace d’un système de
production.
&
! +(
1. INTRODUCTION
L’amélioration et l’accroissement de la réactivité et de la compétitivité d’une entreprise passe

notamment par deux actions simultanées et complémentaires :
• l’amélioration de sa productivité directe par des investissements assez conséquents dans
des SdPs flexibles et automatisés,
• l’amélioration de ses structures par l’adoption d’une organisation rationnelle, conduisant
à une réduction des stocks, des délais et des coûts et une amélioration de la qualité.
Si la première voie est souvent difficile à réaliser par manque de trésorerie, la seconde est plus
facile si on fait appel à l’imagination et la compétence, qui permettent de générer des gains
importants et ainsi investir dans la première voie. Cependant, l’imagination et la compétence
sont des conditions nécessaires mais elles ne sont pas suffisantes pour gérer un SdP et prévoir
l’impact d’une décision sur son comportement. Cette difficulté s’explique par plusieurs
raisons :
• les objectifs souvent antagonistes des différents services de l’entreprise,
• le nombre élevé de paramètres et d’hypothèses,
• la complexité dynamique des systèmes,
) # * ) ) . +
• l’automatisation des processus rendant difficile le contact entre ressources humaines et

ressources physiques,
• le caractère aléatoire concernant la globalité des ressources et des services de l’entreprise.
En l’absence de modèles analytiques puissants, la simulation reste l’approche la plus utilisée

pour la modélisation et l’évaluation des performances des systèmes complexes. Les travaux
de recherche nationaux et internationaux abordés dans ce domaine ne cessent de croître et
d’évoluer, pour répondre aux lacunes et limites de la simulation.
Les lacunes et limites avancées dans nos travaux sont de deux natures : celles liées à
l’approche de modélisation et celles liées à l’utilisation de l’outil. Suite à une analyse des
SdPs dans une optique de simulation, nous avons dégagé certains critères pour améliorer
l’efficacité, d’une part du processus de simulation (surtout l’approche de modélisation) et
d’autre part de l’utilisation de l’outil de simulation. Cette analyse a essentiellement permis de
décomposer le SdP de manière proche à la simulation. Ainsi, des concepts génériques et une
approche de modélisation, structurée selon le point de vue de l’utilisateur potentiel, sont
proposés pour pallier les lacunes liées à l’approche de modélisation et prendre en compte les
critères d’efficacité abordés. Les concepts proposés sont fondés sur une approche d’analyse
hiérarchique du SdP, à la fois concernant la représentation des ressources et leurs états ainsi
que les entités. Ces concepts concernent le processus de fabrication, le processus de pilotage
associé ainsi que les relations d’échange entre les deux processus. Ces concepts sont spécifiés
et modélisés selon l’approche orientée objet. Un modèle est construit en utilisant le langage
UML (Unified Modeling Language) et une plate-forme de simulation baptisée Apollo est
développée ensuite sur JAVA.
2. ANALYSE DES POTENTIALITES ET DES LIMITES DE LA

SIMULATION DES SDPS
2.1. Potentiels et apports de la simulation

Si la simulation est une technique de plus en plus utilisée dans le milieu industriel, en
devenant l’outil de base des ingénieurs, il n’en demeure pas moins qu’elle reste encore mal
maîtrisée dans certaines entreprises. Pourtant, nombreuses sont celles qui sont amenées à
concevoir ou à faire évoluer des SdPs et qui doivent se poser des questions décisives du type :
la gestion appliquée sur cette ligne de production est-elle bien adaptée ? les paramètres de
gestion choisis sont-ils les meilleurs ? le pilotage appliqué est-il bien adapté ? comment
convaincre le responsable du budget qu’il devient indispensable d’investir dans telle ou telle
ressource ?... La simulation est l’un des outils qui peut aider à répondre à ces questions. De
grandes entreprises françaises ou étrangères ont d’ores et déjà franchi le pas et adopté depuis
quelques années la simulation : CITROEN, SNR ROULEMENTS, SOLLAC, SCHNEIDER
ELECTRIC, TEFAL,... Chez RENAULT par exemple, toute ligne de fabrication ou
d’assemblage est simulée avant d’être conçue.
Les potentiels de la simulation sont vastes. Tout d’abord, elle peut couvrir tous les flux de
l’entreprise, puisqu’elle est capable de représenter : les flux physiques pour lesquels elle est
&
) # * ) ) . +
le plus souvent utilisée, mais également les flux informationnels et les flux décisionnels
associés à ces flux physiques.
D’autre part, elle peut représenter ces flux selon différents niveaux de granularité. Elle permet
ainsi de décrire le système avec le degré de détail et de précision nécessaires et convenant à la
résolution du problème posé : au niveau d’une machine, d’une ligne de production, d’un
atelier, d’une usine,... Elle peut représenter ainsi un flux de produits, avec un détail à la pièce
et au niveau de la machine, ou un lot au niveau de la ligne, ou un ordre de fabrication au
niveau de l’atelier,... Cette représentation hiérarchique peut tenir compte des horizons
temporels. Le long terme par exemple, où on cherchera à évaluer l’impact de nouveaux
produits, ou de nouvelles prévisions, ou de nouveaux investissements,... Les travaux de
Cumenal [Cumenal 1997] par exemple, illustrent l’utilisation de la simulation d’un point de
vue stratégique. Ainsi, le simulateur SAXSO fait « vivre une organisation sur une longue
durée, afin d’analyser les réussites et les échecs des transformations de l’organisation ». Ceci
permet, entre autres, d’identifier les facteurs de développement et d’inhibition de
l’organisation, d’apprendre aux managers à gérer et à maîtriser les changements de
l’organisation à travers le temps, de les éclairer sur les comportements et les styles de
management des hommes… Le moyen terme par exemple, pour évaluer la main d’œuvre, les
programmes de production,... Le court terme pour évaluer des programmes de travail, des
niveaux de stocks, des programmes de production à capacité finie,... Le temps réel pour aider
au pilotage d’atelier et la prise en compte des aléas de production.
Enfin, toutes les phases du cycle de vie d’un SdP pourraient être couvertes par la simulation :
la conception, la réalisation et l’exploitation. Depuis qu’elle existe, la simulation s’est
particulièrement imposée durant la phase de conception du système [Habchi et al. 1992]
[Chau et al. 1994] [Khalfoun et al. 1995]… Chaque fois que les tests s’avèrent négatifs, il
faut concevoir et tester à nouveau. Si les résultats négatifs persistent, il faut alors revoir la
phase d’analyse et les objectifs du cahier des charges. Pour une conception préliminaire, des
premières simulations permettent de définir les caractéristiques globales de l’atelier et de faire
le choix entre des projets contrastés. Dans la phase de réalisation, la simulation est de plus en
plus utilisée, particulièrement pour la formation du personnel. Dans cette optique, la
simulation constitue un excellent moyen pour familiariser le personnel avec le système. Sa
contribution est une aide au diagnostic. Un modèle de simulation de l’atelier en réalisation
permet de détecter ses potentielles « faiblesses » : existence de machines goulots, fluidité
faible des pièces, nombre insuffisant de palettes,... Les choix entre diverses propositions,
définies à la suite du diagnostic, pourront alors être testés, évalués et chiffrés. La solution la
plus adaptée pourra ainsi être retenue et l’amortissement calculé. Dans la phase
d’exploitation enfin, la simulation est en passe de s’imposer. Elle évolue et, les simulateurs
devenant de plus en plus performants et ergonomiques, elle est de plus en plus utilisée en tant
qu’outil d’aide au pilotage des systèmes [Habchi et al. 1995]. Les principaux apports de la
simulation au cours de l’exploitation concernent la détection des goulets sur les ressources,
l’analyse des encours et des méthodes de gestion, l’anticipation des décisions qui sont souvent
d’une inertie très importante,... La simulation vise à ce niveau, deux objectifs :
• apporter une aide à la génération de la structure décisionnelle, grâce à différents plans
d’actions,
• permettre une certaine prévision sur l’évolution du système en évaluant l’effet de divers
paramètres (coefficient de retard, panne ressource, absentéisme,...).
Ces deux objectifs impliquent la mise en œuvre de plusieurs facettes du potentiel de la

simulation :
&&
) # * ) ) . +
• l’évaluation de la performance,
• l’évaluation de la décision et du plan d’actions correspondant,
• les conséquences de la mise en place des plans d’actions choisis.
La simulation permet d’autre part, en cours d’exploitation, l’évaluation et la comparaison de

différentes stratégies de pilotage afin de choisir la plus performante. Ainsi, il est possible suite
à un diagnostic, de tester diverses solutions, divers paramétrages et d’appliquer la meilleure
solution en temps réel. Cette aide au pilotage d’atelier par la simulation sera possible grâce à
la modélisation et la simulation du processus de pilotage d’un SdP.
2.1.1. Apports de la simulation
Grâce à l’étude bibliographique réalisée, nous pouvons synthétiser les principaux apports de
la simulation dans le domaine des SdPs.
• Mise en œuvre accélérée : le changement de gestion d’une ligne de fabrication, une

nouvelle implantation d’atelier,... suppose souvent une phase expérimentale dans laquelle
il faut tester les nouvelles données, et où l’on avance souvent par tâtonnement, afin
d’optimiser au plus vite les flux. Cette phase peut être réduite en étant préalablement
simulée.
• Evaluation de la performance par avance : il est possible de mesurer puis évaluer des
performances par l’intermédiaire de divers indicateurs de performance (quel en-cours,
quel risque de rupture, quel niveau de stock, ... ?).
• Conception, modification et dimensionnement par anticipation : chacun des choix
(gestion, paramétrage, ...) pouvant être réalisé au cours de la conception, suite à une
réorganisation, un re-dimensionnement, une modification, et ayant un impact sur
l’exploitation, mérite d’être évalué au préalable grâce à la simulation.
• Comparaison d’alternatives de gestion ou évaluation de l’influence de certains
paramètres de gestion : avant même d’avoir fait le choix d’un type de gestion et de
l’avoir appliqué, il est intéressant de tester plusieurs alternatives possibles.
• Support de formation : un modèle de simulation peut sensibiliser l’utilisateur à une
nouvelle logique de fonctionnement de l’atelier et peut l’aider à mieux le maîtriser.
• Outil de médiation : l’utilisation d’un simulateur peut servir de négociation, de base de
discussion entre intervenants, en illustrant les conséquences des hypothèses en discussion.
• Rôle de macroscope et/ou de microscope : la simulation permet une vision globale du
système étudié, ce qui est particulièrement intéressant quand le système est complexe,
et/ou quand la taille réelle est très importante. A l’inverse, la simulation permet de réaliser
des zooms importants liés au niveau de détail adapté.
• Aide à la formalisation des données pour la production : la simulation permet de
rassembler les données utiles à la production autant pour un système existant que pour un
système en projet. Ces données seront ainsi formalisées en vue de leur exploitation dans
un modèle.
2.2. Limites actuelles de la simulation

L’utilisation de la simulation reste assez restreinte malgré ses potentiels et ses apports mis en
évidence. Ainsi, comme nous l’avons souligné, les potentiels de la simulation sont très larges
&!
) # * ) ) . +
Toutefois, elle est davantage utilisée, en phase de conception. Elle l’est beaucoup moins lors
de la phase de réalisation et d’exploitation du système,... Mais, elle pourrait être tout aussi
bien un outil très performant et utile lors de ces phases, si elle était utilisée pertinemment
[Kosturiak et al. 1998]. Cependant concrètement aujourd’hui, ce potentiel n’est pas appliqué
dans sa totalité [Vernadat 1999].
Aussi, comme nous l’avons souligné dans le chapitre précédent, le processus de simulation
soulève certaines limites dans ses différentes étapes. Ces limites constituent certaines raisons
pour lesquelles l’utilisation de la simulation reste un domaine plus ou moins réservé aux
experts. Nous classons certaines de ces limites en deux catégories [Bel et al. 1990] [Fritschy
1990] [Lenclud 1993] [Bakalem 1996] [Berchet 2000] : les limites liées à l’approche de
modélisation et celles liées à l’étape de programmation.
2.2.1. Limites liées à la modélisation
Les limites de la simulation liées à la phase de modélisation peuvent être décomposées en

plusieurs points.
Absence de cohérence entre les deux modèles statique et dynamique.

Elle est souvent due à l’utilisation de formalismes différents. En effet, le modèle statique
décrit des caractéristiques structurelles alors que le modèle dynamique décrit le comportement
dynamique. Certaines tentatives ont été faites pour coupler des méthodes d’analyse avec des
modèles de simulation. Le succès est limité car les concepts utilisés sont différents et adaptés
à un type de processus : physique, informationnel ou décisionnel [Pierreval 1987] [Corthier
et al. 1991] [Kellert 1992].
Manque de méthodologie pour l’élaboration du modèle.

La plupart des langages de simulation offrent des fonctions ayant une correspondance très
limitée avec les éléments du système réel. Pour construire un modèle, la manipulation de ces
fonctions nécessite une expérience approfondie de la part de l’utilisateur et renforce l’idée de
spécialisation de la simulation.
Manque de propriétés nécessaires à l’approche de modélisation.

Les langages de simulation manquent certaines propriétés qui sont fondamentales telles que ;
l’affinage, la modularité, la réutilisabilité, la flexibilité… En effet, ces propriétés sont
nécessaires à l’approche de modélisation qu’elle soit itérative, modulaire ou progressive. La
tendance actuelle privilégie l’approche modulaire et hiérarchisée qui fournit un fil conducteur
à l’élaboration du modèle sur plusieurs niveaux. Ces niveaux représentent le système en allant
du plus abstrait au plus concret.
Manque de concepts universels et potentiels.

La plupart des concepts utilisés par les langages font référence aux files d’attente, à la notion
de processus, aux réseaux de Petri... L’utilisation de ces concepts, difficilement assimilables
par les utilisateurs potentiels, limite le champ de la simulation et constitue souvent un obstacle
à la compréhension du système étudié. La tendance actuelle est plutôt orientée vers des
concepts proches de la perception des utilisateurs. L’orientation objet favorise fortement cette
approche.
&"
) # * ) ) . +
Manque de structures d’affinage et de réutilisation de modèles existants.

L’affinage des modèles est basé en grande partie sur l’expérience des utilisateurs. Les
structures hiérarchiques permettant un affinage progressif sont quasi inexistantes. Des
modèles nouveaux sont entièrement reconstruits même pour des systèmes très similaires. Ceci
pose le problème d’évolutivité qui s’ajoute à celui du manque de généricité (il est impossible
de considérer autant de concepts spécifiques que de processus et de stratégies).
Manque de concepts pour la modélisation du processus de pilotage.

La modélisation du processus de pilotage est l’une des tâches les plus difficiles à réaliser. On
constate à travers des langages existants que la modélisation du processus de pilotage est
quasi inexistante. L’utilisation de certaines fonctions permettant de réorienter le flux physique
se fait de manière imbriquée avec les autres fonctions. La gestion des échanges
informationnels et décisionnels entre le processus de pilotage et le processus de fabrication
n’est pas prise en compte. Ceci rend complexe l’évaluation de l’impact du pilotage sur les
performances du système. Les activités de décision sont donc beaucoup moins bien
appréhendées, alors qu’il est toujours nécessaire de les prendre en compte dans un modèle de
simulation, soit pour les reproduire afin de refléter au mieux la réalité, soit pour les évaluer.
Par ailleurs, si les décisions sont parfois simples, elles peuvent aussi être complexes, car elles
résultent de l’analyse de l’état du système et dépendent de raisonnements experts. A l’image
d’un système d’indicateurs de résultats ou d’un bilan comptable, la simulation est dans ce cas
« passive », elle ne permet que de constater. Davis et Williams [Davis et al. 1994] soulignent
bien cet état en écrivant que la simulation focalise sur la formulation et la solution des
problèmes en utilisant des méthodes par tâtonnements.
2.2.2. Limites liées à l’outil informatique
L’une des limites liées au support informatique concerne le manque d’interactivité pour l’aide
à la modélisation. La possibilité d’intervenir durant la simulation sur le modèle de façon
intelligente, suite à l’application d’un plan d’action, résultat du processus de pilotage, devrait
être possible. Or cette interactivité n’est pas encore complètement intégrée dans les outils
actuels. Les outils existants (ARENA, WITNESS, PROMODEL, GPSS, EXTEND...) ne sont
pas adaptés pour modéliser les décisions et donc le processus de pilotage du SdP. Jusqu’à
présent, l’utilisateur renseigne les données et la simulation fournit la réponse du système
modélisé. C’est à la fin de l’exécution de la simulation qu’on peut : analyser les résultats,
analyser les causes dans le cas de l’obtention de résultats non escomptés, retrouver les
variables et leviers d’action, modifier les paramètres correspondants, puis relancer la
simulation. Ce processus est à reproduire jusqu’à satisfaction du résultat obtenu. De ce fait, le
processus classique de simulation est à reproduire autant de fois qu’il le faut pour obtenir un
résultat satisfaisant.
La recherche d’un optimum consiste à tester toutes les combinaisons possibles des variables
du système. Mais souvent en production, se posent des problèmes complexes à très forte
combinatoire, dits « N-complets ». Des méthodes telles que les plans d’expérience et les
tables de Tagushi, les techniques mathématiques (programmation linéaire, optimisation
combinatoire,...) permettent de réduire considérablement le nombre d’essais à réaliser pour
obtenir cet optimum, encore faut-il qu’il y ait un optimum atteignable (souvent les objectifs
sont antagonistes). Nous parlerons ainsi davantage de solutions « satisfaisantes ». Mais le
nombre de tests reste malgré tout encore bien élevé.
!$
) # * ) ) . +
L’interactivité suppose une assistance pendant la phase de modélisation et particulièrement

celle de la programmation qui devrait être simplifiée, voire totalement éliminée. Elle implique
également la possibilité d’agir directement sur le modèle pendant l’exécution, c’est à dire
l’introduction d’un aléa, la modification de l’organisation, le changement de règles ou de
paramètres... Mais, elle suppose aussi des possibilités de modification sans compilation
nouvelle du modèle et sans reprise de la simulation aux conditions initiales. L’une des
conséquences directes de cette limite est la difficulté d’utilisation de la simulation pendant la
phase d’exploitation d’un système, qui limite la prise de décision suite à l’arrivée d’un aléa
pour cause de lenteur dans la réaction.
L’interactivité concerne aussi l’introduction de modules d’évaluation, d’aide à la structuration

des expériences et l’évaluation des résultats issus du processus de simulation. Un module
d’évaluation permettrait d’interpréter les résultats continuellement. Ainsi, parmi les nombreux
facteurs, les inducteurs à l’origine d’une performance ou d’une contre performance pourraient
être identifiés. D’autres modules permettraient de limiter et structurer les expériences. Ils
auraient le rôle d’interface entre les résultats généraux du simulateur et l’utilisateur qui a
besoin de résultats spécifiques [Sénéclauze 1995] [Habchi et al. 1996].
2.2.3. Conclusion
Les différentes limites exposées impliquent deux conséquences principales. D’abord, la non
prise en compte du pilotage dans la simulation, de l’évaluation de l’impact des actions mises
en place, ainsi que l’interactivité limitée des outils actuels, impliquent d’importants coûts en
temps et en argent. Effectivement, le fait qu’il soit quasi impossible d’intervenir de manière
automatisée et structurée, en cours de simulation, nécessite de nombreux tests avant d’arriver
à une certaine « optimisation » du résultat. On peut ainsi parler d’une utilisation « passive »
de la simulation, puisque le pilotage n’étant pas pris en compte en cours de simulation, il faut
réaliser des expériences dans des conditions quasi figées. L’outil de simulation joue souvent
un rôle « passif » qui se limite à la représentation, la validation et/ou l’évaluation d’un
processus de production.
Ensuite, la complexité de la programmation et des concepts à utiliser pour obtenir un modèle

représentant la réalité, ne favorise pas la « démocratisation » de l’outil de simulation. De
même, le manque de généricité et de méthodologie dans les outils actuels, pour l’aide à la
compréhension des concepts d’une part, et pour l’aide au paramétrage d’autre part, ne facilite
pas l’accès à la simulation. Ainsi, les industriels font souvent appel à des spécialistes
extérieurs à l’entreprise pour effectuer des modèles, et de fait, l’utilisation de cet outil reste
« ponctuelle et limitée ».
2.3. Critères d’efficacité de la simulation

L’analyse proposée a montré les limites qu’approches de modélisation et outils de simulation
engendrent et qu’il est nécessaire de combler si nous voulons « démocratiser » l’utilisation de
la simulation. Elle permet également de cerner certains critères liés à l’efficacité d’un
simulateur. Ces critères se répartissent également en deux catégories : ceux liés à la
modélisation et ceux liés à l’environnement de l’outil de simulation.
!
) # * ) ) . +
2.3.1. Critères liés à la modélisation
Pour améliorer son efficacité, l’approche de modélisation doit être fondée sur :
• des concepts généraux ou universels développés afin d’expliciter d’abord, les éléments
qui composent le système et les relations entre ces éléments et ensuite, d’améliorer la
communication entre les différents intervenants à l’étape de modélisation,
• une structure permettant, d’une part, de décrire les différents niveaux hiérarchiques du
système à travers les sous-systèmes qui le constituent (système physique, système de
pilotage) et d’autre part, d’élaborer le modèle de manière évolutive et par affinage
progressif en utilisant éventuellement des modèles existants,
• des modèles statique et dynamique développés à partir de concepts identiques et dont la
cohérence est assurée par des liaisons de passage entre les deux modèles,
• des concepts permettant de représenter et de modéliser le processus de pilotage avec
toutes ses composantes (récupération de l’information, mesure et évaluation, prise de
décision, mise en place de l’action) de manière simultanée à la modélisation du système
physique.
2.3.2. Critères liés à l’outil de simulation
L’efficacité de l’outil de simulation est inévitablement conditionnée par son environnement

aussi bien interne qu’externe. Dans ce sens, l’outil doit satisfaire certains critères afin de :
• représenter de manière déclarative les modèles, ce qui réduit, voire élimine l’effort de
programmation,
• avoir une représentation comportementale des entités et des ressources du système à
travers une représentation orientée objets (acteurs ou agents) de la connaissance
permettant un changement des objets sans modification de la structure générale du
modèle,
• exprimer les événements sous forme de règles permettant de rendre plus lisible le
modèle ; dans ce sens, il faut alterner les commandes de l’interface entre des commandes
textes, un langage naturel et des graphiques,
• disposer d’une abstraction automatique des modèles du système qui peut être représenté
à différents niveaux d’abstraction ; en fonction du niveau spécifié, l’environnement doit
permettre la réalisation d’une instrumentation sélective des modèles afin que seules les
données représentatives soient collectées,
• permettre un accès interactif pour la construction des modèles et pour la simulation grâce
à des commandes interactives telles que les fenêtres et les graphiques colorés pour décrire
le modèle dynamiquement et statistiquement et des modules qui permettent de générer
automatiquement des scénarios pour passer en revue toutes les possibilités du modèle en
question,
• disposer d’un diagnostic à base de règles qui implique un raisonnement pouvant aussi
bien détecter un problème que recommander des solutions ; ceci peut se faire en couplant
le simulateur avec un système expert qui permet d’évaluer les performances d’un scénario
donné et suggérer des modifications.
!#
) # * ) ) . +
2.4. Propositions d’améliorations

Les propositions d’améliorations sont les résultats de travaux de thèses (M. Bakalem et C.
Berchet), de DEA, de réflexions et de travaux personnels. L’objectif est de pallier certaines
des limites citées précédemment, par le développement de concepts nouveaux permettant de
modéliser le processus de fabrication et d’introduire le processus de pilotage dans un modèle
de simulation.
Ainsi, le but est de rendre la simulation plus « active », pour élargir et optimiser l'utilisation
de son potentiel, et ainsi la rendre plus accessible à tous les utilisateurs. Notre démarche
consiste à obtenir un modèle puis un support informatique :
• accessible et compréhensible pour tout utilisateur lambda (grâce à l'utilisation de
concepts simples),
• rapide à comprendre et à mettre en œuvre (grâce à la proposition d’une méthodologie
d'utilisation de l'outil et des concepts proposés, sans besoin de connaissances expertes ni
en programmation ni en simulation),
• significatif (si la simplicité des concepts est une caractéristique du modèle, il doit
néanmoins être représentatif de la réalité et pertinent. Il s’agit de reproduire la réalité au
plus juste. Ceci nécessite donc un travail sur l'interface utilisateur, et sur sa convivialité).
Il faut arriver à reproduire les processus de fabrication et de pilotage dans la simulation, afin
de réagir de façon structurée sur le système. Ceci peut s’effectuer par l’intermédiaire des
structures et concepts suivants :
• la structure hiérarchique qui permet de représenter le système physique selon différents
niveaux de granularité,
• les graphes d’état qui décrivent selon une approche TPM, pour une ressource donnée, les
états selon différents niveaux d’abstraction,
• la structure globale qui définit l’environnement dans lequel évoluent les unités de
pilotage,
• la structure locale qui établit l’organisation des différents types de pilotage autour du
système à piloter (nous proposons à ce propos, une typologie selon la réactivité : le
pilotage « a priori », le pilotage « réactif pour anticipation » et le pilotage « a
posteriori »),
• le Système de Transformation du Produit (STP) permettant de modéliser une ressource
physique à tous ses niveaux hiérarchiques ou d’abstraction,
• l’Entité Circulante (EC) qui représentera le flux physique à travers le système de
fabrication,
• le Centre de Pilotage (CP), grâce auquel le processus de pilotage sera intégré dans la
simulation. Cette structure unitaire et générique, est la base du modèle d’aide au pilotage,
et cela selon différents niveaux de granularité (ce qui conserve ainsi la capacité de
représentation à tous les niveaux hiérarchiques de l’entreprise).
La proposition de ces structures et ces concepts va concourir à une modification du processus

de simulation vu précédemment, puisqu’il s’agit entre autre, d’introduire la boucle de
rétroaction (simulation, évaluation des performances, interprétation des résultats,
recommandations) dans le modèle même de simulation.
!%
) # * ) ) . +
3. ANALYSE ET CONCEPTUALISATION DU SdP DU POINT DE VUE DE

LA SIMULATION
Les nouvelles contraintes du marché soulèvent un certain nombre de problèmes qui doivent
être pris en compte dès la phase de conception du SdP. Ces contraintes concernent :
• la nature hétérogène du flux physique principal du SdP ; les éléments constituant ce flux
peuvent être de différents types (vis, écrou, rondelle…), élémentaires ou composés
(composant, sous-ensemble, ensemble) et de débits variables (pièce, lot, série),
• l’optimisation des espaces de production (zones de transformation, de stockage, de
transfert) afin de minimiser les cycles et les temps de production,
• la complexification de la fonction production qui gère, aussi bien, le processus de
fabrication que le processus de pilotage.
Dans cette partie, nous proposons une analyse ascendante du SdP dans laquelle nous
procédons dans un sens inverse à celui classiquement adopté (du système vers le modèle).
Ainsi, des concepts de base que nous voulons génériques, seront dégagés pour l’analyse et la
modélisation du SdP dans une optique de simulation.
Du point de vue de la simulation, nous pouvons décomposer le SdP en deux sous-systèmes :

le système de fabrication et le système de pilotage (figure 2.1).
Le système de fabrication est composé de deux types d’objets principaux : les ressources et
les entités. Les ressources représentent les moyens de production mis en place à disposition
du flux physique (entités). Elles comprennent des ressources dites « actives » telles que les
machines, les opérateurs, les systèmes de transferts... et des ressources dites « passives » telles
que les stocks, les palettes, les outils... Les entités forment le flux physique. Elles
comprennent les composants, les pièces, les lots, les ensembles, les produits...
Le système de pilotage est composé d’unités pilotantes ou décisionnelles. Le pilotage

exprime les relations qui existent entre acteurs décideurs, ressources, entités… Ces relations
correspondent à deux types de règles : les règles de précédence données par les gammes, les
nomenclatures... et les règles de gestion données par la définition des priorités, la gestion des
aléas, l’ordonnancement... Les règles de précédence (gammes et nomenclatures) définissent la
manière selon laquelle le flux physique traverse les ressources (logique d’enchaînement
opératoire). Ces règles sont de nature statique, elles sont affectées aux entités. Généralement,
elles ne changent pas dans le processus de fabrication et sont définies a priori (sauf dans le cas
de choix de gammes alternatives). Par contre, les règles de gestion sont de nature dynamique.
Elles évoluent dans le temps en fonction de l’état des ressources dans le processus de
fabrication. Ces règles sont affectées aux ressources car, généralement les actions mises en
place sont réalisées sur les ressources pour améliorer la performance du processus de
production. Aussi, par exemple la priorité d’une entité dans un processus peut changer d’une
ressource à une autre.
!
) # * ) ) . +
Système de production
Système physique
Entités Ressources
Matière première, Ressources Ressources

pièces, produits, lots, passives actives
séries, ensembles, Flux
sous-ensembles...
Stocks, Machines,
palettes, etc. opérateurs,
chariots...
Règles de Règles de gestion :

précédence : gestion des
nomenclatures, priorités, gestion
gammes, etc. des aléas, etc.
Aspect statique Aspect dynamique
Système de pilotage
Figure 2.1. - Décomposition du SdP du point de vue de la simulation.
Le recours à des structures autonomes, simples d’organisation et de conduite devient

nécessaire [Gindy et al. 1998]. Ainsi, pour tenir son rôle de contrôle aussi bien transitique
qu’opératoire [Barakat 1991], le système de pilotage doit être simple et localisé au maximum
(pour gérer des structures de taille réduite). De ce fait, le SdP est de plus en plus conçu sous la
forme de structures hiérarchiques agrégées, comportant les deux organisations physique
(système physique) et logique (système de pilotage).
!
) # * ) ) . +
3.1. Analyse et conceptualisation du système de fabrication

Dans cette partie, nous proposons d’abord, une analyse du système de fabrication fondée sur
une structure hiérarchique, une analyse de la ressource et de ses états… et ensuite les concepts
de STP et d’Entité Circulante.
3.1.1. Structure hiérarchique du système de fabrication
Pour construire une approche de modélisation tenant compte des critères définis
précédemment, nous proposons une structure générique capable de représenter un SdP,
composée de cinq niveaux hiérarchiques (figure 2.2) :
• la ressource élémentaire (machine, opérateur, stock...) correspond au niveau le plus bas
de la structure. Elle est capable de réaliser une opération réelle (transformation) ou
virtuelle (stockage). Le flux interne est composé de pièces unitaires ;
• la station est une association limitée de ressources élémentaires (par exemple : un stock,
une machine et un opérateur). Le flux interne est également composé de pièces unitaires ;
• la cellule est une association d’un ensemble de stations et éventuellement un système de
transfert synchronisé (convoyeur). Elle est caractérisée par son autonomie sur une période
de temps donnée. Son flux interne, généralement incompressible (ensemble ou sous-
ensemble de produit) se forme par assemblage de composants ;
• l’îlot est défini comme un ensemble de cellules associées à un réseau de transfert non
nécessairement synchronisé (par exemple un système de chariots filoguidés). Le flux
interne est généralement le lot ;
• l’atelier est un ensemble d’îlots associés par un système de transfert (par exemple chariots
ou navettes). Il correspond au niveau le plus élevé de la structure. Le flux interne est
constitué de lots ou de groupements de lots (séries).
Flux interne :
lots ou Atelier
séries Îlot Niveau « i-1 »
Flux interne :
Cellule Niveau « i »
produit assemblé
Flux interne : Station Niveau « i+1 »

pièce unitaire
Ressource élémentaire
Figure 2.2. - Structure hiérarchique du système physique.
3.1.2. Comportement d’une ressource du point de vue de la simulation
Les opérations associées à une ressource de production peuvent être de quatre types : la
transformation, le transfert, le contrôle et le stockage. L’opération de transformation est seule
capable de modifier l’état physique d’une entité (usinage, assemblage, soudage...). La
différence fondamentale qui existe entre les ressources de transformation (machine) et les
ressources transitiques (stock, convoyeur, robot, chariot) et de contrôle réside essentiellement
!
) # * ) ) . +
dans le fait que ces dernières introduisent une temporisation improductive. Toutefois,
l’ensemble des ressources de production présente fondamentalement deux aspects identiques :
d’abord, un aspect machine qui se traduit par le comportement opérationnel (transformation,
transfert, contrôle) et ensuite un aspect stock qui se traduit par une opération de temporisation
destinée à la régulation de la production. L’aspect stock est présent sur une machine en cas de
blocage aval de la production. Il apparaît donc que les ressources d’un SdP sont
structurellement et fonctionnellement identiques. De ce fait, le comportement fonctionnel
d’une ressource peut être exprimé de manière générique en trois opérations principales (figure
2.3) : la réception, la transformation et la fourniture. Ce comportement est valable quelle
que soit la ressource et quel que soit son niveau hiérarchique décrit précédemment.
Fourniture
Fourniture
Réception
Réception
Transformation
Entité Entité Entité
Figure 2.3. - Représentation schématique des opérations fondamentales d’une ressource de

production.
3.1.3. Niveaux d’abstraction et états d’une ressource
Une ressource passe successivement, de façon déterministe ou aléatoire, par un certain

nombre de phases différentes, dites états. L’état correspond à une situation particulière de la
ressource pendant un certain temps. Il est défini par un ensemble de variables caractéristiques
représentant les différentes facettes de la ressource : les variables d’état. L’état d’une
ressource est défini par l’ensemble des valeurs que prend chacune de ses variables d’état. Le
processus de production résulte de la succession interactive d’un certain nombre d’états par
lesquels passent les différentes ressources composant le SdP.
Il est possible de décrire le comportement d’une ressource donnée et d’évaluer sa performance

à l’aide de différents indicateurs liés à ses états. Cette performance servira par la suite au
pilotage de la ressource pendant la simulation. Le nombre d’états rattachés à une ressource
dépend de son niveau de détail adopté. Nous appellerons ce niveau : niveau d’abstraction.
Pour décrire le comportement d’une ressource de production et évaluer sa performance en vue
de la piloter, nous définissons quatre niveaux d’abstraction (figures 2.4 à 2.8) inspirés de la
philosophie TPM (Total Productive Management).
Premier niveau (figure 2.4) : il traduit l’engagement ou le non-engagement d’une ressource

dans un processus de production. Ceci induit deux super-états (ouvert et fermé) et deux sous-
états (disponible et indisponible). Les deux super-états ouvert et fermé, permettent de
calculer les indicateurs concernant les taux d’ouverture et de fermeture d’une ressource à un
niveau hiérarchique élevé (usine, atelier), alors que les deux sous-états disponible et
indisponible permettent de calculer les taux d’utilisation et de non-utilisation d’une ressource
à un niveau hiérarchique moins élevé (station, machine).
!&
) # * ) ) . +
Marche
Fermé Ouvert
Arrêt
Début arrêt
Pas d’arrêt programmé
programmé
Début arrêt
programmé
Disponible Indisponible
Fin arrêt
programmé
Figure 2.4. - Graphe d’état d’une ressource au premier niveau d’abstraction.
Deuxième niveau (figure 2.5) : si l’état indisponible est synonyme de non-productivité, l’état
disponible n’est pas toujours synonyme de productivité. Il peut être dans plusieurs cas
improductif. En effet, nous pouvons le détailler en cinq sous-états différents (libre, occupé,
défaillant, en réparation et en réglage). Ces états sont utilisés spécialement pour évaluer les
indicateurs tels que ; le taux brut de fonctionnement, le taux de panne, le taux de changement
de série, le taux de réparation... Les trois sous-états non productifs ; défaillant, en réparation et
en réglage sont subis et nécessitent des actions correctives et/ou préventives.
Disponible
Réception
Pas de même type
réception
Réception
type différent
Réception
type différent
Réception
Réception
même type Début
Défaillance réparation
Libre Occupé Panne Réparation Réglage
Fourniture Fourniture
Fin réparation
Fin réglage
Figure 2.5. - Graphe d’état d’une ressource au deuxième niveau d’abstraction.
!!
) # * ) ) . +
Troisième niveau (figure 2.6) : dans le cas d’une ressource à capacité multiple (centre de
charge ayant plusieurs unités identiques) ou d’une cellule de production, l’état occupé peut
être exprimé en trois sous-états ; intermédiaire, saturé et bloqué. Ces états permettent
d’évaluer, de manière plus précise, le taux brut de fonctionnement d’une ressource (l’aspect
stock ne correspond pas à une situation productive d’une machine). Dans une ressource à
capacité unitaire, les deux sous-états intermédiaire et saturé correspondent au même état
(saturé). L’état bloqué correspond à l’état d’une ressource qui a terminé la transformation
alors que le produit ne peut être fourni à la ressource suivante pour raison d’indisponibilité.
Réception
Réception
même type
Libre Occupé
Réception et
Charge < Capacité
Fourniture et Réception et
Charge = 0 Charge = Capacité
Réception Fin
transformation
Intermédiaire Saturé Bloqué
Fourniture
Fourniture
Figure 2.6. - Graphe d’état d’une ressource au troisième niveau d’abstraction.
!"
) # * ) ) . +
Quatrième niveau (figure 2.7) : l’état indisponible qui correspond à un état programmé ou
planifié (donc état non productif mais non subi), peut être également détaillé en plusieurs
sous-états ; maintenance préventive, pause, non-production, arrêt programmé... Ces
différents sous-états, exprimant l’indisponibilité programmée d’une ressource, sont utilisés
pour évaluer en détail, au cas de besoin, les indicateurs nécessaires.
Arrêt
programmé
Fin arrêt Début

programmé Début Début
pause Début
N.P. M.P. A.P.
Fin
pause
Non Maintenance Arrêt

Pause production Préventive Programmé
Fin N.P.
Fin maintenance
préventive
Fin arrêt
programmé
Figure 2.7. - Graphe d’état d’une ressource au quatrième niveau d’abstraction.
Les quatre niveaux d’abstraction d’une ressource sont présentés dans un graphe d’état global
représenté par la figure 2.8.
"$
) # * ) ) . +
Marche
Fermé Ouvert
Arrêt
Pas d’arrêt Arrêt
programmé programmé
Début arrêt
programmé
Fin arrêt
programmé Début Début Début Début
pause N.P. M.P. A.P.
Fin
pause
Non Maintenance Arrêt

Pause production Préventive Programmé
Pas de Fin N.P.

réception Fin maintenance
Réception préventive
Fin arrêt
même type programmé
Réception
Réception type différent
type différent
Réception
Réception
même type Début
Défaillance réparation
Libre Occupé Panne Réparation Réglage
Réception et
Fin réparation
Charge < Capacité
Fourniture Réception et Fin réglage

Charge = Capacité
Réception Fin
transformation
Intermédiaire Saturé Bloqué
Fourniture
Fourniture
Figure 2.8. - Graphe d’état global d’une ressource (tous les niveaux d’abstraction).
"
) # * ) ) . +
3.1.4. Décomposition et caractérisation du flux physique
D’après l’analyse hiérarchique du système physique réalisée précédemment, les éléments qui
composent le flux physique sont de nature différente et peuvent être classés selon différents
types (figure 2.9).
• La pièce unitaire qui correspond à un composant, une pièce...
• Le produit est très souvent formé par assemblage à partir d’un ensemble de pièces
unitaires généralement différentes. Il peut correspondre à une pièce unitaire.
• Le lot est formé par un ensemble de pièces unitaires ou de produits identiques.
• La série correspond à un ensemble de lots différents, elle est caractérisée par l’ordre de
passage des lots sur les ressources de production.
Série
Lot
Produit
Pièce
unitaire
Figure 2.9. - Décomposition du flux physique.
Selon le point de vue de la simulation et dans un but d’évaluation des performances et de

pilotage du SdP, il est nécessaire de suivre les éléments du flux physique dans le temps et
dans l’espace à travers le système de fabrication. Dans ce sens, nous proposons dans le
chapitre suivant une formalisation tenant compte de ces aspects.
Ainsi, les entités composant le flux physique seront suivies dans le temps et dans l’espace à
travers leurs caractéristiques. En outre, l’évaluation des performances et le pilotage de ce flux
nécessitent la mise en place d’indicateurs et l’affectation de variables qui identifient en
permanence l’état du flux. Les caractéristiques ainsi que les variables d’état permettent de
calculer des indicateurs de performances pertinents, qui seront les entrées du processus de
pilotage du SdP.
"#
) # * ) ) . +
3.1.5. Le concept STP : Système de Transformation du Produit
L’analyse du SdP, du point de vue de la simulation, nous permet de constater que toutes les
ressources sont considérées comme étant structurellement et fonctionnellement identiques.
L’approche de modélisation que nous proposons [Bakalem et al. 1996] [Bakalem 1996],
s’inscrit dans le cadre des modèles basés sur des objets génériques.
Le Système de Transformation du Produit (STP) est un processeur possédant toutes les

caractéristiques structurelles et fonctionnelles d’une ressource de production, développées
dans le cadre des niveaux hiérarchiques et d’abstraction. Il réalise principalement les trois
opérations de base : la réception, la transformation et la fourniture. Chacune des trois
opérations traduit une facette du comportement de la ressource.
• L’opération de réception consiste à obtenir une ou plusieurs entités à transformer. La
réalisation de cette opération suppose que la pièce à recevoir est disponible, que la
capacité de la ressource concernée n’est pas saturée et que cette ressource est prête à la
réception.
• L’opération de transformation consiste à retenir l’entité pendant un certain temps « T »
défini par la gamme de production. L’occupation de la ressource, au-delà de « T », est
considérée comme un blocage de la ressource. La durée « T » peut être nulle pour
certaines ressources (par exemple un stock).
• L’opération de fourniture consiste à libérer la ressource concernée et à fournir l’entité
transformée à la ressource consécutive définie par la gamme de fabrication. La réalisation
de cette opération suppose que la ressource suivante est prête à la recevoir.
Nous avons associé au STP un certain nombre d’hypothèses, pour modéliser son
comportement.
• Le STP doit procéder dans l’ordre ; réception, transformation, fourniture.
• La réception et la fourniture sont des opérations instantanées.
• La durée d’occupation d’une ressource au-delà de « T » est considérée comme blocage.
• Si la durée de stockage est nulle, l’occupation d’un stock correspond à un état de blocage.
• Le STP peut se trouver dans tout état représentatif des états d’une ressource.
Chaque ressource du SdP peut être modélisée par un STP. Construit selon cette approche, le
modèle est en partie un réseau hiérarchique et récursif de plusieurs STP. A un niveau
hiérarchique donné, les STP représentent des ressources du même niveau.
Présenté sous sa forme actuelle, le STP est une ossature générique et paramétrable, qu’on peut
enrichir selon les spécificités des ressources à modéliser et du niveau de détail (abstraction)
souhaité. Il permet une modélisation proche de la perception mentale des utilisateurs en
manipulant des objets proches de la réalité.
3.1.6. Comportement du STP dans un SdP dit « parfait »
Un SdP est « parfait » s’il est caractérisé par les points suivants :
• les ressources sont à capacité suffisante ou infinie,
• les ressources sont fiables,
• la matière première et les ressources auxiliaires sont disponibles à tout moment,
• le marché absorbe toute la production du système,
"%
) # * ) ) . +
• la production est bonne du premier coup,

• les stocks d’encours sont inutiles si les temps de stockage sont nuls.
Ces caractéristiques impliquent un flux de production ayant un débit de sortie qui correspond
au débit d’entrée quels que soient les temps opératoires unitaires. Vues selon le concept STP,
les ressources d’un SdP « parfait » ont un comportement identique qui consiste à répéter les
fonctions définies par le processus suivant (figure 2.10) :
• recevoir une entité,
• transformer cette entité,
• fournir cette entité à la ressource suivante ou au client.
Cycle Cycle
comportemental comportemental
d’un STP d’un STP
Flux physique « parfait » Flux physique « parfait » Flux physique
Réception Fourniture Réception Fourniture
Transformation Transformation
STP (i) STP (i+1)
Figure 2.10. - Schéma représentatif du comportement d’un STP dans un processus de

production dit « parfait ».
Dans un SdP dit « parfait », le pilotage est traduit directement par le comportement idéal du
STP. Pour tendre progressivement vers un comportement réel du SdP, nous introduisons dans
notre approche de modélisation des ressources ayant une capacité limitée. Ceci nécessite
l’introduction de ressources de stockage ayant une capacité suffisante pour réguler le flux
physique des entités. L’absence de stock dans un système ou l’existence de stocks à capacité
limitée introduisent la notion de blocage décrite précédemment. Enfin, l’introduction des
différents niveaux d’abstraction d’une ressource de production nécessite l’introduction de
modules de pilotage à tous les niveaux hiérarchiques du SdP, conformément à la structure
globale représentée précédemment.
3.1.7. Le concept EC : Entité Circulante
La modélisation du SdP implique, par ailleurs, la modélisation du deuxième type d’objet qui
constitue le flux physique. Ce flux est constitué par l’ensemble des entités qui circulent dans
le système et qui subissent des transformations réelles ou virtuelles sur les STPs. Un objet
entité est défini selon le niveau hiérarchique considéré ; une pièce unitaire, un produit obtenu
par assemblage, un lot, une série. Nous verrons dans le chapitre suivant la modélisation de cet
objet. De manière non exhaustive, il est caractérisé par : le nom ou l’identificateur, la taille, la
gamme principale et éventuellement les gammes alternatives, la nomenclature dans le cas
d’un assemblage, la date d’arrivée dans le système, la date de besoin exprimée par le client,
"
) # * ) ) . +
un indicateur de qualité fournissant le résultat de la transformation sur un STP (rebut,

reprise...)...
3.1.8. La ressource auxiliaire
Il arrive souvent qu’une ressource principale ait besoin d’une ressource auxiliaire (opérateur,
foret, moule, palette, outil...) pour effectuer une opération de transformation. La ressource
auxiliaire peut être caractérisée par l’exclusivité ou la « partageabilité ». En effet, un
opérateur humain peut s’occuper simultanément de plusieurs ressources principales, il est
partagé par ces ressources, alors qu’un moule ne peut être utilisé que par une seule presse à la
fois, il est exclusif et donc il ne peut être affecté qu’à une seule ressource presse. Nous avons
considéré qu’un opérateur pouvait être modélisé par un STP. Par contre, une ressource
auxiliaire autre est caractérisée par : son identificateur, son état (libre, réservé ou alloué), un
échéancier éventuel qui fournit le plan d’allocation de cette ressource aux différentes
ressources principales l’ayant réservée.
3.2. Analyse et conceptualisation du système de pilotage

Dans nos travaux de recherche, nous abordons le système de pilotage d’un SdP [Berchet et
al. 1999a] [Habchi et al. 1999] en vue de son intégration dans une approche de modélisation
pour la simulation [Berchet et al. 1999b] [Berchet 2000] [Berchet et al. 2001]. Cette
intégration a était l’un des objectifs fixés dans le cadre de la thèse de Claire Berchet en contrat
CIFRE avec l’entreprise ALCATEL. Comme nous avons déjà vu, plusieurs travaux existent
sur le pilotage industriel et la littérature est assez abondante dans ce domaine. Ainsi, dans la
section suivante nous proposons un tour d’horizon non exhaustif pour aborder de manière
succincte l’essentiel de ces travaux. Il est toutefois important de rappeler que la majorité de
ces travaux gravitent autour des fonctions d’ordonnancement et de conduite d’ateliers et sont
essentiellement fondés sur des formalismes tels que les RdPs, la programmation linéaire…
non abordés dans nos travaux.
3.2.1. Des travaux existants autour de l’ordonnancement et la conduite

d’ateliers
• Les systèmes ORDO et SCOOP du LAAS

Au LAAS/CNRS de Toulouse (Laboratoire d’Analyse et d’Architecture des Systèmes), les
travaux ont pour thème principal l’étude des systèmes de production. Briand [Briand 1995] a
développé une approche concernant la problématique de conduite d’atelier (principalement
l’ordonnancement temps réel). Ses travaux s’inscrivent dans un cadre de recherche consistant
en l’élaboration d’une commande automatisée pour les Systèmes Flexibles de Production
Manufacturiers et l’informatisation du système de fabrication. Ils se focalisent
particulièrement sur l’analyse et la conception du centre de fabrication (mise en œuvre du
plan de fabrication, commande en temps réel des ressources de fabrication,…). Ce centre est
un centre de décision de niveau opérationnel ayant pour charge de gérer les flots de produits
dans l’atelier de manière à respecter les contraintes physiques des ressources et les contraintes
temporelles exprimées dans le plan de fabrication prévisionnel. L’architecture de commande
proposée prévoit trois niveaux hiérarchiques : le centre planificateur, le centre prévisionnel et
"
) # * ) ) . +
le centre de conduite (composé lui-même de deux centres ; le centre coordinateur et le centre

superviseur). Une stratégie de fonctionnement a été définie : le centre coordinateur envisage
le procédé par rapport aux contraintes physiques et le centre superviseur, ayant un point de
vue plus abstrait, ne considère que les contraintes temporelles. Ce travail a permis de définir
une architecture logicielle pour la conduite d’atelier. Une conception OO est utilisée, elle
mixe les principes d’abstraction OO et le formalisme des RdP. D’autres travaux du LAAS,
plus anciens, concernent plutôt l’ordonnancement prévisionnel. ORDO est un progiciel
d’ordonnancement développé au LAAS puis commercialisé successivement par les sociétés
Syseca et Cabinet Villaumié [Billaut 1993]. Il vise à caractériser un ensemble admissible de
solutions par utilisation de contraintes suffisantes d’admissibilité. SCOOP est un système
interactif d’aide à la décision pour l’ordonnancement d’atelier [Esquirol et al. 1994]. Il
propose une interface homme/machine évoluée qui permet aux responsables de la production
de construire pas à pas un plan de fabrication en étant guidé en permanence dans leur
démarche. L’approche utilisée est basée sur l’analyse sous contraintes.
• Les projets CASPAIM du LAIL

Au LAIL (Laboratoire d’Automatique et d’Informatique Industrielle de Lille), l’objectif du
projet CASPAIM (Conception Assistée de Systèmes de Production Automatisés en Industrie
Manufacturière) est de proposer une méthodologie d’analyse, de conception et
d’implémentation des systèmes flexibles de production manufacturière. La structure de
commande globale comporte trois niveaux : hiérarchique, commande et procédé [Bourey
1993]. Le niveau hiérarchique résout les indéterminismes du niveau commande. Le niveau
commande est chargé du transport des produits entre les ressources de l’atelier. Le niveau
procédé est composé des ressources propres à l’atelier. Une grande partie des travaux du
LAIL a porté sur le niveau intermédiaire de commande [Bourey et al. 1991] [Amar et al.
1992]. Ces travaux sont basés sur une approche orientée produit. A l’aide d’un modèle
logique (gammes) et d’un modèle physique (ressources et relations), la construction d’un
« pré-graphe » de commande est générée automatiquement. Le pré-graphe traduit pour chaque
type de produit les enchaînements d’opérations possibles sur les ressources. Ensuite, en
prenant en compte des informations de plus bas niveau, un RdP structuré est engendré avec
une faible abstraction puis simulé, validé et implémenté. Suite à une analyse critique du projet
CASPAIM, un nouveau projet CASPAIM2 fut développé. Une nouvelle structure de
commande issue d’une analyse SADT fut proposée. Cette nouvelle démarche s’efforce de se
placer dans un contexte de gestion de production temps réel en proposant une surveillance des
défaillances et un ordonnancement prévisionnel des opérations à mettre en œuvre [Elkhattabi
1993].
• La méthode GRAI et l’approche PCS

La méthode GRAI (Graphe à Résultats et Activités Inter-reliés) est développée par le
laboratoire GRAI de Bordeaux [Breuil 1984] [Doumeingts 1984] [Roboam 1993] pour
l’analyse et la conception des systèmes décisionnels de gestion de production. Basée sur un
modèle conceptuel, elle aide à identifier les composants d’un système de production et à
définir leurs interactions. Elle s’inscrit surtout dans une démarche d’organisation rationnelle
des activités de la production. Les interactions existantes entre centres de décision définissent
le cadre de décision. Trois types de relations inter-centres sont envisageables : les relations de
coordination (vertical descendant), les relations de synchronisation (horizontal), les relations
de suivi (vertical ascendant). L’analyse étant basée principalement sur les fonctions que
réalise le système, la structure résultante est peu propice à supporter une restructuration de
l’entreprise ou une reconfiguration des moyens de production. L’approche PCS (Planification,
Conduite, Suivi) [Archimède 1991] vise à proposer une solution réactive, distribuée et
"
) # * ) ) . +
hiérarchisée au problème de la conduite d’atelier. Le système de commande, constitué de

centres de pilotage PCS, est organisé en trois niveaux : l’atelier, la cellule, le poste de travail.
Chaque centre comporte trois sous-systèmes qui agissent en parallèle : le système de
planification qui élabore le planning d’activités, le système de conduite qui détecte les
dysfonctionnements et élabore les actions à mettre en œuvre en fonction du planning
prévisionnel et des événements, le système de suivi qui a pour rôle de mettre à jour l’état du
système piloté et de signaler au système de conduite les éventuelles anomalies. Cette
approche présente un principe de fonctionnement générique pour chaque centre PCS et un
centre d’ordonnancement à chaque niveau de la commande.
• Les approches RdPCO et CODECO du LAG

Plusieurs travaux ont été menés au LAG (Laboratoire d’Automatique de Grenoble) sur la
problématique de la conduite des systèmes flexibles de production manufacturière. Une
première approche mixte objets/RdP [Hssain 1993] est fondée sur un modèle de
représentation de la commande des ateliers flexibles basé sur une classe enrichie de RdP : les
RdP de Commande orientés Objet (RdPCO). Les RdPCO permettent un passage de la phase
de modélisation à celle d’implémentation. La structure de commande est située à deux
niveaux : contrôle (gestion des interactions entre les objets physiques), décisionnel (résolution
des situations conflictuelles et ordonnancement temps réel). L’avantage principal de cette
approche réside dans la structuration objet qui favorise notamment la réutilisabilité des
composants et une distribution de la commande. Par contre, son inconvénient est qu’elle ne
permet pas de déterminer dans quelle mesure le choix des objets définis par le concepteur est
judicieux par rapport aux objectifs initiaux. Une deuxième approche dénommée CODECO
(COnduite DÉcentralisée COordonnée d’ateliers) préconise la définition d’une structure de
commande basée sur une décomposition en plusieurs niveaux de décision [Kallel et al. 1985].
Chaque niveau comporte un ou plusieurs centres de décision qui coopèrent selon deux axes :
un axe horizontal (coopération) et un axe vertical (coordination). L’efficacité de la commande
est essentiellement basée sur l’autonomie des centres de décision. Le système de conduite
comporte deux niveaux décisionnels : un niveau ordonnancement et un niveau conduite
locale. Cette approche semble être intéressante par les principes de fonctionnement qu’elle
préconise. L’architecture favorise le découplage des centres de décision et laisse à chaque
conduite locale une autonomie qui permet d’éviter de remettre en cause systématiquement un
plan de fabrication. Une troisième approche [Long 1993] (conduite hiérarchisée par la
méthode de la commande des flux) préconise la définition d’une structure de commande en
trois niveaux : un niveau d’ordonnancement prévisionnel, un niveau d’ordonnancement temps
réel et un niveau de supervision. Le niveau ordonnancement prévisionnel consiste à envisager
le processus de fabrication à court terme en tant que processus continu. Dans ces conditions,
l’ordonnancement peut être abordé selon un système d’équations traité par programmation
linéaire. L’idée est de déterminer une solution d’ordonnancement qui, bien que non réaliste,
servira de guide pour le pilotage temps réel. Le niveau supervision correspond à la commande
temps réel du procédé et se base sur une modélisation par RdP de Commande. Cette approche
semble intéressante par la technique d’ordonnancement qu’elle propose. Néanmoins, le
problème semble être d’assurer que l’état du procédé est toujours compatible avec les
hypothèses de continuité et de périodicité du processus de fabrication.
• L’architecture SIAD proposée par le LGIL

Le LGIL (Laboratoire de Génie Industriel et Logiciel de l’Université de Valenciennes)
préconise l’utilisation d’un Système Interactif d’Aide à la Décision (SIAD) pour la conduite
d’atelier [Dindeleux 1992] [Tahon 1992]. L’architecture générale du SIAD repose sur trois
niveaux d’abstraction : le niveau connaissance, le niveau fonctionnel et le niveau métier. Le
"&
) # * ) ) . +
niveau connaissance représente les caractéristiques du procédé structurées en trois bases : une
base de règles, une base de description et une base dynamique. Le niveau fonctionnel
rassemble les fonctions nécessaires à la conduite du procédé. Le niveau métier correspond aux
divers experts et utilisateurs qui participent à la maintenance du système d’aide à la décision
et à son fonctionnement. L’approche paraît très intéressante dans le cadre d’une coopération
étroite homme/machine.
• Le projet ESPRIT DIAS

Certains des travaux du CRAN (Centre de Recherche en Automatique de Nancy) se situent
dans le cadre de la conception des systèmes de production manufacturière. Plusieurs études se
sont intégrées au sein du projet ESPRIT DIAS (Distributed Intelligent Actuators and Sensors)
n° 2172 [Iung 1992]. L’objectif de ces études concernait la spécification d’une méthodologie
permettant le passage entre l’analyse de fonctionnement et l’exploitation des équipements des
processus industriels complexes d’une part, et la conception des automatismes de conduite et
de maintenance, d’autre part. L’analyse s’appuie sur trois types de modèle : le modèle
pratique qui est constitué d’un ensemble d’interviews multi-spécialistes, le modèle cognitif
qui exprime la connaissance contenue dans le modèle pratique (utilisation de MERISE), le
modèle machinable qui permet de faire la synthèse des besoins dans un but d’exploitation
informatique. Le module fonctionnel d’automatismes (gestion de la commande, validation des
objectifs, validation des observations, les comptes rendus) associé à des actionneurs ou
capteurs, traduit le concept de capteur intelligent. La réutilisabilité des modules fonctionnels
est difficile du fait que chaque composant possède un ensemble de contraintes propres.
• Les projets ESPRIT 477 et IMPACS 2238 et l’architecture PAC

Dans le cadre du projet ESPRIT n° 477 du CONSORTIUM COSIMA mêlant les entreprises
COMAU (Italie), Renault (France), D. Equipement (Allemagne, Irlande) et l’université de
Galway (Irlande), un système de conduite fut développé dans le but de pallier les manques et
les carences des outils de conduite automatisés existants. L’architecture de PAC (Production
Activity Control) a été utilisée. Cette architecture met en évidence cinq fonctions principales :
ordonnancer (ordonnancement prévisionnel à partir de MRP2), lancer (lancement ou
ordonnancement temps réel), surveiller, produire, transporter. L’inconvénient de l’approche
PAC réside dans le faible facteur de réutilisabilité qui caractérise les éléments du système. En
effet, la mise en œuvre des fonctions est très liée à la structure du système physique. Cet
inconvénient est pris en compte dans le projet IMPACS n° 2238 qui devait garantir la
réutilisabilité de l’architecture proposée.
3.2.2. Structures de pilotage
La littérature fait référence à diverses structures de pilotage [Trentesaux 1996] [Dindeleux

1998] [Roy 1998] [Youssef 1998]. Nous recensons et établissons une description succincte de
la plupart d’entre elles :
• La structure centralisée
C’est la plus classique et la plus ancienne. Elle se caractérise par un pilotage localisé au sein
d’une ressource unique qui supervise la production et gère en temps réel, les événements qui
surviennent tout au long de la production, sur le système composé de plusieurs ressources. Le
pilotage est très spécifique à l’environnement de production. Cependant, la capacité de
régulation est réduite par la rigidité structurelle. Ainsi, la structure centralisée est par essence
peu robuste et ne peut efficacement intégrer la résistance aux perturbations.
"!
) # * ) ) . +
• La structure hiérarchisée
Dans cette structure, la notion de niveau d’abstraction permet de modéliser une entreprise
complète. Chaque niveau coordonne les unités de pilotage du niveau inférieur, et ce jusqu’au
niveau le plus bas. Donc, chaque niveau a des relations de dépendance vis à vis du niveau
supérieur et de dominance vis à vis du niveau inférieur. Chaque décision est élaborée au
niveau où un problème est détecté. Les niveaux inférieurs traitent cette décision comme une
contrainte et transmettent en retour une information de suivi au niveau supérieur. Des
présentations détaillées sont fournies dans [Archimède 1991] [Trentesaux 1996] [Youssef
1998]. Ainsi, cette structure basée sur une décomposition du problème global en sous-
problèmes et sur le concept d’agrégation, est souvent utilisée. Le principe de décomposition
permet de ramener la résolution du problème global à la résolution successive de sous-
problèmes de dimension et de complexité acceptables.
• La structure coordonnée
Elle correspond à un ensemble de structures hiérarchisées. La différence est l’existence d’une
coopération à un même niveau. Ces structures accroissent théoriquement la capacité de
décision au sein de chacun de ces niveaux. Ainsi, cette coopération doit améliorer la réactivité
en proposant une décomposition dynamique du problème au niveau où il apparaît, plutôt
qu’une décomposition hiérarchique des ordres vers les niveaux inférieurs. Le modèle
CODECO (COnduite DEcentralisée COordonnée d’atelier) [Kallel 1985] est un exemple
illustrant ce type de structure.
• La structure distribuée
Elle est fondée sur une distribution complète de la décision sur l’ensemble des ressources
pilotant un centre de production. Le contrôle d’une telle structure est beaucoup plus complexe
en raison de sa modularité, par rapport à une structure hiérarchique qui est plus rigide mais
plus facilement maîtrisable. Cette structure présente un niveau élevé de réactivité et de
flexibilité.
• La structure distribuée supervisée

Elle se caractérise par un ensemble d’entités coopérantes sous le contrôle d’une entité
superviseur dont le rôle est d’imposer, de conseiller ou de modifier une décision afin de
respecter un objectif plus global. Un superviseur possédant une vision plus globale du
processus de production, est rajouté à la structure distribuée. Cette structure est un compromis
entre les structures, distribuée et centralisée. Elle permet une gestion globale et efficace par la
centralisation de contrôle d’une part, et une meilleure réaction aux perturbations par la
distribution des capacités de décision d’autre part. Le modèle de Kouiss par exemple [Kouiss
et al. 1995], est dédié au pilotage d’atelier et se base sur une structure distribuée supervisée.
• L’approche holonique
D’après Roy [Roy 1998], elle a été introduite par Koestler en 1989 pour des organisations
sociales et des systèmes auto-organisés. C’est une approche originale qui considère un
système comme un agglomérat d’unités distribuées et autonomes : les « holons ». Un système
holonique est une société d’holons (holarchie) qui coopèrent pour atteindre un objectif et qui
agissent en tant qu’ensembles d’entités coopérantes. Un holon est un bloc de construction
autonome et coopératif d’un système de fabrication pour transformer, transporter, stocker
et/ou valider de l’information ou des objets physiques. Il se compose d’une partie pour le
traitement de l’information et d’autre part du développement physique. Il peut représenter un
opérateur humain, une machine ou un logiciel. Enfin, il peut faire partie d’un autre holon.
""
) # * ) ) . +
3.2.3. Notre choix d’une structure de pilotage hybride : une structure

coordonnée hiérarchisée
Pour conceptualiser et introduire le processus de pilotage dans un modèle de simulation, nous

optons pour une structure coordonnée hiérarchisée. Ce type de structure apporte de
nombreux avantages en terme d’intégration des objectifs. Elle permet de prendre en compte
les objectifs locaux d’une part. Et elle apporte l’aspect coopératif entre les différentes unités
de pilotage d’un même niveau hiérarchique, par la prise en compte lors de la prise de
décision, des objectifs des autres unités de pilotage (sous forme de contraintes), du fait de la
structure coordonnée. D’autre part, l’intégration des objectifs globaux et la cohérence du
modèle (grâce à la désagrégation des objectifs et à l’agrégation des données), sont possibles
en utilisant la structure hiérarchisée. Nous retrouvons une analyse détaillée des avantages et
limites de cette structure dans [Berchet 2000].
3.2.4. Structure globale et tridimensionnelle du pilotage
Pendant la simulation d’un SdP, le processus de pilotage, nécessaire pour le maintien du

système sur sa trajectoire prévisionnelle, doit être considéré avec tous ses aspects réels. Le
pilotage ne peut exister que si le système est en mouvement, c’est à dire que l’état du système
varie principalement selon deux facteurs : l’espace et le temps. De plus, le processus de
pilotage se construit par la mise en place de diverses décisions prises à différents moments et
différents points du système. Les décisions à prendre et à mettre en place dépendent des
différents objectifs à atteindre et définis selon les niveaux hiérarchiques du système industriel.
Ainsi, nous pouvons présenter le pilotage industriel selon une structure globale et
tridimensionnelle (figure 2.11) comportant les trois dimensions : espace ou profondeur,
temps et hiérarchie.
• La dimension hiérarchique
Elle est fonction de l’organisation verticale du système de décision. Elle peut être explorée de
manière ascendante ou descendante, à un instant donné, en faisant appel à des unités de
pilotage de niveaux hiérarchiques différents. L’unité de pilotage ainsi que le niveau
hiérarchique, sélectionnés dépendent de plusieurs facteurs : l’objectif assigné, la gravité et la
complexité du problème, la décision à prendre, l’action à mettre en place... La coordination
qui exprime la relation entre deux unités de niveaux différents, constitue la base du problème
de cohérence entre les différents décideurs hiérarchiques. Cette coordination est induite par le
caractère hiérarchisé des systèmes. Les différentes prises de décision à tous les niveaux
concernés, et les actions qui en découlent doivent rester en cohérence avec la finalité globale
de l’entreprise. La coordination doit résoudre les problèmes posés par la relation qu'entretient
une unité avec les unités qui lui sont hiérarchiquement rattachées.
• La dimension profondeur (ou espace)

Elle dépend du type d’organisation du système de fabrication, de son envergure et du niveau
de décentralisation. Cette dimension peut être explorée à un instant donné par des unités de
même niveau hiérarchique, en plusieurs points du système. Le niveau de diffusion horizontale
d’une décision est fonction de la profondeur du processus opérant. L’importance du problème
à traiter agit directement sur le nombre d’unités concernées par la décision. La coopération
$$
) # * ) ) . +
qui exprime la relation entre deux unités de même niveau, constitue le principe de base pour
résoudre localement et par coopération les problèmes à un niveau donné. En effet, il est
nécessaire de s’assurer de la non-contradiction existante entre les décisions d’un même niveau
hiérarchique. A chaque échelon, les décisions doivent tenir compte des informations latérales
(qui peuvent être des contraintes), afin de mieux situer la mission de chaque unité. Au
problème de cohérence des informations établies pour chaque unité, s'ajoute celui de leur
cohérence avec les autres unités. Lorsque des unités horizontalement indépendantes sont
concernées, il est possible qu'une action entreprise dans une unité améliore certains de ses
résultats et en dégrade d'autres dans d'autres unités.
• La dimension temporelle
Elle représente la dynamique du système. En un point donné, deux décisions prises à deux
instants différents peuvent être différentes, mais elles sont dépendantes. Une décision devient
irréversible avec le temps dès lors qu’elle est appliquée. En tout point du système, le
processus de pilotage évolue dans le temps suivant des trajectoires décrivant des flux de
décision. La relation de dépendance entre ces trajectoires est une fonction des autres
dimensions donc des principes de coordination et de coopération. Le temps tient une place
prépondérante dans le processus de pilotage, dans la prise des décisions, puisque celles-ci
provoquent des réactions irréversibles.
Dimension Unité de pilotage

hiérarchique
Aléas Relation de
extérieurs coordination entre
au système Niveaux différents niveaux
fonctionnels
Relation de
coopération au
même niveau
Niveau i
Flux décisionnel
et informationnel Dimension
temporelle
Flux décisionnel
et informationnel
«t-1» «t» «t+1»
Dimension
profondeur Flux de production
Niveau
opérationnel
Figure 2.11. - Structure globale et tridimensionnelle du système de pilotage industriel.
$
) # * ) ) . +
3.2.5. Structure locale et typologie du pilotage
L’AFGI [Afgi 1992] distingue deux types de pilotage : le pilotage économique et le pilotage
technique. Le pilotage économique définit une organisation ou une réorganisation des
processus opérants. Les actions correctives prises à ce niveau sont des actions de remise en
cause des processus et de modification de leur finalité. Le pilotage technique, quant à lui, fait
appel aux activités de lancement et de suivi, c’est-à-dire à la réalisation des activités du
système opérant. Les choix issus du pilotage technique consistent à remettre en cause
localement des activités opérantes d’un processus, sans que la finalité ne soit remise en cause,
en utilisant les évaluations retournées par les indicateurs élémentaires sur les activités
opérantes. Quant à nous, nous proposons une typologie du point de vue de la réactivité
[Berchet et al. 1999a].
D’abord, le pilotage « a priori » correspond à la définition d’une trajectoire prévisionnelle

acceptable, voire optimale du système. C’est une étape théorique fondée sur la modélisation et
définie avant l’exécution. Elle pose parfois des problèmes de principe, puisque les résultats
sont obtenus à partir de modèles.
Ensuite, le pilotage « réactif pour anticipation » correspond à la correction en permanence

des écarts de la trajectoire réelle par rapport à la trajectoire prévue. Cette étape de pilotage
événementielle agit, d’une part, sur les facteurs techniques internes et maîtrisables pour
corriger les éventuelles dérives du système, et prévoit, d’autre part, des actions préventives
conditionnelles et systématiques pour éviter l’arrivée de certaines perturbations. Cette étape
nécessite la mise en place d’une maintenance préventive et d’un système d’indicateurs de
processus [Berrah 1997].
Enfin, le pilotage « a posteriori » s’effectue à la suite de l’arrivée d’une perturbation sans

avoir pu l’anticiper (commande urgente), d’un aléa résiduel (défaillance machine) ou après
obtention de résultats périodiques. Cette étape peut impliquer dans certaines conditions la
modification de la trajectoire prévue. Elle nécessite la mise en place d’un système
d’indicateurs de résultat et d’une maintenance corrective.
Pilotage « réactif par

anticipation »
(évoluant en fonction de l’état
du système, par réaction en
cours du processus et par Pilotage « a posteriori »
Pilotage « a priori » prévention) (effectué en fonction des résultats
(théorique, fondé sur des modèles) Outils : indicateurs de processus, du système, par correction)
Outils : simulation, maintenance préventive. Outils : indicateurs de résultat,
ordonnancement, planification, … maintenance corrective.
Système à piloter
Figure 2.12. - Structure locale du pilotage industriel.
$#
) # * ) ) . +
La structure locale du processus de pilotage (Figure 2.12) présente de manière

« macroscopique », d’une part, l’organisation des trois types de pilotage autour du système et,
d’autre part, les liens pouvant exister entre ces étapes et le système à piloter.
La complémentarité entre les deux structures locale et globale, crée un environnement

indispensable à un pilotage pertinent. La structure globale, ayant pour base le niveau
opérationnel, situe le processus de pilotage dans son environnement, alors que la structure
locale prend en compte la boucle de rétroaction en totalité (la mesure et son évaluation, la
mise en place de la décision, son suivi, et la réaction aux aléas).
3.2.6. Le concept CP : Centre de Pilotage
Pour piloter un système, des unités de pilotage structurées sont nécessaires. Nous citons, par
exemple, le Centre de Décision (CD) [Breuil 1984] [Doumeingts 1984] [Giard 1988]
[Bitton 1990], la Station Intégrée de Pilotage (SIP) [Trentesaux 1996] [Pesin et al. 1998], le
Point de Vue (PDV) [Trad 1996]… Un aperçu de ces structures est résumé dans [Berchet
2000].
Pour notre part, nous allons définir, décrire puis formaliser une unité nommée Centre de
Pilotage (CP), appropriée à notre besoin, et grâce à laquelle nous pourrons introduire le
processus de pilotage dans un modèle de simulation [Berchet 2000]. La structure globale
(figure 2.11) a montré, de manière générale, l’existence d’entités disposées aux différents
niveaux hiérarchiques indispensables pour le pilotage d’un système. Ces entités que nous
voulons génériques et capables de piloter les autres entités du système, sont nécessaires à
définir et à mettre en place. Ainsi, cette entité que nous désignons par « Centre de Pilotage »
(CP) est définie comme étant « une structure autonome, dépendante de la stratégie de
l’entreprise, ayant un pouvoir décisionnel, associée à une entité à piloter et disposant d’un
ensemble de moyens nécessaires à la mise en place d’actions pour atteindre un ou plusieurs
objectifs définis dans le cadre global de l’entreprise ».
Un CP possède une structure et un comportement. Sa structure dispose des éléments suivants :

• acteur(s) décideur(s),
• données endogènes (référents, objectif),
• données exogènes (données structurelles, données liées au système à piloter, données
liées à l’environnement),
• outils d’aide à la décision (indicateurs de performance, outils d’ordonnancement et de
planification, simulation…),
• ressources (humaines, matérielles) pour la mise en place des actions.
Le comportement interne d’un CP se traduit, de manière simplifiée, par un ensemble

d’activités qui sont réalisées conformément à la structure de la figure 2.13. Ces activités se
déroulent selon un processus comprenant les quatre étapes suivantes : la performance, la
décision, l’évaluation, l’action.
Cette structure simplifiée du comportement du CP est ensuite détaillée selon la figure 2.14.
D’abord, la performance est évaluée à l’aide d’un indicateur qui est scindé en mesure,
évaluation et objectif selon certains travaux du LLP/CESALP [Berrah 1997], ensuite en cas
de dérive du système piloté, l’étape de décision est éclatée en l’identification des causes, la
$%
) # * ) ) . +
définition d’un plan d’actions et son évaluation, et enfin l’étape d’action est effectuée par la
mise en place du plan d’actions après sa validation à l’aide d’outils d’aide à la décision.
CENTRE DE PILOTAGE
Processus de
Outils d’aide à décision Acteur
la décision décideur Informations
exogènes
Evaluation Décision
Ressources
Informations
endogènes
Action Performance
SYSTEME
PILOTE
Figure 2.13. - Structure simplifiée d’un centre de pilotage.
CENTRE DE PILOTAGE
Acteur
Processus de décideur
Outils d’aide à décision
la décision
Informations
Evaluation du Plan exogènes
plan d’actions d’actions
Non
Validation ?
Identification
des causes
Oui
Oui Informations
Ressources endogènes,
Dérive ? objectifs…
Non
Application du
plan d’actions
Evaluation
Mesure
Indicateur
SYSTEME
PILOTE
Figure 2.14. - Structure détaillée d’un centre de pilotage.
$
) # * ) ) . +
3.3. Informations d’échange entre STPs, ECs et CPs

Pour structurer et modéliser les relations d’échange qui lient CPs, STPs et ECs, nous
proposons de manière non exhaustive une typologie de l’information pouvant exister dans ces
relations (figure 2.15). La stratégie globale et la cohérence de l’ensemble du système
dépendent des relations d’échange, donc de ces informations.
CP
Information Information de
structurelle l’environnement
CP CP
Information de
conduite
interne au CP CP
Information Information d’état

décisionnelle ou de retour
SYSTEME
PILOTE
Figure 2.15. - Les informations des relations d’échange entre CP et système piloté.
• L’information structurelle
Elle concerne les produits (ECs) (gammes, délais…), les ressources (STPs) (machines,
acteurs…), les clients (commandes, dates de besoins…)... Pour éviter la duplication de cette
information, elle doit être stockée sur une base commune. Elle correspond à une information
tirée puisqu’elle est mise à la disposition des CPs qui en ont besoin (achat, planification,
production…). Des CPs compétents sont responsables de la mise à jour et de la fiabilité de
cette information.
• L’information décisionnelle
Elle correspond à une décision émise. Elle ne peut provenir que d’un CP. C’est une
information poussée par un CP à la suite d’un processus de décision, sous forme d’objectifs
et/ou d’actions, vers un ou plusieurs CPs destinataires de même niveau ou de niveau
hiérarchique inférieur. Conformément à la définition donnée à un CP, c’est au CP destinataire
d’atteindre cet objectif d’une manière autonome, en se fixant des variables d’action, en
construisant lui-même ses indicateurs ou tableaux de bord.
• L’information de conduite
Elle concerne généralement le système piloté au niveau opérationnel (priorité associée aux
Ordres de Fabrication, gestion des priorités dans une file d’attente, règles de conduite d’un
transporteur…). Elle est stockée par chaque CP car elle peut être différente d’un CP à un autre
et changer en fonction de l’état du système.
• L’information d’état
C’est une information poussée par le système piloté et renseigne en permanence, à l’aide d’un
indicateur, le CP concerné de l’état du système en fonction du temps (marche, panne, arrêt,
situation d’un OF…). Le changement d’état (renseigné par cette information) est déclenché
$
) # * ) ) . +
suite à l’arrivée d’un événement prédéterminé ou contingent et est utilisé dans un pilotage
« réactif pour anticipation ». Elle a comme support un indicateur de processus.
• L’information de retour
Elle est obtenue à partir du système piloté de manière périodique. Elle a pour support un
indicateur de résultat et concerne le flux physique et les ressources. Elle est tirée du système
et sert dans le cas d’un pilotage « a posteriori » (production à la fin d’une période,
disponibilité moyenne d’une ressource…).
• L’information de l’environnement
Elle concerne généralement les CPs situés aux niveaux hiérarchiques supérieurs. Cette
information plutôt tirée correspond souvent à une décision stratégique (étude de marché,
lancement d’un nouveau produit…).
3.4. Proposition d’un cadre de simulation en fonction de la

décomposition adoptée du SdP
Il n’existe pas de fonction de dépendance explicite permettant d’exprimer facilement les
niveaux d’abstraction (figure 2.8) en fonction des niveaux hiérarchiques (figure 2.2) du SdP.
Toutefois, il est évident que certains niveaux hiérarchiques ne sont pas compatibles avec
certains niveaux d’abstraction (par exemple l’expression du comportement d’un atelier ou
d’un îlot en fonction des niveaux d’abstraction 3 ou 4).
Atelier Ilot Cellule Station Machine
Analyse Niveaux
Niveau 1
hiérarchiques
Niveau 2 Planification
Niveau 3
Niveau 4 Implémentation
Niveaux
d’abstraction
Exploitation
Cycle de vie
d’un système
Figure 2.16. - Proposition d’un cadre de simulation dans un système à trois axes : niveaux
hiérarchiques, niveaux d’abstraction, cycle de vie.
Pour un SdP donné, ayant certains objectifs, il est nécessaire de définir un cadre de simulation
en fonction de ces objectifs, car le niveau de détail du modèle en dépend. Ce cadre de
$
) # * ) ) . +
simulation (figure 2.16) dépend des trois axes exprimant : les niveaux hiérarchiques, les
niveaux d’abstraction et les phases du cycle de vie du système. En effet, l’étude d’un système
est toujours située dans l’une des phases de son cycle de vie ; la conception (analyse et
planification), l’implémentation, l’exploitation. Les objectifs dépendent de ce cycle de vie et
sont différents d’une phase à l’autre. Le niveau de détail pourrait être ainsi exprimé de
manière cohérente, en tenant compte des objectifs, du niveau hiérarchique et du niveau
d’abstraction souhaité en fonction des résultats demandés.
A travers ce cadre de simulation, nous pouvons qualifier les objectifs par rapport à un référent
stable et unanimement reconnu (cycle de vie). La corrélation est forte entre les phases de ce
cycle et les niveaux hiérarchiques et d’abstraction. Ainsi, dans une optique de rationalité, nous
pouvons affirmer qu’en général et pour un objectif se rapportant à :
• la phase d’analyse, le degré d’affinement du modèle peut se limiter au premier niveau
d’abstraction et aux niveaux hiérarchiques atelier ou îlot,
• la phase de planification, le degré d’affinement peut se limiter au deuxième niveau
d’abstraction et au niveau hiérarchique îlot,
• la phase d’implémentation, le troisième niveau d’abstraction et le niveau ressource
élémentaire, sont nécessaires,
• la phase d’exploitation, il faut opter pour le quatrième niveau d’abstraction et le niveau
ressource élémentaire.
4. CONCLUSION
L’analyse conjointe de la simulation informatique et des systèmes de production, nous a

permis de situer les potentiels et les apports, mais aussi les limites actuelles de la simulation
appliquée aux systèmes de production. Nous avons dissocié les limites en deux parties : celles
qui concernent la phase de modélisation et celles qui concernent l’outil de simulation. La
comparaison entre potentiels et limites, nous a permis de définir certains critères d’efficacité
et d’avancer des propositions d’amélioration dans les deux directions.
L’analyse des systèmes de production d’un point de vue de la simulation, s’est concrétisée par
la proposition de concepts génériques. Ces concepts (STP, EC, CP) concernent d’une part, le
processus de fabrication et d’autre part, le processus de pilotage. Ils sont définis dans un
environnement bien adapté et caractérisé par : la structure hiérarchique du système de
production, les graphes d’état de la ressource, la structure globale de pilotage, la structure
locale de pilotage, les relations d’échanges…
Dans le dernier chapitre, nous proposons une formalisation et une modélisation orientée objet
de ces concepts. Le langage UML est ainsi utilisé pour obtenir un méta-modèle du réseau
STP/CP. Le méta-modèle est actuellement en cours d’implémentation avec le langage JAVA
pour donner naissance à la plate-forme Apollo.
$&
) # * ) ) . +
$!
! (
1. INTRODUCTION
Nous avons proposé, dans le deuxième chapitre, les concepts fondamentaux structurant
l’approche proposée, notamment : le STP, l’EC et le CP, ainsi que les structures dans
lesquelles évoluent ces concepts, en particulier : la structure hiérarchique du SdP, les niveaux
d’abstraction d’une ressource, la structure globale et la structure locale du pilotage. Le STP et
l’EC sont les concepts permettant de modéliser le système de fabrication. Le CP est le concept
permettant d’introduire le processus de pilotage dans la simulation et modélisant la partie
décisionnelle du SdP.
Dans la première partie de ce chapitre, nous proposons d’abord, une description formelle de
ces concepts et ensuite, une formalisation permettant de lier les concepts entre eux dans un
réseau appelé le réseau STP/CP. La formalisation étant basée sur une approche orientée objet,
nous décrivons pour chacun de ces concepts ses parties ; structurelle, fonctionnelle et
comportementale. Dans la seconde partie, nous proposons une modélisation du réseau
STP/CP, afin de l’implémenter et d’obtenir une plate-forme appelée Apollo. Ainsi, suite à un
rappel des principaux concepts du langage UML utilisés pour obtenir le modèle conceptuel,
) % *. ) +
nous présentons les différents paquetages30 formés pour la représentation avec le langage
UML de la simulation du réseau STP/CP. Pour chacun d’entre eux, nous décrivons ensuite les
diagrammes de collaboration des objets, ainsi que la signification des relations entre objets :
lien d’association, d’agrégation ou encore de généralisation. Les derniers paragraphes
permettent de mieux appréhender la façon dont est implémenté le modèle sur JAVA, selon les
trois étapes suivantes : l’implémentation du simulateur, l’implémentation des objets du réseau
STP/CP et enfin, l’implémentation de l’interface graphique du modèle.
2. DESCRIPTION D’UN RESEAU STP/CP
Pour mieux comprendre la logique de modélisation du réseau STP/CP, considérons l’exemple

schématisé à la figure 3.1. Le système de fabrication comprend les ressources physiques
suivantes :
• un stock de matières premières,
• un poste de soudure,
• un poste de rectification,
• un stock de produits finis.
Deux opérateurs et un magasinier sont affectés au pilotage de ces postes. Le premier opérateur
gère les postes de stockage de matière première et de soudure, le second gère le poste de
rectifieuse et le magasinier gère le poste de stockage de produits finis [Berchet et al. 99b].
Ces trois personnes sont supervisées par un responsable de ligne. Ainsi, le système de
fabrication est composé de quatre ressources et également des pièces (P1, P2,…, Pq) à
fabriquer. Et le système de pilotage est composé de trois individus sur un premier niveau
hiérarchique et d’un quatrième sur un second niveau.
Responsable
de Ligne
Opérateur Opérateur Magasinier
P1
P2 Stock MP Soudeuse Rectifieuse Stock PF
Pq
Figure 3.1. - Exemple d’un système de fabrication et de son système de pilotage.
Le système de fabrication sera modélisé à l’aide des concepts génériques STP et EC. Ainsi, le
STP représentera les postes et gèrera les informations les concernant (informations
structurelles, fonctionnelles et indicateurs de performance). La structure EC représentera le
30
Un paquetage est un groupement d’éléments de modélisation. Il peut contenir aussi bien des paquetages
emboîtés que des éléments de modélisation ordinaires [Kettani et al. 1998].
$
) % *. ) +
flux physique circulant sur les STPs. C’est cette structure qui comportera les informations
liées aux produits. Quant au système de pilotage, représenté par l’ensemble des opérateurs et
le responsable de ligne, sera modélisé par les CPs.
Ainsi, l’exemple cité peut être représenté, par le méta-modèle des classes du réseau STP/CP,
comme présenté ci-dessous (figure 3.2).
CP4
Système de
Pilotage
CP1 CP2 CP3
Opérationnel
EC1
Système
EC2 STP1 STP2 STP3 STP4
ECq
Figure 3.2. - Méta-modèle des classes du réseau STP/CP.
Le CP est directement associé aux structures à piloter pouvant être des :

• STPs, dans le cas du premier niveau (STP1, STP2, STP3, STP4 pilotés par CP1, CP2, CP3),
• CPs de niveau inférieur (CP1, CP2, CP3 pilotés par CP4).
3. FORMALISATION DU RESEAU STP/CP
Un réseau STP/CP (RSTP/CP) est un ensemble de trois classes d’objets :

• le Système de Transformation du Produit (STP)
• le Centre de Pilotage (CP)
• l’Entité Circulante (EC)
Il est défini formellement par un triplet :
RSTP/CP : <STP ; EC ; CP>
Chacune des trois classes forme un ensemble homogène d’objets, et chaque objet est une
instanciation particulière de la classe, tels que :
STP = {STP1 ; STP2 ; STP3 ;… ; STPn} ensemble fini de processeurs STPs

EC = {EC1 ; EC2 ; EC3 ; … ; ECq} ensemble fini de types d’Entités
CP = {CP1 ; CP2 ; CP3 ; … ; CPp} ensemble fini de Centres de Pilotage
) % *. ) +
3.1. Formalisation du Système de Transformation du Produit (STP)

Chaque STP est défini formellement par un quadruplet de quatre listes de classes d’objets :
• la liste des attributs (liste_attributs),
• la liste des fonctions (liste_fonctions),
• la liste des indicateurs (liste_indicateurs),
• la liste des événements (liste_événements).
STP : <liste_attributs ; liste_fonctions ; liste_indicateurs ; liste_événements>
3.1.1. Liste des attributs du STP
La liste des attributs d’un STP concerne des informations propres. Les valeurs associées aux
attributs correspondent aux données à renseigner par un utilisateur potentiel (en terme d’objet,
il s’agit de son instanciation). Elles permettent d’identifier un STP et de renseigner les
données réelles qui serviront au calcul des indicateurs. La formalisation de la liste des
attributs est la suivante :
liste_attributs_STP : 
Tels que :
I : Identificateur correspondant au nom du STP, attribut alphanumérique
C : Capacité du STP définissant un nombre de ressources identiques, attribut numérique
C = {0 ; 1 ; 2 ; … ; n} ensemble fini entier
Sachant qu’un stock est modélisé par un STP, la capacité n’est en générale pas limitée.
Cal : Calendrier d’ouverture du STP

Cal : <durée1*C1 ; durée2*C2 ; … ; duréek*Ck> attribut réel*attribut entier
tel que : Σduréei = 1 cycle (1 jour de 24 heures par exemple)
Le calendrier définit les heures d’ouverture et de fermeture, planifiées pour un STP ainsi que
sa capacité durant ses heures.
Lp : Loi des pannes et des réparations

Un historique de pannes sur une ressource de production permet de mieux refléter la réalité.
Après analyse et traitement de cet historique, il est possible de générer des pannes dans le
modèle de simulation, en utilisant les distributions aléatoires correspondantes.
Le logiciel ADONIS (http://www.ogp-annecy.com) permet d’analyser un historique de pannes
et de trouver une distribution correspondant aux besoins exprimés en simulation.
TCS : temps de changement de série par STP

TCS : <… ; ECi*ECi+1*Durée ; …>
Le temps de changement de série est défini en fonction de l’ordre de passage des types
d’entités sur un STP.
Tr : taux de rebut par STP

Tr = {X% ou fonction mathématique}
Le taux de rebut définit le pourcentage de production rebutée sur un STP ainsi que la loi
d’évolution de ce taux en fonction de la loi de dégradation de la ressource dans le temps.
#
) % *. ) +
Rd : rendement ou allure du STP

Rd = {Y%}
Le rendement d’un STP défint son allure, donc sa cadence de production par rapport à une
cadence nominale. La cadence réelle est ainsi obtenue par augmentation ou diminution du
temps opératoire défini par la gamme.
3.1.2. Liste des fonctions du STP
Les fonctions correspondent principalement aux variables qui seront utilisées dans la logique
de changement d’état d’un objet en vue de la modification de son état. Un STP possède quatre
fonctions principales. Ainsi, la liste des fonctions est définie formellement par un quadruplet :
liste_fonctions_STP : <L ; R ; T ; F>
Tels que :
L : Charge du STP
L = {0, 1, 2, …, m} ensemble fini entier avec L ≤ C
La charge est une variable entière du STP, elle doit rester inférieure ou égale à sa capacité.
R : fonction de réception du STP

R = {0 ou 1} variable logique binaire
La fonction de réception R prendra ses valeurs de la manière suivante :
R = 1 (le STP peut réceptionner) si
L < C le STP est totalement ou partiellement libre.
R = 0 (le STP ne peut pas réceptionner) si
C = 0 le STP est en état indisponible planifié (non ouvert, maintenance préventive...),
Ou le STP est en état indisponible subi (panne, réparation, changement de série…)
Ou L = C le STP est saturé.
T : fonction de transformation du STP

T = {0 ou 1} variable logique binaire
La fonction T est égale 0 si la durée opératoire est terminée ou le STP est libre, sinon la
fonction T vaut 1. La durée opératoire d’une entité est définie dans sa gamme. Cette durée
peut être nulle dans le cas d’une opération de stockage.
F : fonction de fourniture du STP

F = {0 ou 1} variable logique binaire
La fonction de fourniture F prendra ses valeurs de la manière suivante :
F = 1 (le STP est en état de fournir) si
L > 0 ET tcourant ≥ tfin(op) (le STP peut fournir une entité s’il est occupé et si le temps de
transformation est terminé)
F = 0 (le STP n’est pas en état de fournir) si
L = 0 (le STP n’est pas en état de fournir s’il n’est pas occupé),
Ou L > 0 ET tcourant < tfin(op) (le STP n’est pas en état de fournir s’il est occupé mais le
temps de transformation n’est pas terminé)
Ou le STP est indisponible (panne, réparation, changement de série, maintenance…)
%
) % *. ) +
3.1.3. Liste des indicateurs du STP
Les indicateurs sont des fonctions qui dépendent des valeurs associées aux attributs et aux
variables d’un STP à tout moment. La valeur d’un indicateur est mise à jour pendant
l’évolution temporelle de l’état du STP en cours de simulation (indicateurs de processus) et en
fin de simulation (indicateurs de résultats). Certains des indicateurs de performance affectés à
un STP seront fondés sur les indicateurs de la démarche TPM. Les informations nécessaires à
la formalisation de ces indicateurs en fonction de cette démarche sont explicitées selon le
schéma suivant :
TO : temps d’ouverture du STP ou temps requis Σ des arrêts programmés ou
(production théorique) planifiés (selon un calendrier)
Σ arrêts - Pannes
- Changement de série (CS)
Temps brut de fonctionnement du STP subis - Rupture (matière, production)
- Réglages…
Temps net de fonctionnement Σ ralentissements
(Production réalisée) Ecart de performance - Coefficient de ralentissement (allure)
- Arrêts mineurs
Temps utile Σ non - Rebuts

(Production bonne) qualité - Retouches
- Pertes au redémarrage
Figure 3.3. - Données pour les indicateurs de la TPM.
Ainsi, les indicateurs affectés à un STP seront formalisés de la manière suivante (figure 3.4) :
Indicateur Formalisation
TYPE COMPTEUR
Nombre de pièces fabriquées totales Compteur (incrémenté à chaque fin d’opération)
Nombre de pièces fabriquées par type Compteur (incrémenté à chaque fin d’opération de même type)
Nombre de pannes Compteur (incrémenté à l’occurrence de chaque événement de
type panne)
Nombre de changements de série (CS) Compteur (incrémenté à chaque changement de série)
Nombre de pièces rebutées Compteur (incrémenté en fin d’opération et suite à un tirage de
pièce rebutée)
Nombre de pièces bonnes Compteur (incrémenté en fin d’opération et suite à un tirage de
pièce bonne)
TYPE TEMPS
Temps requis Temps de simulation – temps planifiés pour fermeture
Temps total de CS Σ temps de CS
Temps total de panne Σ temps de panne
Temps de rupture Σ temps de non-production non planifiés (temps pendant lequel
le STP peut produire mais le STP précédent ne peut fournir)
Temps d’arrêts subis Temps total de CS + Temps total de panne + Temps de rupture
Temps brut Temps requis – Temps d’arrêts subis
Temps utile Σ temps de fabrication de pièces bonnes
Temps de non-qualité Σ temps de fabrication de pièces rebutées
Temps net Temps utile + Temps de non-qualité
Temps de ralentissement Temps brut – Temps net
Temps de cycle réel moyen Temps requis / Nombre de pièces bonnes
Temps moyen de CS Σ temps de CS / nombre de CS
Temps moyen de panne Σ temps de panne / nombre de pannes
) % *. ) +
TYPE TAUX
Taux d’ouverture Temps requis / Temps de simulation
Taux de Rendement Synthétique (TRS) Temps utile / Temps requis
Taux brut de fonctionnement (Disponibilité) Temps brut / Temps requis
Taux de performance Temps net / Temps brut
Taux de qualité Temps utile / Temps net
Taux de panne Σ temps pannes / Temps requis
Taux de non-qualité 1 – Taux de qualité
Taux de CS Σ temps CS / Temps requis
Taux de rupture Temps de rupture / Temps requis
Figure 3.4. - Formalisation des indicateurs d’un STP.
3.1.4. Liste des événements du STP
Pour décrire le comportement du STP, donc sa logique de changement d’état, nous utiliserons
l’approche par événement. Tout type d’événement sera caractérisé au moins par les deux
informations suivantes :
Event : 
Tels que :
I : Identificateur de l’événement, attribut alphanumérique
Date_occ : Date d’occurrence de l’événement, attribut réel positif
Pour formaliser les événements associés à un STP, considérons un processus composé de trois
STPs nommés dans l’ordre du processus : STPi-1, STPi et STPi+1 comme le montre la figure
3.5.
STPi-1 STPi STPi+1
Figure 3.5. - Exemple d’un processus de fabrication modélisé par un ensemble de STPs.
Un STP possède une liste de deux événements principaux :
liste_event_STP : <event_fin_op() ; event_fin_cs()>
La logique de changement d’état du STP est décrite par les deux événements ainsi que les
fonctions suivantes : fournir, recevoir, bloquer, panne, jeter, régler.
Outre l’identificateur et la date d’occurrence, un événement associé à un STP aura la

formalisation suivante :
event_type : 
Avec :
EC : Entité associée à cet événement
STPsource = STPi-1 ; STPcourant = STPi ; STPcible = STPi+1
) % *. ) +
Logique de l’événement : event_fin_op(STPcourant)

Début
/Test de panne : y’a-t-il eu panne sur STPcourant ?/

Si oui alors exécuter fonction_panne
Sinon
/Test de qualité : l’entité fabriquée est bonne ou mauvaise ? (Si taux rebut > 0 => tirer qualité)/
Si entité mauvaise
Exécuter fonction_jeter
/Est-ce que mon fournisseur STPsource peut me fournir ?/

Si oui
/Tester CS (STPcourant)
Si /type_entite différent de type_entite précédent et nécessite un CS/
CS = vrai
Exécuter fonction_régler
Sinon CS = faux
Exécuter fonction_fournir (STPsource) /mon fournisseur me fournit/
Exécuter fonction_recevoir (STPcourant) /je reçois/
Fin si
Fin si
Sinon (entité bonne)

Nb_entité_bonnes = Nb_entité_bonnes + 1
Rechercher dans la gamme le STPcible
/Est-ce que mon client STPcible peut recevoir ?/

STPcible.(L) < STPcible.(C) ?
Si oui
/Tester CS (STPcible)
Si /type_entite différent de type_entite précédent et nécessite un CS/
CS = vrai
Sinon CS = faux
Exécuter fonction_fournir (STPcourant) /je fournis/
Exécuter fonction_recevoir (STPcible) /mon client reçoit/
Fin si
/Est-ce que mon fournisseur STPsource peut me fournir ?/
Si oui
/Tester CS (STPcourant)
Si /type_entite différent de type_entite précédent et nécessite CS/
CS = vrai
Sinon CS = faux
Exécuter fonction_fournir (STPsource) /mon fournisseur me fournit/
Exécuter fonction_recevoir (STPcourant) /je reçois/
Fin si
Fin si
Sinon /client ne peut pas recevoir/
Exécuter fonction_bloquer / je me bloque/
Fin si
Fin si
Fin si
Supprimer événement Fin_operation
Fin
) % *. ) +
Logique des différentes fonctions à exécuter :
fonction_fournir L=L–1
tf(r)op = tps_courant
R=1
/Test de l’état bloqué ?/
si oui
supprimer état bloqué
tps_blocage = tps_courant – date_blocage
Σtps_blocage = Σtps_blocage + tps_blocage
sinon Fin
Fin si
fonction_recevoir L=L+1
td(r)op = tps_courant
Si L < C alors R = 1
Sinon R = 0
tps_fin_operation = tps_courant + tps_operatoire
Insérer événement Fin_operation dans liste avec tps_fin_operation
fonction_bloquer Etat = bloqué /blocage : une entité sur un STP/

Date_blocage = tps_courant
fonction_régler /Si la durée du CS est aléatoire : tirer tps-CS/

tps_fin_CS = tps_courant + tps_CS
Insérer événement Fin_CS dans liste avec tps_fin_CS
Nb_CS = Nb_CS +1
R=0
Date_CS = tps_courant
fonction_jeter L=L–1
Nombre_entite_rebutees = Nombre_entite_rebutees + 1
R=1
fonction_panne /Si la durée de la panne est aléatoire : tirer duree_panne/

Mettre à jour les variables d’état (calculer les indicateurs concernés)
Bloquer entité encours sur STPcourant
Tps_fin_operation = tps_courant + duree_panne
Fin
Logique de l’événement : event_fin_cs(STPcourant)

Début
R=1
Tps_CS = tps_courant – date_CS
Σtps_CS = Σtps_CS + tps_CS
/Est-ce que mon fournisseur STPsource peut fournir ?/

Si oui
Exécuter fonction_fournir de STPsource
Exécuter fonction_recevoir STPcourant
Fin si
Supprimer événement Fin_CS
Fin
&
) % *. ) +
3.2. Formalisation de l’Entité Circulante (EC)

L’entité est l’objet représentant l’élément du flux physique. Elle peut être définie par un objet
unitaire ou un assemblage d’objets unitaires ou composés (selon un processus récursif).
Nous définissons de manière formelle cette entité par le quadruplet suivant :
EC : <liste_attributs ; liste_fonctions ; liste_indicateurs ; liste_événements>
3.2.1. Liste des attributs de l’EC
La liste des attributs concerne des informations propres de l’Entité Circulante. Elles
permettent d’identifier l’Entité et de renseigner les données réelles qui serviront au calcul des
indicateurs qui lui sont associés. Ces attributs sont les suivants :
liste_attributs_EC : 
Tels que :
I : Identificateur, attribut alphanumérique correspondant au type de l’entité
DL : Date de lancement en fabrication de l’entité, attribut réel
G : Gamme de l’entité
La gamme est un sous-objet de l’entité et est définie formellement par un quadruplet :

G : 
Tels que :
I : Identificateur de la gamme, attribut alphanumérique
Si : Numéro d’opération = {10 ; 20 ; 30 ; …} ⊂ N*
STPi : Identificateur du STP nécessaire pour réaliser l’opération
topi : Temps opératoire unitaire, attribut réel
3.2.2. Liste des fonctions de l’EC
liste_fonctions_EC : <Créer ; Grouper ; Associer ; Dissocier ; Copier ; Supprimer>
La fonction Créer permet de générer des entités à lancer dans le système.

La fonction Grouper permet de réaliser un groupement définitif (assemblage) pour générer un
produit fini à partir de composants ou d’autres groupements.
La fonction Associer permet de réaliser un groupement provisoire de pièces identiques pour
générer un lot nécessaire au transport ou autre opération.
La fonction Dissocier permet d’éclater un groupement provisoire réalisé à l’aide de la
fonction Associer.
La fonction Copier permet de réaliser des copies d’entités dans le système.
La fonction Supprimer permet de réaliser des suppressions d’entités dans le système
(livraison aux clients par exemple en fin de production).
!
) % *. ) +
3.2.3. Liste des indicateurs de l’EC
Les données récupérées de la simulation au niveau de l’entité, sont essentiellement des dates
de début ou de fin d’opération sur les STPs. Nous utilisons ces dates pour renseigner les
indicateurs concernés (figure 3.6).
Indicateur Formalisation
Dd(r)op : date de début réelle de l’opération Obtenue par affectation du temps courant lors de la simulation
sur le STP concerné dans la fonction RECEVOIR du STP
Dd(r)op = Tcourant
Df(r)op : date de fin réelle de l’opération sur le Obtenue par affectation du temps courant lors de la simulation
STP concerné dans la fonction FOURNIR du STP
Df(r)op = Tcourant
Temps de production pour une entité Date de fin réelle de l’opération sur le dernier STP – date de
l’arrivée de l’entité sur le premier STP
Df(r)op (dernier STP) - DateLancement
Temps moyen de production par type d’entité Σ des temps de production par types d’entités / nombre
d’entités fabriquées de même type
Temps de cycle de production de l’entité Indicateur associé à l’entité, mais calculé en fonction des
données du STP, donc voir indicateurs du STP
Figure 3.6. - Indicateurs liés à l’Entité Circulante.
3.2.4. Liste des événements de l’EC
L’opération de génération est nécessaire pour lancer les entités dans le processus de
fabrication. Outre, l’identificateur et la date d’occurrence, l’événement de lancement des
entités est caractérisé par les informations suivantes :
Event_type : 
Tels que :
I : Identificateur de l’événement, attribut alphanumérique
Date_occ : Date d’occurrence de l’événement, attribut numérique réel positif
EC : Type d’entité concernée par cet événement
Q_lot : Nombre maximal de lots à lancer de ce type d’entité, attribut entier positif
Taille : Taille de lot, attribut entier positif
Inter : Intervalle entre le lancement des entités ou lots, attribut réel positif
STP : Premier STP où les entités seront lancées (stock matière première)
Une entité possède la liste d’événements suivante :
liste_event_EC : <event_lancer()>
Logique de l’événement : event_lancer(EC)

Début
Exécuter la fonction Créer_EC
Faire Nb_ent_cr = Nb_ent_cr + 1
Si Nb_ent_cr ≤ Q_lot
"
) % *. ) +
Exécuter la fonction Copier_EC autant de fois Taille

Envoyer entités sur STP concerné (stock matière première)
Exécuter fonction_recevoir(STP)
Faire Date_occ = tps_courant + inter
Remplacer la date d’occurrence de l’événement par Date_occ
Sinon
Fin
3.3. Formalisation du Centre de Pilotage (CP)
3.3.1. Analyse fonctionnelle du CP
Pour étudier le comportement du CP, nous décrivons formellement chacun des éléments du
quadruplet suivant :
CP : 
Avec :
I : Identificateur du CP, attribut alphanumérique
Il s’agit de l’acteur décideur (organe de planification et de décision).
IP : Indicateur de Performance
L’indicateur de performance est l’outil d’aide à la décision du CP. Il peut être un indicateur de
processus ou/et un indicateur de résultat. Pour sa formalisation, nous nous basons en partie sur
les travaux déjà réalisés au LLP/CESALP [Berrah 1997]. Nous reprenons en partie, la
définition formelle de l’indicateur de performance selon le triplet suivant :
IP : <O ; M ; P>
Tels que :
O : Objectif du CP
O : 
L’objectif correspond à un état espéré du système ou de l’un de ses éléments. Il est identifié
formellement d’une part, par un identificateur ou un référent, et d’autre part, par un ensemble
de valeurs correspondant à une valeur minimale, une valeur nominale et une valeur maximale.
M : Mesure associée à l’indicateur de performance

La mesure est extraite du processus physique et peut être de type événementiel Me associée à
l’occurrence d’un événement ou périodique Mp selon une périodicité p.
P : Calcul de la Performance
P : 
Par rapport aux travaux déjà réalisés, nous nous limitons ici à l’identificateur, au mode de
calcul de la performance et à l’état de dérive.
En fait, le calcul de la performance ici, correspond à la comparaison de la mesure avec une ou

plusieurs valeurs associées à l’objectif.
• Dans le cas d’un pilotage « a posteriori », l’objectif équivaut à une expression de contre
performance, que nous appellerons seuil limite SL, valeur à ne pas dépasser pour répondre
#$
) % *. ) +
à l’objectif espéré. Dans ce cas, le calcul de la performance du système correspond à la

comparaison de la valeur mesurée Mp au seuil limite SL.
• Dans le cas d’un pilotage « réactif pour anticipation », le calcul de la performance
correspond à la comparaison de la valeur mesurée Me à un seuil d’alerte SA. C’est un
seuil limite auquel est rajouté un degré de flexibilité, rendant l’objectif initial O plus
sévère ou plus permissif.
Dans les deux cas, l’atteinte du seuil limite ou du seuil d’alerte provoque l’état de dérive, état
qui lancera le processus interne de prise de décision du CP. C’est lors de cette étape où nous
validons l’état de dérive ou de non-dérive, que nous évaluons la performance. Il y a dérive D
lorsque le comportement du système n’est pas le comportement attendu. L’expression de
l’état de dérive est à définir initialement et l’état est connu après évaluation du calcul de la
performance. Cet état de dérive D est une fonction du mode de calcul de la performance.
D = f(M, O)
D = {0 ou 1} variable logique binaire
Ceci peut se traduire par exemple par :
• un résultat négatif, positif ou nul, de la soustraction de la mesure M par rapport à l’objectif
O ; si O représente une valeur nominale, D = 1 (il y a dérive) si P ≠ 0 et D = 0 (il n’y a
pas dérive) si P = 0
• une tendance calculée de pente descendante ou ascendante ; D = 1 si P est une fonction
ayant une pente < 0…
• une suite « inquiétante », comme par exemple « plus de trois mesures M au-dessus de la
valeur du seuil d’alerte » ; D = 1 si Pn-2 < 0 et Pn-1 < 0 et Pn < 0
Li : Liste des inducteurs (i)

Li = {i1 ; i2 ; i3 ;…, in}
i : <Ii ; IPi>
La liste des inducteurs (liste des causes) est associée à l’indicateur IP. L’atteinte d’un seuil
d’alerte ou limite déclenche l’état de dérive D et la recherche de l’inducteur i éventuellement
responsable parmi la liste Li. Une cause est vérifiée et validée grâce à un indicateur
secondaire. Chaque inducteur est ainsi lié à un indicateur de performance secondaire IPi.
Tels que :
Ii : Identificateur de l’inducteur, attribut alphanumérique.
IPi : Indicateur de Performance de l’inducteur
IPi :<Oi ; Mi ; Pi>
La formalisation des éléments de l’indicateur secondaire IPi est identique à celle de

l’indicateur principal IP.
La : Liste des actions (a)

La = {a1 ; a2 ; a3 ;… ; an}
a : <Ia ; Va ; TRa>
Une liste d’actions La est associée à la liste Li. Ainsi, la dérive d’un inducteur déclenche la
recherche de l’action a éventuellement capable de retrouver le comportement attendu du
système, parmi la liste des actions. Cette liste est constituée des actions pouvant être
appliquées sur le système. L’application d’une action se traduit par la modification de la
valeur associée à une variable ou un attribut des objets constituants le réseau STP/CP.
#
) % *. ) +
Tels que :
Ia : Identificateur de l’action, attribut alphanumérique.
Va : Variable d’action pouvant être associée à un STP ou un CP de niveau inférieur. Une
variable d’action peut être liée à plusieurs inducteurs.
TRa : Temps de Réaction de l’action. Il correspond au temps nécessaire pour mettre l’action
en place, donc le décalage entre le choix de l’action et la modification de la variable
associée.
L’effet de l’action mise en place sera évaluée par simulation interne. Une copie interne du
réseau STP/CP est faite au même instant. Cette copie du modèle servira à l’évaluation de
l’action avant application définitive.
3.3.2. Analyse comportementale du CP
3.3.2.1. Processus de pilotage du CP
Dans le deuxième chapitre, nous avions proposé le fonctionnement global du CP, selon le
schéma suivant (figure 3.7) :
CP
CENTRE DE PILOTAGE
Informations
ACTEUR(S)- intrinsèques et Informations
DECIDEUR(S) endogènes extrinsèques
Processus de prise de décision
et exogènes
CP 3-Décision 2-Evaluation CP
Indicateurs de
performance
Ressources 4-Application du
1-Mesure
plan d’action
Système à piloter
Figure 3.7. - Fonctionnement global du CP et rôle de ses composants.
Le processus de pilotage du CP, comporte quatre étapes principales : la mesure, l’évaluation,

la décision et l’application du plan d’action. Le processus de prise de décision du CP
(évaluation et décision) est basé sur le modèle « IMC » (Intelligence, Modélisation, Choix)
proposé par H. Simon en 1960 [Le Moigne 1974]. Ce modèle montre l’imbrication étroite des
notions de décision et d’information, qui a son importance pour l’étude des performances et
pour la conception d’un système de décision efficace. De manière générale, un processus de
décision consiste à restreindre un ensemble de possibilités à un sous-ensemble strict et à
évaluer cette restriction. Le processus de prise de décision du CP résume dans notre modèle
trois étapes d’évaluation : l’évaluation de la performance du système piloté, l’évaluation de
l’inducteur en cas de dérive, et l’évaluation du plan d’action à mettre en place (la simulation
interne). Le processus interne du CP est détaillé sur la figure 3.8.
##
) % *. ) +
CENTRE DE PILOTAGE (CP)
Réseau STP simulé
Suspension du temps de
Mesure simulation actuelle
Evaluation : comparaison de la mesure par
rapport à l’objectif
Evaluation de la Simulation interne du
performance plan d’action
Evaluation du plan d’action
Oui Identification d’un plan

Dérive ? Lire l’historique des actions
d’action
Oui
Non
Dérive ?
Evaluation Evaluer la dérive
Choix d’une cause

Evaluation des inducteurs
Oui et fin liste Identification des

actions inducteurs Lire l’historique des inducteurs
Non
Oui
Interrogation des Non
Dérive ? Test : résultat de l’évaluation
inducteurs externes
Evaluation de la performance Evaluation : comparaison de la mesure par

rapport à l’objectif (seuil d’alerte)
Application du plan Me : lecture d’une variable événementielle

Mesure Mp : lecture d’une variable périodique si
d’action
tcourant = k×tp (k=entier)
SYSTEME A PILOTER
Figure 3.8. - Comportement interne détaillé du CP.
3.3.2.2. Etapes du processus de pilotage du CP
Le processus de pilotage du CP comporte les 7 étapes suivantes.
1. Prise de mesure
Lors de cette étape, il s’agit de récupérer la mesure qui peut être soit événementielle Me soit
périodique Mp. La mesure est relevée ou fournie par un STP, une Entité ou un CP de niveau
inférieur. Cette mesure concerne l’indicateur principal et les indicateurs secondaires associés
aux inducteurs qu’un CP doit suivre.
2. Evaluation de la performance du système piloté

L’évaluation de la performance du système piloté se fait en deux étapes : d’abord, le calcul de
la performance (comparaison de la mesure avec l’objectif), et ensuite l’évaluation de cette
#%
) % *. ) +
performance (analyse de cette comparaison pour déduire un état de dérive ou de non-dérive

du système).
Dans le cas d’une dérive, le processus de pilotage est poursuivi pour identifier l’inducteur
interne responsable. Dans le cas de non-dérive, le comportement du système étant celui qui
est attendu, le processus de pilotage est stoppé.
3. Identification de l’inducteur interne

L’identification de l’inducteur est essentielle pour construire un système de pilotage. Il s’agit
de déterminer les ressources critiques dans le processus suivi et les principaux facteurs qui
agissent sur la performance de ces ressources (leurs inducteurs). Chaque CP est responsable
de ses propres inducteurs. Ainsi, si l’inducteur est externe au CP, ce dernier attend que le CP
responsable le traite, mais peut prendre des mesures préventives.
4. Evaluation de l’inducteur interne

Cette étape consiste à mettre en évidence, parmi la liste des inducteurs, ceux qui sont
responsables de la dérive de l’indicateur principal suivi du CP. Les inducteurs sont évalués
grâce aux indicateurs de performance secondaires.
5. Identification du plan d’action

Une fois que l’inducteur interne est identifié et évalué, nous chercherons à identifier la liste
des actions La correspondant à cet inducteur et pouvant améliorer la situation.
6. Evaluation du plan d’action

L’évaluation du plan d’action correspond à une « simulation dans la simulation », appelée
simulation interne ou « reflective simulation » [Novak 2000] [Kindler 2000]. L’objectif est
de tester les actions à l’aide d’une copie du modèle de simulation avant application définitive.
La simulation interne se décline en trois étapes : simulation du plan d’action, prise de mesure
simulée, évaluation de la performance du système piloté simulé.
7. Application du plan d’action

Si l’action évaluée a permis de rétablir la situation de non-dérive, elle sera appliquée sur le
système piloté. Cette étape se compose des différentes opérations suivantes.
• Appliquer le plan d’action choisi sur le système à piloter pendant une durée donnée. Ceci
signifie que les valeurs de certains attributs ou variables vont être remplacées par les
valeurs caractérisant le plan d’action, après un certain temps correspondant au temps de
mise en place des actions.
• Dans le cas où des inducteurs externes auraient été identifiés dans la liste des messages
d’avertissement, un plan d’action préventif sera également mis en place.
• Reprendre le déroulement de la simulation en cours.
Le processus de pilotage est ainsi terminé, il ne reprendra qu’à la détection d’une autre dérive.
3.3.2.3. Emission et réception des messages de coopération et de coordination

entre CPs
Suite à la première analyse des relations d’échange entre CPs, présentée dans le deuxième
chapitre, nous avons vu que les relations de coopération et de coordination avaient pour
support les messages d’avertissement circulants entre CPs. Ces messages peuvent être
#
) % *. ) +
verticaux ascendants, descendants ou horizontaux. La figure 3.9 schématise ces messages

ainsi que leurs points d’émission et de réception qui seront explicités dans le paragraphe qui
suit [Berchet et al. 2000] [Berchet et al. 2001].
CENTRE DE PILOTAGE
Evaluation du plan d’action
Oui
5 COOPERATION / COORDINATION
Dérive ?
ENTRE CPs et SYSTEME A PILOTER
Identification des plans d’action Émission : messages 1 à 8
Réception : messages 9 à 11
Oui 2
Non
Dérive ?
Evaluation des inducteurs

internes
Oui et fin
liste actions Identification des inducteurs
3 internes
Non Non
Oui 1 4
Dérive ?
6
Interrogation des
9 inducteurs externes
Evaluation de la performance 11
Application du plan
Mesure
d’action
8 7 10
SYSTEME A PILOTER
Figure 3.9. - Emission et réception des messages d’avertissement entre CPs.
Emission de messages horizontaux :
1. mon objectif n’est pas atteint : en cas de dérive, le CP avertit les CPs voisins afin que
ceux-ci prennent, le cas échéant, les dispositions nécessaires et préventives de leur côté.
2. j’ai cerné les causes de ma dérive : suite à sa dérive, le CP a recherché ses inducteurs,
puis les a évalués et cernés. Il avertit alors les CPs voisins de ces causes, afin qu’ils prennent,
le cas échéant, les dispositions nécessaires.
3. j’ai trouvé l’action rétablissant ma situation : le CP a trouvé parmi sa liste d’actions et
suite à l’évaluation de cette action, celle qui rétablissait la situation de non-dérive. Il avertit
les CPs voisins de cette action qui va être mise en application : il fournit ainsi les paramètres
de l’action, son temps de réaction et le résultat attendu à la fin de ce temps.
Emission de messages verticaux ascendants :
4. mon objectif n’est pas atteint ou mon objectif est atteint : suite à une demande d’état de
la situation par rapport à l’objectif fixé, le CP donne à son CP supérieur un résultat de dérive
ou de non-dérive suite à l’évaluation de la performance de son système.
#
) % *. ) +
5. j’ai testé toutes les actions possibles prévues, mais aucune ne rétablit la situation : le
CP a évalué toutes les actions possibles des inducteurs ayant une dérive, mais aucune ne
rétablit la situation. Il avertit son CP supérieur de cette conclusion, pour que ce dernier
analyse l’ensemble des résultats de ses CPs et détermine l’origine du problème (certains
objectifs seront éventuellement revus).
6. mon objectif est rétabli : le CP a trouvé, parmi sa liste d’actions, celle qui rétablissait la
situation. Il avertit son CP supérieur que son objectif va être atteint suite à cette action dans
une durée égale au temps de réaction de cette action.
Emission de messages verticaux descendants :
7. je modifie les paramètres de mon STP – je modifie l’objectif de mon CP : suite à une
action, le CP modifie les paramètres sur son STP à piloter au niveau opérationnel. S’il s’agit
d’un CP de niveau supérieur, il modifiera l’objectif du CP piloté.
8. quelle est ta situation actuelle : le CP supérieur peut demander un compte-rendu de la
situation d’un CP par rapport à son objectif, qui deviendra, pour lui, une mesure à évaluer par
rapport à ses propres objectifs.
Réception de messages horizontaux :
9. y’a-t-il de messages de mes CPs voisins : suite à la réception de messages des CPs
voisins, le CP concerné peut décider d’appliquer une action préventive sur son système, si ces
messages peuvent avoir une influence sur le comportement du système à piloter.
Réception de messages verticaux ascendants :
10. y’a-t-il de messages de mes CPs inférieurs : suite à la réception de messages

d’avertissement des CPs inférieurs, le CP supérieur évalue sa performance en fonction de ces
nouvelles informations et de son propre objectif.
Réception de messages verticaux descendants :
11. y’a-t-il de messages de mon CP supérieur : le CP doit prendre en compte les messages
de ses CPs supérieurs comme dans le cas de modification de son objectif, dans le cas de
rendre compte de son état...
#
) % *. ) +
3.3.3. Logique de pilotage du CP
Pour décrire la logique de pilotage du CP, nous considérons les notations suivantes :
O : Objectif de l’indicateur principal (exemple, O : maintenir le niveau d’un stock en dessous

de 25 pièces, avec déclenchement d’action préventive à 20 pièces)
SA : Valeur du seuil d’alerte de l’indicateur principal (ici SA = 20 pièces)
SL : Valeur du seuil limite de l’indicateur principal (ici SL = 25 pièces)
Me : Mesure événementielle
Mp : Mesure périodique
P : Performance du système telle que P = Mp – SL ou P = Me - SA
D : Dérive ; si P > 0 (c’est à dire que la mesure est supérieure à l’objectif)
Li : Liste des inducteurs liés à l’objectif principal (O) Li = {i1 ; i2 ; … ; in}

Avec i : inducteur (STP en panne, CSTP = 0)
n = nombre d’inducteurs
Mi : Mesure de l’inducteur
Oi : Objectif de l’indicateur secondaire
SLi : Seuil limite à ne pas atteindre, traduisant Oi
SAi : Seuil d’alerte à ne pas dépasser, traduisant Oi
Pi : Performance du système suivi telle que Pi = Mpi – SLi ou Pi = Mei - SAi
Di : Dérive ; si Pi > 0 (c’est à dire que la mesure est supérieure à l’objectif)
La : Liste des actions liées à l’inducteur i La = {a1 ; a2 ; … ; am}

Avec a : action (STP en réparation, CSTP = 0 pendant 0.5 heure, CSTP = 1 ensuite)
m : nombre d’actions
Ms : Mesure du système piloté simulé
Ps : Performance du système simulé telle que Ps = Mps – SL ou Ps = Mes - SA
Ds : Dérive ; si Ps > 0 (c’est à dire que la mesure est supérieure à l’objectif)
#&
) % *. ) +
Mesure
Début: Si tcourant = k×tp Alors lire Mp OU Si événement lire Me
Evaluation de la performance
Mettre à jour l’objectif (Lire Liste_avertissement_verticale)
Faire : P = M – O (Comparaison du résultat d’analyse à l’objectif)
Si P < 0 alors O = vrai et D = faux
Interroger liste_avertissement_horizontale concernant le CP et Mener action (préétablie)
Fin : aller à Début: (attendre la prochaine mesure)
Sinon O = faux et D = vrai
Ajouter message dans liste_avertissement_verticale et liste_ avertissement_ horizontale
Aller à Induct:
Fin si
Identification et évaluation des inducteurs internes

Induct: Lire premier inducteur i1 dans Li
Faire : Pi = Mi – Oi de i1
Si Pi < 0 alors Oi = vrai et Di = faux
10: Alors faire n = n+1
Lire in+1 dans Li
Faire : Pi = Mi – Oi de in+1
Si Pi < 0 alors Oi = vrai et Di = faux
Alors aller à 10:
Identification des plans d’action

20: Sinon
Ajouter un message d’avertissement dans Liste_avertissement_horizontale
Lire première action a1 dans La
Appliquer a1 sur une durée ∆t
Si pas Evaluation de l’action
Interroger liste_avertissement_horizontale concernant le CP
Appliquer action préventive (préétablie)
Fin : aller à (début) (attendre la prochaine mesure)
Sinon continuer vers Evaluation de l’action
Fin si
Evaluation de l’action (simulation interne)

Si tsimulé = tfin application
Faire : Ps = Ms – SA
Si Ps < 0 alors O = vrai et D = faux
Alors Appliquer a1 sur STP réel pendant ∆t
Ajouter message dans listes concernées
Fin : aller à Début:
Action: Sinon Lire action suivante am+1
Appliquer am+1 sur une durée ∆t
Si tsimulé = tfin application
Faire : Ps = Ms – SA
Si Ps < 0 alors O = vrai et D = faux
Mise en place de l’action

Alors Appliquer a1 sur STP réel pendant ∆t
Ajouter message dans listes concernées
Fin : aller à Début:
Sinon aller à Action:
Fin si
Fin si
Sinon aller à 20:
Fin si
Fin
#!
) % *. ) +
Après avoir décrit et formalisé les concepts, nous proposons dans la partie suivante de
représenter le réseau STP/CP et ses classes d’objets, par le langage formalisé UML, en vue
d’une implémentation dans une plate-forme de simulation.
4. MODELISATION ORIENTEE OBJET DU RESEAU STP/CP
4.1. La Simulation Orientée Objet (SOO)

Depuis le milieu des années 80, la recherche et le développement des outils de simulation
orientés objet ont eu une croissance relativement importante [Roberts et al. 1998]. Plusieurs
langages et environnements supportant la SOO ont été développés. Si les avantages de la
SOO sont nombreux, il y a aussi des inconvénients qui souvent obligent les chercheurs à
utiliser des langages et environnements traditionnels. L’avantage typiquement cité est la
capacité de modélisation en utilisant des entités naturelles aux systèmes [Booch 1991].
D’autres avantages fréquemment cités concernent la rapidité de développement,
l’amélioration de la qualité et de la maintenance, la réutilisation des modèles, la modularité...
[Bischak et al. 1991] [Rothenberg 1986]. Néanmoins, parmi les inconvénients de la SOO,
figurait la vitesse d’exécution qui représentait l’un des freins majeurs. Mais, actuellement vu
les progrès réalisés, elle est équivalente à celle des langages traditionnels. Il faut noter
cependant que la SOO nécessite des connaissances fondamentales plus larges sur les
mécanismes de la programmation [Ball et al. 1994] et le développement initial de classes
d’objets nécessite plus de temps. Le premier langage à regrouper données et procédures fût
SimulaI [Dahl et al. 1966]. Simula [Birtwistle et al. 1973] qui fût le successeur de SimulaI, a
formalisé le concept d’objet ou d’instance et de classe (une classe s’inscrit dans une hiérarchie
d’héritage et sert à spécifier un comportement commun à un ensemble d’objets appelés
instances de la classe). Smalltalk, un langage général orienté objet, développé au début des
années 80, était l’une des contributions les plus significatives selon l’orientation objet
[Goldberg 1984]. Héritier direct de Simula, Smalltalk72 [Kay et al. 1976] introduit l’envoi de
message qui permet aux objets de communiquer entre eux. Depuis, Smalltalk a subi de
nombreux travaux visant à son amélioration [Goldberg et al. 1985] [Bézivin 1989]. La SOO
est marquée par les caractéristiques du langage qui font que le processus de modélisation est
fondamentalement différent du processus de modélisation conventionnel. La première
distinction vient dans la manière dont un modeleur voit et construit le modèle d’un système.
L’objectif des langages étant la simplification de l’étape de programmation, le modeleur est
très souvent contraint à utiliser des primitives ou des fonctions prédéfinies dans la plupart des
langages de simulation.
4.2. La Programmation Orientée Objet (POO)

A l’origine, le modèle objet fut conçu pour traiter des problèmes de simulation qui resteront
un domaine privilégié de la POO. Le mécanisme d’abstraction permet d’exprimer des
modèles de simulation avec plus d’efficacité et de souplesse [Bézivin et al. 1991]. Dès lors,
l’approche la plus naturelle pour simuler des SdPs est celle permettant de décrire directement
leurs composants par des objets possédant des propriétés et sachant réaliser des actions
#"
) % *. ) +
[Carré 1989]. Le concept d’objet est né et prend la forme d’une entité rémanente regroupant
au sein d’une même structure, données, actions et comportement.
Un objet est considéré comme une abstraction d’un élément du monde réel [Rosen 1987] ;
c’est une traduction informatique d’une entité physique ou d’un concept du monde réel
[Bailly et al. 1987]. Dans le cas général, un objet regroupe :
• une partie statique composée d’un ensemble de données, attributs ou champs ; cette partie
représente ce que l’on appelle la structure de l’objet,
• une partie dynamique constituée d’un ensemble de procédures et de fonctions connues
sous le nom de méthodes. Ces méthodes sont les seules à pouvoir manipuler la structure
de l’objet. Cette partie représente le comportement de l’objet.
Les objets sont dérivés à partir de classes qui sont similaires à des gabarits ou patrons non
paramétrés. Un objet est créé quand une version paramétrable d’un patron devient un code.
Les objets sont caractérisés par des paramètres et des fonctions typiquement connues par les
méthodes de l’objet. Les méthodes changent souvent les valeurs associées aux paramètres,
exécutent des algorithmes, des manipulations graphiques et communiquent avec d’autres
objets. Les classes sont organisées selon une hiérarchie qui fournit une souplesse dans la
construction de modèles hiérarchiques. La hiérarchie des sous-classes permet la construction
de sous-assemblages. Les paramètres aussi bien que les comportements des objets peuvent
être construits de manière hiérarchique. Ce concept reflète une approche structurée dans
laquelle les objets à un niveau d’abstraction donné activent des objets situés à un niveau
d’abstraction plus bas. Cette approche descendante permet à l’utilisateur le développement de
modèles hiérarchiques ayant un niveau de détail lié au système réel. De plus, elle permet à des
parties du modèle, d’être simulées dans un but de vérification et de validation. L’orientation
objet est extensible car l’utilisateur peut définir des nouveaux objets ayant des comportements
spéciaux à partir des classes existantes, des objets et des méthodes disponibles.
Les deux principaux mécanismes qui sont à l’origine des avantages de la modélisation
orientée objet sont : le polymorphisme et les liaisons dynamiques. Le polymorphisme est un
concept de « la théorie du type » où un nom (par exemple déclaration d’une variable) peut
indiquer des objets de plusieurs classes différentes. Ainsi, tout objet marqué par ce nom est
capable de répondre à des ensembles d’opérations communes de différentes manières [Booch
1991]. Une liaison dynamique correspond au mécanisme qui crée une référence pour un
comportement polymorphique, elle permet à une entité de se référer aux instances de
différentes classes pendant l’exécution. Ce mécanisme est souvent nécessaire pour la
programmation distribuée, les interfaces utilisateurs et les applications de base de données. Ce
mécanisme permet la création et l’interfaçage de nouveaux objets avec des implémentations
existantes, sans affectation du code existant, qui en retour éliminent les déclarations de choix.
Par conséquent, la complexité de programmation est réduite car des déclarations de choix
imbriquées sont remplacées par un simple appel. Néanmoins, il faut relativiser l’efficacité de
ces mécanismes. En effet, la SOO peut certainement accélérer le développement de modèles
pour des utilisateurs expérimentés ayant à leur disposition des bibliothèques de classes
spécialisées. Cependant, pour les utilisateurs des langages conventionnels, l’effort
d’apprentissage peut être redoutable. Mais, le temps de développement pour des expérimentés
en objet peut être aussi long si les classes d’objets doivent être développées. Cependant,
l’utilité de la SOO croît avec la taille, la complexité et la réutilisation des modèles. Ceci est
aussi vrai pour la maintenance et la modification des programmes. Les modèles de simulation
orientés objet peuvent être exécutés sans pré-traitement et sans compilation, ils peuvent réagir
instantanément à des nouvelles configurations, facilitant ainsi les opérations relatives à leur
%$
) % *. ) +
évolution et modification. En fournissant un moteur de simulation et une bibliothèque

d’objets, les langages spécifiques SOO réduisent de manière appréciable le temps de
développement des modèles [Roberts et al. 1998].
4.3. La Modélisation Orientée Objet avec UML

UML (Unified Modeling Language) a été le langage utilisé pour la modélisation du réseau
STP/CP et de ses objets. C’est un langage de modélisation unifié ou universel. Il représente
une étape majeure dans la conception et la Modélisation Orientée Objet (MOO), dans le sens
où il unifie les différentes approches et en donne une définition plus formelle. Il a été conçu
pour permettre la modélisation de tous les phénomènes de l’activité de l’entreprise,
indépendamment des techniques d’implémentation utilisées par la suite. UML constitue une
bonne synthèse des différentes méthodes existantes dans plusieurs champs de pensée comme
les bases de données, les concepts orientés objets et le génie logiciel. Il offre les avantages
suivants :
• la prise en compte de l’aspect dynamique qui est indispensable en simulation,
• la présence des trois modèles (objet, fonctionnel, dynamique) qui permettent de cerner
toutes les facettes d’un système,
• les représentations graphiques qui simplifient la modélisation.
La modélisation d’un objet au sein d’un système doit être envisagée selon trois axes : la
structure (ce qu’est l’objet), le fonctionnement (ce que peut faire l’objet), l’évolution (ce que
devient l’objet). Le troisième axe traduit les relations entre l’objet et son environnement. Ce
point de vue considère l’objet selon trois facettes : statique, fonctionnelle, environnementale.
La troisième facette représente les réactions de l’objet à son environnement, elle se traduit par
le comportement.
De manière non exhaustive, nous présentons les concepts majeurs d’UML utilisés pour
obtenir le modèle conceptuel du simulateur du réseau STP/CP :
• un diagramme de classes est une collection d’éléments de modèle (statiques), tels que des
classes, des interfaces et leurs relations, connectés entre eux comme un graphe. Un
diagramme de classe montre uniquement les aspects statiques du modèle et fait abstraction
des aspects dynamiques ou temporels, même si les éléments du diagramme de classes
peuvent avoir un comportement dynamique important ;
• un diagramme de collaboration montre une interaction organisée autour des instances et
leurs liens. A l’inverse d’un diagramme de séquence, un diagramme de collaboration
montre les relations parmi les rôles d’objets. En revanche, un diagramme de collaboration
ne montre pas le temps dans une dimension séparée. La séquence des messages doit être
déterminée en utilisant les numéros de séquence ;
• un paquetage est un groupement d’éléments de modélisation. Il peut contenir aussi bien
des paquetages emboîtés que des éléments de modélisation ordinaires. Le système entier
peut être pensé comme un unique paquetage de haut niveau comprenant l’ensemble. Tous
les éléments de modélisation d’UML, y compris les diagrammes, peuvent être organisés
en paquetages. Une classe qui se trouve dans un paquetage appartient à celui-ci et ne peut
être partagée par d’autres paquetages. En revanche, elle peut avoir des relations avec des
classes qui appartiennent à un autre paquetage.
%
) % *. ) +
D’autre part, UML définit plusieurs types de relations entre classes d’objets, dont
l’association, l’agrégation et la généralisation (figure 3.10) :
• une association est un type de relation qui établit une connexion entre plusieurs classes.
Elle porte éventuellement un nom et possède autant de rôles qui spécifient la participation
de chaque classe dans l’association. Le rôle peut avoir un nom et possède plusieurs
attributs orthogonaux. La multiplicité définit le nombre d’instances du rôle qui participent
dans une instance de l’association. UML permet d’exprimer toutes les valeurs de
multiplicité possibles. La multiplicité n’est pas dans l’association, mais sur chaque rôle.
La navigabilité définit si ce rôle est accessible à partir de la source. Pour une instance
d’une association, la navigabilité indique s’il est possible en partant de l’instance de la
classe opposée au rôle de rejoindre l’instance (ou les instances) attachée(s) au rôle
(navigable) ;
• une agrégation est une variante de l’association, ou plus exactement, un attribut sur un
seul des rôles d’une association. Elle introduit la relation de composition ou « partie de ».
Ainsi, un réseau STP/CP possède un ou plusieurs CPs, un ou plusieurs STPs, une ou
plusieurs ECs ;
• une généralisation de classe définit une relation de classification (taxinomie) entre une
classe plus générale et une classe plus spécifique. La classe la plus spécifique est
cohérente avec la classe la plus générale, c’est-à-dire qu’elle contient par héritage tous les
attributs, les membres, les relations de la classe générale, et peut en contenir d’autres. La
relation de généralisation est essentielle pour la « classification ». Cette relation permet de
construire une hiérarchie.
Association Agrégation Généralisation

A est lié à B A est composé de B B est une sorte de A
A B A B A B
Figure 3.10. - Types de relations selon UML.
Afin de faciliter la compréhension du modèle conceptuel global selon UML, nous l’éclatons
en cinq paquetages présentés comme suit.
%#
) % *. ) +
4.4. Les paquetages du modèle UML du réseau STP/CP

Le modèle global du réseau STP/CP est divisé selon les 5 paquetages suivants (figure 3.11) :
• le paquetage STP,
• le paquetage EC,
• le paquetage CP,
• le paquetage simulateur,
• le paquetage réseau STP/CP.
SIMULATEUR
LE_SIMULATEUR
SIMULATION CP
GENERATEUR_ALEAS
GENERATEUR_ENTITE AVERTISSEMENT
LISTE_BLOCAGE LISTE_AVERTISSEMENT_CP
LISTE_EVENEMENT CP
EVENEMENT LISTE_INDUCTEUR
BLOCAGE INDUCTEUR
EVENT_FIN_BLOCAGE_ACTION ACTIONS
EVENT_CREER_PANNE INDICATEUR_PERFORMANCE
EVENT_LANCER_ENTITE INDICATEUR_TEMPS
EVENT_CALENDRIER INDICATEUR_TAUX
EVENT_FIN_OPERATION INDICATEUR_COMPTEUR
EVENT_FIN_CS TYPE_OBJECTIF
EVENT_ACTION OBJECTIF
EVENT_AC_CAPACITE MESURE
EVENT_AC_PANNE
EVENT_AC_REBUTS
EVENT_AC_CS
ENTITE STP
LOT_ENTITE RESEAU STP/CP STP
TYPE_ENTITE CALENDRIERSTP
ENTITE RESEAU_STP_CP LISTEETATSTP
GAMME ETATSTP
ELEMENT_GAMME LISTEINDICATEUR
Figure 3.11. - Paquetages du modèle UML du réseau STP/CP.
Ci-après (figures 3.12 à 3.16), nous fournirons les diagrammes de classes des différents
paquetages (CP, STP, EC, Simulateur et Réseau). Toutefois, nous ne reprendrons pas le détail
des attributs et des fonctions des principales classes d’objets. Aussi, à titre d’exemple nous
présentons le diagramme de séquence de l’événement fin opération qui récapitule les
différents échanges de message avec les objets du réseau STP/CP.
Cependant, nous analysons le modèle UML représentant la simulation du réseau STP/CP, en

décrivant la collaboration existant entre les objets, ainsi que les caractéristiques des liens
reliant ces objets (relations d’association, d’agrégation et de généralisation). Puis nous
présenterons les liens entre ces 5 paquetages, lors de la présentation du modèle entier, pour
une vue d’ensemble du simulateur du réseau STP/CP.
%%
) % *. ) +
De CP
+mSTPsource
1 1 1
Vers CP
De STP
RESEAU_STP_CP identif icateur : String
capacite : int
+mSTPreseau charge : int
0..* nb_rebuts : int
nb_entites : int
nb_panne : int
reception : boolean 0..1 +iSTP
transf ormation : boolean
f ourniture : boolean
+mSTPcausal
capacitemax : int
+mSTPencoursf ab De INDUCTEUR
tempsDernierEv ent : f loat = 0 1
0..1 tempsCS : f loat
De
ENTITE identif icateur()
+iSTPmesure
identif icateur()
1
ajouter()
+mSTPaf f ecte
supprimer()
1
sommeduree()
modif ier()
+iSTP
1
1
+mListeEtatSTP
De
LISTE_ETAT_STP
ELEMENT_GAMME +mListeIndic
cET_PANNE : int = 0 LISTE_INDICATEURS
cET_CS : int = 1 1 cID_TX : int = 0
+mCalendrier 0..*
cID_COMPTEUR : int = 1
CALENDRIER_STP ajouter() cID_TEMPS : int = 2
duree : f loat v iderListe()
capacite : int calcul_duree() ajouter()
indexEnCours : int estEnPanne() supprimer()
estEnCS() supprimer()
nb_etat() supprimer()
nb_CS()
nb_panne() +iListeIndic
calcul_duree()
+mEtatSTP 1..* Vers 1..*

ETAT_STP INDICATEUR_
Vers ENTITE ty pe : int PERFOMANCE
tps_debut : f loat
tps_f in : f loat
Figure 3.12. - Diagramme de classes du paquetage STP.
%
) % *. ) +
De GENERATEUR_ENTITE De RESEAU_STP_CP De EVENEMENT
+mLotEntite 1
0..*
+iReseauSTPCP
LOT_ENTITE
taille : int +iLot
periode : f loat
identif icateur : String 1..*
+iLotEntite1
+mEntitecourant
+mEntite 1
1..* Vers STP
ENTITE
rebutee : boolean = f alse
+iEntiteSTP
terminee : boolean = f alse
num_serie : int 0..*
+mTy peEntiteLot
+mTy peEntiteReseau
estRebutee() 1..* 1..* 1
calcul_tps_operatoire() +iEntite +mTy peEntite TYPE_ENTITE
stp()
1 nom_entite : String
stpcourant()
0..*
+entite +iTy peEntite STP() Vers STP

1 0..* 0..1
GAMME
+mTy peEntite +mTy peEntite
duree_gamme : f loat
nb_element : int +mGamme
ajouter_element_gamme() 1
supprimer_element_gamme()
element()
calcul_STPsuiv ant()
calcul_STPprecedent()
premier_STP()
dernier_STP()
stp()
isSTP()
+iGamme1
{ordered}
+mElementGamme De
0..* ETAT_STP
ELEMENT_GAMME
identif icateur : String
+iObjectif
num_sequence : int
De OBJECTIF
tps_operatoire : f loat
1
stp()
stp()
De INDICATEUR_PERFORMANCE
Figure 3.13. - Diagramme de classes du paquetage EC.
%
) % *. ) +
AVERTISSEMENT
LISTE_AVERTISSEMENT_CP identif icateur : String
nb_av ertissement : int = 0 ty pe : int
+mListeAv ertissementSTP +mAv ertissement tps_av ertissement : f loat
ajouter() niv eau_hierarchique : int
De SIMULATION 1..* supprimer() 0..* message : String
ajouter() v aleur : f loat
destroy Doublon()
INDUCTEUR LISTE_INDUCTEURS
objectif : String ajouter()
ty pe_inducteur : int supprimer()
+mInducteur
seuil_limite_inducteur_sup : f loat
deriv e_sup : boolean +mListeInducteur
1..*
cIN_TR_NB_PANNE : int = 7 2
Vers STP cIN_TR_NB_REBUT : int = 8
cIN_TR_CAPACITE : int = 6
cIN_TR_TPS_SERIE : int = 9
seuil_limite_inducteur_inf : f loat +mCPcible
+mCPsource
deriv e_inf : boolean
1
De 1
ev aluer_perf ormance()
RESEAU_STP_CP v erif _indicateur() CP
ty pe_seuil : int
+iAction +mAction 1..* ty pe_ev aluation : int
De EVENT_ACTIONS deriv e_sup : boolean
Vers STP cCP_TR_SEUIL_LIMITE : int = 0 +iCPCP
ACTIONS
1..* cCP_TR_SEUIL_ALERTE : int = 1
identif icateur : String +mCP 0..1
cCP_EV_PERF_SUP : int = 0
1 ty pe : int
De cCP_EV_PERF_INF : int = 1
+mActions v ariable_action : f loat +mCP cCP_EV_PERF : int = 2
BLOCAGE tps_reaction : f loat
1 deriv e_inf : boolean +mCPCP
tps_mise_en_place : f loat LISTE_INDICATEURS
cID_TX : int = 0 0..*
identif icateur()
modif ier() cID_COMPTEUR : int = 1
ev aluer_perf ormance()
cID_TEMPS : int = 2
+mListeIndic traitement_deriv e()
lierCP()
De STP 1 ajouter()
modif ier()
supprimer()
calculCPPrecSuiv ()
supprimer()
supprimer()
+iListeIndic
TYPE_OBJECTIF
identif icateur : String +mIndicateurSecondaire
+mTy peObjectif
expression : String 0..1
1 +mIndicPerf
ajouter() 1..*
+iTy peObjectif INDICATEUR_PERFORMANCE
supprimer() 1 identificateur : String
INDICATEUR_TEMPS
type_general : int
+mIndicateurPrincipal
type_specifique : int cID_TPS_MOY _CS : int = 0
performance_seuil_sup : float cID_TPS_RALENTISSEMENT : int = 1
1
1 performance_seuil_inf : float cID_TPS_REEL : int = 2
cID_TPS_NON_QUAL : int = 3
mesurer() cID_TPS_UTIL : int = 4
Vers calculer_performance() cID_TPS_CYCLE_SYST_ENT : int = 5
calculer_performance() cID_TPS_CYCLE_MOY_SYST_ENT : int = 6
TYPE_ENTITE 1..*
+mObjectif calculer_performance()
ajouter() calculer()
supprimer()
OBJECTIF
+iObjectif seuil_limite_inf : f loat
Vers seuil_limite_sup : f loat
TYPE_ENTITE 1 seuil_alerte_inf : f loat
seuil_alerte_sup : f loat
INDICATEUR_COMPTEUR INDICATEUR_TAUX
cID_NB_ENTITE_BONNE : int = 0 cID_TX_BRUT_FONC : int = 0
cID_NB_ENTITE_REBUTEE : int = 1 cID_TX_PANNE : int = 1
+mMesure cID_NB_ENTITE_TOTAL : int = 2 cID_TX_CS : int = 2
cID_NB_ENTITE_PAR_TYPE : int = 3 cID_TX_QUALITE : int = 3
Vers 0..* cID_NB_CS : int = 4 cID_TX_NON_QUALITE : int = 4
MESURE
TYPE_ENTITE cID_NB_PANNE : int = 5 cID_TX_OUVERTURE : int = 5
mesure : f loat
cID_TRS : int = 6
tps : f loat
calculer()
calculer() calculer()
Figure 3.14. - Diagramme de classes du paquetage CP
%
) % *. ) +
EVENT_CREER_PANNE
EVENT_CALENDRIER
ATION+iSimulation +mListeEvenement LISTE_EVENEMENT
1
1 +mListeBlocage EVENT_LANCER_ENTITE
ation 1
+iListe_Evenement
LISTE_BLOCAGE
EVENT_FIN_OPERATION
0..*
+mEvenement
+mBlocage EVENEMENT
EVENT_FIN_CS
0..*
1
BLOCAGE +iEvenement
AU_STP_CP 1
EVENT_ACTIONS
+mEvAction
1
1
1
1+iSTPreseau EVENT_AC_CS
1
EVENT_AC_CAPACITE
EVENT_AC_REBUTS
+iReseauSTPCP
EVENT_AC_PANNE
+mSTPcourant
Figure 3.15. - Diagramme de classes du paquetage simulateur.
%&
) % *. ) +
De SIMULATION
+mReseauSTPCP
1
RESEAU_STP_CP
cTY PE_ENTITE : int = 0
cSTP : int = 1
cCP : int = 2
ajouter()
ajouter()
supprimer()
estSTPValide() Vers
stp() LISTE_AVERTISSEMENT
ajouter() +iReseauSTPCP
supprimer()
supprimer() Vers CP
nb_STP() +iSTPreseau
nb_CP() 1
nb_Ty peEntite()
ajouter()
cp() Vers STP
ty peEntite()
+iReseauSTPCP
Vers TYPE_ENTITE
Figure 3.16. - Diagramme de classes du paquetage réseau.
%!
) % *. ) +
Liste des ev enement : Fin Opération : STP source : STP Entite Courante : STP courant : STP STP cible : STP Liste blocage : Générateur Aléas :
LISTE_EVENEMENT EVENT_FIN_OPERATION ENTITE LISTE_BLOCAGE GENERATEUR_ALEAS
1: Trier les evennement
2: executer( ) 3: Fournir ?
4: Pas de fourniture
5: ajouter()
6: Fourniture OK
7: Rebut sur STP courant ?

8: rebutée
9: estRebutee( )
10: décrémenter la charge
11: Blocage sur STP source ?
12: blocage sur STP source

13: Fournir ?
14: Fourniture OK
15: Ajouter un evenement FIN_OP
16: supprimer blocage sur STP source
17: supprimer Fin Opération
18: non rebutée
19: Recevoir ?
20: Reception OK
21: Blocage sur STP source ?

22: Blocage sur STP source
23: Fournir ?
24: Fournir OK
26: supprimer blocage sur STP source
28: Décrémenter charge
29: Enlever lien Entite courante
30: Incrémenter charge
31: Ajouter lien Entite courante


34: Pas de reception
35: Ajouter un blocage sur STP courant et Entité Courante
Figure 3.17. - Diagramme de séquence de l’événement fin opération.
%"
) % *. ) +
4.5. Les relations entre paquetages du modèle

Nous avons présenté à titre d’exemples dans les pages précédentes, les diagrammes de classes
des paquetages du modèle. Dans cette partie, nous explicitons les relations existant entre ces
paquetages (figure 3.18).
SIMULATEUR CP
LE_SIMULATEUR AVERTISSEMENT
SIMULATION LISTE_AVERTISSEMENT_CP
GENERATEUR_ALEAS CP
GENERATEUR_ENTITE LISTE_INDUCTEUR
LISTE_BLOCAGE INDUCTEUR
LISTE_EVENEMENT ACTIONS
EVENEMENT INDICATEUR_PERFORMANCE
BLOCAGE INDICATEUR_TEMPS
EVENT_FIN_BLOCAGE_ACTION INDICATEUR_TAUX
EVENT_CREER_PANNE INDICATEUR_COMPTEUR
EVENT_LANCER_ENTITE TYPE_OBJECTIF
EVENT_CALENDRIER OBJECTIF
EVENT_FIN_OPERATION MESURE
EVENT_FIN_CS
EVENT_ACTION
EVENT_AC_CAPACITE
EVENT_AC_PANNE RESEAU STP/CP
EVENT_AC_REBUTS
EVENT_AC_CS RESEAU_STP_CP
ENTITE STP
LOT_ENTITE STP
TYPE_ENTITE CALENDRIERSTP
ENTITE LISTEETATSTP
GAMME ETATSTP
ELEMENT_GAMME LISTEINDICATEUR
Figure 3.18. - Relations entre paquetages du modèle
• Relations entre STP et Entité

La classe d’objet Entité est liée à la classe d’objet STP, permettant ainsi d’avoir la liste des
entités sur un STP à un instant donné.
La classe d’objet Element_Gamme est identifiée par un STP. Chaque élément de la gamme
est représenté par un STP existant du Réseau STP/CP.
• Relations entre STP et CP

La classe d’objet CP est liée à un ou plusieurs STPs. Un CP pilote un ou plusieurs STPs.
La classe d’objet Inducteur est liée à un STP. Les inducteurs, causes de dérive, sont liés aux
paramètres des STPs.
La classe d’objet STP est liée à un ou plusieurs Indicateurs_Performance. Ce lien permet
d’obtenir la mesure d’un paramètre du STP, pour qu’ensuite, le CP puisse calculer la
performance du système piloté.
$
) % *. ) +
• Relations entre STP et Simulateur

La classe d’objet Generateur_aleas génère des aléas sur des STPs. Les changements de série
et pannes sont créés selon des lois aléatoires données par le générateur d’aléas sur un ou
plusieurs STPs.
La classe d’objet Evenement est caractérisée par trois STPs. Les quatre types d’événements
ont pour paramètres un STP source, un STP courant et un STP cible.
La classe d’objet Blocage est liée à un STP. Un blocage est défini comme : une entité bloquée
à un instant donné, sur un STP donné.
• Relations entre Entité et Simulateur

La classe d’objet Generateur_aleas génère des aléas sur Entité. Les rebuts sont créés selon
des lois aléatoires données, par le générateur d’aléas sur un ou plusieurs types d’entités.
La classe d’objet Simulation est liée à un Generateur_Entite. Ce lien permet de créer les
entités à fabriquer, pour la simulation.
La classe d’objet Blocage est liée à une Entite. Un blocage est défini comme : une entité
bloquée à un instant donné, sur un STP donné.
• Relations entre Simulateur et Reseau STP/CP

La classe d’objet Simulation est liée à un Reseau STP/CP. Ce lien permet ainsi de lier les
différentes classes d’objets (STP, EC et CP) à la simulation.
5. CONCLUSION
Nous avons présenté dans ce chapitre le réseau STP/CP qui est une association entre les STPs
et les ECs modélisant le processus de fabrication et les CPs permettant de modéliser le
processus de pilotage des STPs et des CPs de niveau inférieur. L’objectif de ce chapitre était
de formaliser les différents concepts et de les positionner dans le réseau STP/CP, en vue de sa
modélisation pour la simulation. Ainsi, après avoir défini formellement les STPs et les ECs,
nous nous sommes attardés sur la classe d’objet du CP. Son analyse comportementale a
permis de formaliser le processus de pilotage interne du CP, facilitant ainsi sa représentation
dans un langage de formalisation en vue d’une implémentation.
Le réseau STP/CP n’est pas une structure figée. Chacune des classes d’objets le composant,
constitue une ossature générique permettant de modéliser le système de fabrication et son
système de pilotage. Cet outil de modélisation générique peut ainsi proposer des modèles
selon différents niveaux hiérarchiques et selon différents niveaux d’abstraction. Le STP,
l’entité et le CP étant des classes d’objets « squelettes », peuvent être enrichies selon les
spécificités demandées et le niveau de détail souhaité. Ces niveaux dépendront des objectifs
escomptés par l’utilisateur. Ils permettront d’obtenir rapidement des modèles représentatifs de
la réalité, en s’adaptant à des objectifs industriels concrets.
) % *. ) +
#
! $(
Après avoir synthétisé notre activité globale d’enseignant chercheur dans la première partie de
ce mémoire (curriculum vitæ et synthèse d’activités), et détaillé nos travaux de recherche
scientifique dans la deuxième partie (chapitres 1 à 3), nous abordons dans ce chapitre les
conclusions et les perspectives de nos recherches.
D’abord, nous situerons, dans une première partie, le cadre dans lequel cette recherche a été
réalisée ainsi que les personnes ayant été encadrées et participées à ce travail. Aussi, nous
mettrons en relief les principaux points forts développés. Ensuite, dans une seconde partie,
nous ferons une proposition des perspectives que nous estimons importantes à aborder dans
nos travaux futurs.
1. CONCLUSIONS SUR NOS RECHERCHES
Les différents acteurs de la productique, qu’ils soient académiciens ou industriels, n’ignorent

pas que les systèmes de production appartiennent à une famille de structures complexes dont
la conception, l’organisation, la gestion, le pilotage… nécessitent le recours à des techniques
d’aide à la décision. Parmi ces techniques, la simulation informatique est, sans aucun doute,
une des techniques les plus efficaces et les plus utilisées actuellement. Cependant, nombreux
sont les acteurs potentiellement utilisateurs mais qui hésitent encore à y recourir pour des
raisons liées à la complexité de construction et d’exploitation des modèles de simulation.
Par conséquent, dans le cadre de nos recherches aussi bien personnelles que collectives
(thèses de M. Bakalem et de C. Berchet, DEA de C. Labrune, P. Carbone, P. Sénéclauze, C.
Berchet, J.N. Charpin), nous avons cherché à analyser la problématique de la simulation des
) * + )
systèmes de production, à identifier les principales difficultés, et à proposer des solutions à

travers des concepts et une approche de modélisation permettant de surmonter certains de ces
problèmes et ainsi mieux exploiter un potentiel encore très large de cette technique. En effet,
nous estimons qu’à terme, une vision « intelligente et active » de la simulation devra
permettre aux différents utilisateurs, d’obtenir une aide décisionnelle plus fiable à l’aide d’une
modélisation plus représentative de la réalité.
Le point déclencheur de ces travaux est sans doute dû à une passion pour la recherche, mais
aussi à une volonté personnelle d’engagement dans différentes études industrielles
(STAUBLI, SOMFY, SALOMON, TEFAL, DAV…) concernant des aspects différents du
système de production (évaluation de performances, aide à la conception, validation d’un
mode de gestion, aide au pilotage, comparaison d’alternatives…).
L’utilisation de certains outils généraux de simulation (SIMAN, ARENA, EXTEND…) pour

mettre en œuvre ces études pratiques ainsi qu’une littérature abondante dans ce domaine, nous
ont permis de mettre en évidence certains problèmes limitant l’utilisation de la simulation en
entreprise. Une analyse plus fine de ces problèmes, a fait émerger deux principaux types :
ceux qui concernent le processus de simulation et particulièrement l’approche de modélisation
et ceux relatifs au support de l’outil informatique. Toutefois, il est évident que certains des
problèmes liés au support informatique sont conséquents de l’approche de modélisation
adoptée. Afin de pallier ces problèmes, leur analyse nous a permis de déduire un ensemble de
propriétés que doit satisfaire un bon simulateur. Nous nous sommes particulièrement
intéressés aux propriétés qui concernent l’approche de modélisation. Parmi celles-ci, la
propriété de réutilisation des modèles et des concepts, la propriété d’affinement des modèles
existants et la propriété de cohérence du formalisme dans la modélisation des processus de
fabrication et de pilotage, ont fait l’objet d’une attention particulière de notre part.
Ainsi, l’objectif de nos travaux, est de proposer une approche de modélisation et un modèle,
qui permettent de représenter aussi bien le processus de fabrication que le processus de
pilotage, et qui correspondent à la perception qu’un utilisateur potentiel peut avoir d’un
processus de simulation. Dans ce sens, nous avons procédé à l’analyse du système de
production dans une optique de simulation. Nous avons ainsi dégagé un certain nombre de
notions qui ont été à la base de notre approche de modélisation.
1.1. Conceptualisation du processus de fabrication

Dans un premier temps (travaux de thèse de M. Bakalem) et concernant principalement le
processus de fabrication, nous avons introduit les notions de :
• structure récursive et hiérarchique traduisant un modèle de représentation de la

structure du système de fabrication (ressource, station, îlot…),
• ressource selon une optique de simulation, traduisant des aspects, structurel, fonctionnel
et comportemental standards de toutes les ressources composant un système de
fabrication,
• graphe d’état générique représentant le comportement standard d’une ressource de
fabrication selon plusieurs niveaux d’abstraction ou de détail,
• système de production à comportement parfait traduisant un processus de production
sans contrainte et sans perturbation. Cette notion permettra de définir par la suite, un
processus de pilotage basé sur les indicateurs de performance et à intégrer dans un
) * + )
modèle de simulation. Pour nous, le système de pilotage est perçu comme un système de
prévention et de correction des dérives et des perturbations du comportement parfait du
système de fabrication.
Cette analyse du système de production a montré, dans une optique de simulation, que toutes
les ressources d’un processus de fabrication présentent une structure identique et un
comportement standard. Ce constat a permis de proposer deux structures de base permettant
de construire un modèle représentant le système de fabrication. Il s’agit du Système de
Transformation du Produit (le STP) et de l’Entité Circulante (l’EC). L’association de ces
deux structures va nous permettre de modéliser le processus de fabrication d’un système de
production. Le STP est la structure générique permettant de représenter tout type de
ressource, à tous les niveaux hiérarchiques et à tous les niveaux d’abstraction. L’Entité
Circulante est la structure générique permettant de modéliser le flux de production, à tous les
niveaux à travers les STPs.
1.2. Conceptualisation du processus de pilotage

Dans un second temps (travaux de thèse de C. Berchet), nous avons cherché à modéliser
l’ensemble du processus de production, c’est à dire à la fois, le processus de fabrication et le
processus de pilotage. La réalité des systèmes de production (perturbés, aléatoires,
dégradables…) va être ainsi étendue à la notion de système de fabrication « parfait »
considérée auparavant. Dans ce sens, le type et la structure dans laquelle doit évoluer le
processus de pilotage, ont été définis : un pilotage de type interprété laissant ainsi à tout
acteur décideur du système de production, une interprétation propre et un pouvoir d’action
mais dans une stratégie globale, et une structure de pilotage coordonnée hiérarchisée afin
d’évoluer dans une organisation hiérarchique tout en gagnant en réactivité et en coopération
dès le niveau opérationnel. Ainsi, nous avons introduit les notions de :
• structure globale permettant de situer les unités de pilotage dans un cadre

tridimensionnel où ; la dimension hiérarchique représente le support des liens de
coordination, la dimension spatiale représente le support des relations de coopération et la
dimension temporelle représente le support de l’évolution dynamique des unités de
pilotage,
• structure locale situant l’évolution de l’unité de pilotage dans un contexte de réactivité.
Cette réactivité est caractérisée par une typologie à trois types de pilotage ; le pilotage « a
priori », le pilotage « réactif pour anticipation » et le pilotage « a posteriori ». Le premier
type concerne des tâches de pilotage planifiées, le deuxième type concerne les tâches de
prévention anticipées et le troisième type concerne les tâches de correction subies.
Le concept de base qui représente l’unité de pilotage et qui évolue dans ces structures est le
Centre de Pilotage (le CP). Le CP est le processeur générique qui va nous permettre de
modéliser le processus de pilotage dans un processus de production. Les deux principales
composantes incontournables pour le pilotage à l’aide du CP sont, d’une part, les indicateurs
de performance (indicateurs de processus pour un pilotage de prévention et indicateurs de
résultat pour un pilotage de correction) et d’autre part, les informations et les relations
d’échange (relations de coopération et relations de coordination) circulant entre CPs, et entre
CPs et STPs.
) * + )
Le Centre de Pilotage a été défini par :
« une structure organisée et autonome, mais dépendante de la stratégie de l’entreprise, ayant

un pouvoir décisionnel, associée à une entité à piloter et disposant d’un ensemble de
ressources nécessaires à la mise en place d’actions pour atteindre un ou plusieurs objectifs
définis dans le cadre global de l’entreprise ».
1.3. Modélisation orientée objet du processus de production

Les trois concepts de base (STP, EC, CP) ont été formalisés afin de construire le réseau
STP/CP. Ainsi, après avoir défini formellement le STP et l’EC, structures permettant de
modéliser le processus de fabrication, l’analyse comportementale du CP a été effectuée, en
dissociant son processus de pilotage en deux étapes principales et un processus de décision :
• mesure,
• processus de décision (évaluation et décision),
• action.
L’ensemble du processus de pilotage comprend trois types d’évaluation :
• évaluation de la performance à l’aide d’indicateurs principaux,

• évaluation de l’inducteur à l’aide d’indicateurs secondaires,
• évaluation du plan d’action à l’aide de simulations internes.
Sur la base de cette formalisation du réseau STP/CP et ses composants, un modèle de

simulation orienté objet a été développé. Il s’agit du modèle Apollo. Pour la modélisation,
nous avons opté pour la technique objet. En effet, ses caractéristiques conjuguées avec celles
du STP, de l’EC et du CP nous permettent de maintenir, voire de renforcer, les propriétés
recherchées. Vu son caractère unifié et universel, le langage UML a été adopté pour l’analyse
et la construction de ce modèle en cinq paquetages de classes d’objets (STP, EC, CP, réseau
STP/CP, Simulateur). Le modèle constitue ainsi, une architecture générique qui doit permettre
de modéliser un processus de production (processus de fabrication et processus de pilotage).
Cette architecture est paramétrable en fonction des caractéristiques propres du système à
modéliser, du niveau de détail souhaité et des objectifs finaux de l’utilisateur. A terme, un
raffinement du prototype permettra également de rendre les possibilités de modélisation plus
complexes et variées.
Pour l’implémentation du modèle, nous utilisons le langage de programmation JAVA. Ce

langage orienté objet offre l’environnement de base, nécessaire et adéquat au développement
de modèles de simulation. L’implémentation du modèle Apollo est basée sur un cycle de vie
en spirale. De ce fait, actuellement une partie de chacun des paquetages de classes d’objets est
implémentée. La programmation se fait par évolution progressive et simultanée de l’ensemble
des paquetages. Le modèle fonctionne dans le cas d’un système de production « parfait » ou
soumis à des contraintes de capacité sans stocks intermédiaires. C’est à dire, des situations de
blocage sur certaines ressources peuvent être générées si des ressources « goulets » sont
prévues dans le processus. Plusieurs personnes ont déjà travaillé sur l’implémentation du
modèle. Actuellement, J.N. Charpin dans le cadre de son DEA en informatique, est entrain de
) * + )
vérifier la cohérence du modèle UML et d’implémenter le paquetage correspondant aux

classes d’objets du CP.
La faisabilité du modèle Apollo a été vérifiée lors d’une application industrielle à ALCATEL,
dans le cadre de thèse de Claire Berchet en contrat CIFRE. Dans cette application, le caractère
pédagogique de l’approche a été mis en avant, puisqu’il permet à l’utilisateur de mener une
réflexion sur les facteurs influant le processus de pilotage. Il sensibilise l’acteur à l’impact des
décisions prises et des actions mises en place et favorise ainsi la prévention à court terme.
Dans l’élaboration de cette approche de modélisation, nous avons tenu à ce que les principales
propriétés soient vérifiées, en effet :
• la réutilisabilité est assurée par l’aspect générique du STP, de l’EC et du CP,

• l’affinement est rendu possible grâce au graphe d’état générique et à la structure
hiérarchique qui permettent de considérer plusieurs niveaux de détail,
• la cohérence du formalisme de modélisation entre le système de fabrication et le système
de pilotage, est vérifiée grâce au STP, au CP, à la notion de système parfait et au graphe
d’état,
• enfin, la modularité est assurée principalement par les structures standards de l’EC, du
STP et du CP, permettant la construction séparément puis le regroupement de différentes
parties d’un modèle situées au même niveau d’abstraction.
2. PERSPECTIVES DE NOS RECHERCHES
Dans la première partie de ce chapitre, nous avons présenté les principales conclusions sur
nos travaux de recherche concernant la modélisation et la simulation des systèmes de
production (chapitres 1, 2 et 3). Dans cette seconde partie, nous exposons les perspectives des
travaux que nous envisageons de traiter, à court et moyen terme et celles qui pourraient être
approchées à long terme. Toutefois, avant d’aborder ces perspectives, rappelons les problèmes
soulevés par notre analyse du système de production selon un point de vue de la simulation et
les solutions apportées par notre approche de conceptualisation et de modélisation, ainsi, que
les nouveaux problèmes découlant de l’approche adoptée ou de nouveaux besoins.
Nous avons vu, que les problèmes à résoudre pour améliorer les potentialités de la simulation
des systèmes de production portent sur :
• l’approche de modélisation adoptée,

• l’environnement de simulation qui supporte l’approche de modélisation.
En effet, d’autre part, les principaux points développés et qui distinguent nos recherches des
autres travaux concernent l’approche de modélisation centrée volontairement sur l’utilisateur
potentiel. Cette approche, à travers ses concepts naturels, génériques et limités en nombre
(STP, CP, EC) a permis d’apporter des solutions concernant :
• les problèmes de réutilisabilité, d’affinement, de cohérence du formalisme et de

modularité,
• la modélisation d’un processus de pilotage réactif (préventif et correctif), orienté objectif
et basé sur la notion d’indicateur de performance de processus et de résultat (cette
&
) * + )
approche de modélisation du processus de pilotage dans un modèle de simulation peut être

considérée comme innovante dans ce domaine),
• la séparation, dans un même modèle, entre deux processus (processus de fabrication et
processus de pilotage) souvent imbriqués et modélisés par les mêmes primitives qui se
limitent (si elles existent !) à des fonctions élémentaires de choix, de sélection, de
déviation, de groupement,…
• la modélisation de processus de fabrication sans stocks d’encours est possible grâce au
concept STP qui a une logique comportementale permettant de gérer un flux de produits
(vers l’aval) et un flux d’information (vers l’aval et vers l’amont) ; en effet, la plupart des
approches de modélisation sont basées sur la méthode des files d’attente qui nécessite par
définition l’enchainement de files et de serveurs dans le modèle.
D’autre part, les autres points abordés dans nos recherches concernent l’utilisation et l’analyse
du système de production selon les concepts développés dès la première étape du processus de
simulation. Ils permettent de :
• développer des modèles statique et dynamique cohérents (une méthodologie d’utilisation

du CP a été développée dans la thèse de Claire Berchet),
• construire des modèles sans programmation (en effet, le modèle de simulation développé
avec les concepts proposés, est généré automatiquement à partir de la description des
Entités Circulantes à travers leurs gammes de fabrication).
Cependant, si nos travaux de recherche ont apporté des solutions à certains problèmes,
d’autres n’ont pas encore été résolus ou abordés. Aussi, l’avancement de ces travaux fait
apparaître naturellement de nouveaux besoins. L’analyse de ces besoins fait ressortir trois
types de travaux :
• d’abord, les travaux qui concernent directement le modèle Apollo et son évolution par
des actions à court ou moyen terme,
• ensuite, les travaux qui concernent la génération automatisée de processus de
simulation qui peut être envisagée à long terme,
• enfin, les travaux également à long terme et qui concernent l’aspect intelligent du CP et
sa modélisation à l’aide d’une approche multi-agents.
2.1. Evolution du modèle Apollo

En ce qui concerne le modèle Apollo, certains travaux se poursuivent naturellement pour
avancer l’implémentation, d’autres travaux sont nécessaires à court terme et certains peuvent
être envisagés à moyen terme… en effet.
• Le modèle est actuellement dans une phase de finalisation, par la création des interfaces
graphiques et la présentation de l’animation visuelle en cours de simulation, des tests à
échelle industrielle sont prévus dans l’entreprise ALCATEL.
• Une réflexion est nécessaire pour déterminer quelle part de prise de décision doit être
laissée à l’outil de simulation et quelle part doit être laissée à l’opérateur humain. Dans ce
sens, des travaux sont à réaliser pour améliorer la partie du modèle concernant le
processus de pilotage.
!
) * + )
• Les applications actuelles du modèle sont prévues au niveau opérationnel. Mais, de part
la généricité des concepts du modèle, nous envisageons à moyen terme, des applications à
un degré de granularité plus élevé (par exemple au niveau station, niveau atelier…). Des
applications étendues à d’autres services de l’entreprise pourraient être aussi envisagées.
• Sachant que l’indicateur de performance, est un élément essentiel dans le processus de
pilotage du CP, des travaux sur l’agrégation de l’indicateur sont nécessaires pour un
pilotage aux niveaux supérieurs de la structure globale (démarche ascendante). Si cette
agrégation est abordée, le processus de pilotage nécessite également des travaux sur la
décomposition des objectifs (démarche descendante).
• A terme, le modèle Apollo doit devenir une aide au pilotage en temps réel dans un atelier
de production. Ceci nécessiterait la création de bases de données mais, surtout
d’interfaces permettant de faire le lien entre des systèmes de GPAO ou de ERP et le
modèle de simulation.
• La phase d’évaluation de l’action nécessite d’être approfondie. En effet, la simulation
interne peut être une phase délicate à implémenter. Le temps de réponse informatique de
l’évaluation de l’action reste encore à déterminer. Ce temps doit être le plus faible
possible pour un pilotage que nous voulons réactif. Il est souhaitable de faire une
recherche simultanée sur d’autres approches permettant d’avoir des solutions
équivalentes.
• L’élaboration d’une bibliothèque d’objets dédiés à la simulation des systèmes de
production et conçus selon l’approche de modélisation par STP/CP semble être une étape
future naturelle de ce travail.
• Le recensement des états d’une ressource et des niveaux d’abstraction les plus
fréquents suivant une approche pragmatique, permettrait de définir des états et des
niveaux d’abstraction standards dans un processus de simulation.
2.2. Génération automatisée de processus de simulation
2.2.1. Contexte de la recherche
A la faveur d’une étude bibliographique conséquente et d’une expérience de plusieurs années

de notre équipe au sein du LLP/CESALP, en simulation des systèmes de production, nous
constatons que des travaux de recherche importants peuvent être menés aussi bien à moyen
terme qu’à long terme, sur l’ensemble du processus de simulation. Ces travaux concernent à
la fois le processus de simulation lui-même ainsi que certaines de ses étapes.
D’abord, comme nous l’avons souligné dans le premier chapitre (§ 4.2 ), il existe divers
points de vue concernant le processus de simulation. Le processus simplifié de la figure 1.1 et
le processus défini par Pritsker et présenté à la figure 1.2 (chapitre 1) sont deux exemples de
points de vue différents. Aussi, le processus publié par le Cetim [Cetim 1991] (figure 4.1.a)
ainsi que celui proposé par Hoover et al. [Hoover et al. 1989] (figure 4.1.b) sont deux autres
exemples de processus de simulation séquentiels et itératifs comprenant plusieurs boucles de
retour. Même si quelques-unes des étapes sont communes à certains points de vue de
processus, nous remarquons que certains sont fondamentalement différents.
"
) * + )
Définition du système
et des objectifs
Qualification
du modèle Formulation
Définition du
problème
Modèle conceptuel
Collecte et analyse
Vérification des données
Représentation
préparer, valider
Validation
les données
Construction du
Identifier,
Valider le
modèle
Modèle modèle
communicatif
Redéfinition
Validation du
Vérification modèle
Programmation
Validation
Expérimentation
Modèle et optimisation
programmé
Implémentation
Vérification Conception des résultats
Validation scénarios
Modèles (b)
expérimentaux
Simulations
Présentation des résultats
Résultats
Vérification de la présentation
(a)
Figure 4.1. - Étapes d’un processus de simulation.

(a) d’après [Cetim 1991]
(b) d’après [Hoover et al. 1989]
Ensuite, un second point non moins important que le premier mais qui n’apparaît pas
forcément de manière explicite dans le processus, concerne la réalisation même des
différentes étapes. Il s’agit ici de plusieurs aspects comprenant les méthodologies, les
démarches, les méthodes, les outils… à utiliser pour assurer la cohérence du processus de
simulation en tant que projet à part entière.
2.2.2. Définition de la problématique
Si dans le cadre de nos recherches, des travaux ont été réalisés pour améliorer l’étape de
modélisation et simplifier la phase de programmation, d’autres travaux peuvent être envisagés
pour aborder les autres étapes du processus. En effet, les problèmes que tout utilisateur de
simulation peut rencontrer dans un projet de simulation sont de deux natures différentes.
D’abord, il y a les problèmes qui sont directement liés au processus de simulation lui-même,
c’est à dire :
$
) * + )
• le problème posé par le choix d’un processus parmi un certain nombre de points de vue
différents et les difficultés qui en découlent pour un utilisateur non expérimenté,
• le déroulement des étapes du processus qui est par nature itératif nécessitant une grande
expérience et une intuition personnelle,
• la négligence de certaines étapes du processus par ignorance du domaine et en pensant
qu’un processus de simulation équivaut à une phase de programmation informatique…
Ensuite, il y a les problèmes qui concernent directement la réalisation même des différentes
étapes du processus de simulation, c’est à dire :
• le manque de relations formalisées permettant de faire le lien de manière explicite entre

les étapes du processus et de tenir compte des objectifs définis dans les étapes
précédentes…
• le manque de méthodologie et de méthode permettant de guider l’utilisateur dans la
réalisation des différentes étapes du processus (méthodes d’analyse et de formulation du
problème de manière cohérente avec les concepts de l’outil utilisé, méthodes de collecte et
d’analyse des données à introduire dans un modèle de simulation en cohérence avec les
objectifs de simulation, méthodes de structuration des expériences et d’analyse des
résultats de simulation…).
Si l’intégration du processus de pilotage à l’aide du concept de CP peut réduire le nombre

d’expériences par l’action sur certains paramètres du système suite à l’évaluation de sa
performance, il est nécessaire pour d’autres modèles, d’intégrer des outils tels que les plans
d’expériences pour la structuration des essais et l’analyse de la variance pour la détermination
des interactions éventuelles entre certains facteurs.
Vu ces problèmes, nous pouvons nous poser les questions suivantes :
• faut-il normaliser ou standardiser un processus de simulation ? dans l’affirmative quel

processus standardiser ?
• faut-il imposer à un utilisateur expérimenté un processus de simulation différent de son
point de vue ?
• faut-il ignorer des utilisateurs non expérimentés mais pouvant devenir potentiels ?
• comment pouvons-nous réduire voire éliminer les risques rencontrés dans une mauvaise
utilisation de la simulation, même par des utilisateurs expérimentés ?
• faut-il faire en sorte pour que la simulation reste uniquement un domaine privilégié des
spécialistes ?…
2.2.3. Des processus logiciels pour la génération et l’automatisation de

processus de simulation
De notre point de vue, ce travail doit aborder l’ensemble des étapes du processus à travers une
méthodologie globale. Cette méthodologie doit prendre en compte les problèmes de
génération automatisée des processus ainsi que les méthodes nécessaires pour la réalisation
des différentes étapes.
Il existe des technologies qui relèvent du génie logiciel et qui permettent la spécification de
processus logiciels. Parmi ces technologies, l’équipe Génie Logiciel du LLP/CESALP a
) * + )
développé un langage pour la génération de processus logiciels dans le cadre du projet

européen PIE (Process Instance Evolution). Dans ce travail, nous chercherons à utiliser entre
autres, ce langage de spécification de processus pour la description et la génération de
processus de simulation.
Il s’agit de définir un méta-modèle de processus permettant la génération de processus de

simulation et la formalisation des étapes sur la base de méthodes et d’outils d’analyse. Deux
phases de recherche peuvent être considérées, l’une à moyen terme et l’autre à long terme :
• dans la première phase, nous chercherons à formaliser et à spécifier un processus de

simulation standard permettant de retrouver les étapes fondamentalement nécessaires pour
guider un utilisateur non expérimenté (ce travail peut être réalisé à court et moyens termes
en stages de DEA),
• dans la seconde phase, nous proposons de définir et de formaliser un générateur de
processus de simulation permettant de générer un modèle de processus selon les besoins
propres de l’utilisateur que nous supposons expérimenté. La génération du modèle de
processus peut être basée sur des aspects ontologiques ou des points de vue différents. Ce
travail peut être réalisé à long terme dans le cadre de projets et de sujets de thèses.
Le modèle de description des processus devra posséder les mécanismes ou les fonctionnalités
qui permettent de spécifier la manière selon laquelle on génère un processus. Ainsi, pour un
non expérimenté le choix d’un type de processus peut être fixé a priori, alors que pour un
spécialiste de simulation on pourra relaxer les contraintes de génération du processus.
L’utilisateur dans ce dernier cas pourra générer le processus qui décrit son point de vue et qui
est adapté à ses besoins.
L’automatisation et la formalisation du processus devront permettre le contrôle des différents

allers/retours entre les différentes étapes du processus. A chaque phase du processus, des
accès dynamiques permettront l’utilisation de méthodes structurées et d’outils adaptés pour la
réalisation des activités définies. Une analyse approfondie de la littérature couplée à une
démarche expérimentale sur le terrain peuvent être les éléments de base à l’origine de cette
étude.
2.3. Modélisation et simulation du processus de pilotage selon une

approche multi-agents
2.3.1. Contexte de l’étude
L’approche d’intégration d’un processus de pilotage réactif basé sur l’indicateur de

performance dans un modèle de simulation, est sans doute une approche nouvelle. Les
concepts sous-jacents à cette approche, notamment le CP permet d’une part, une
représentation explicite des objectifs de la production, et d’autre part, le contrôle entre la
satisfaction de l’objectif et la mesure de la performance fournie par un STP exécutant une
fabrication. L’objectif définit la condition que l’on souhaite obtenir à l’issue de l’exécution
d’un processeur. Actuellement, le CP peut être vu comme un agent réactif, son comportement
séquentiel et prédictif est défini « a priori ». Il a ainsi, la possibilité de réagir et modifier le
#
) * + )
comportement des processeurs dont il est responsable. Le fait de donner plus d’autonomie et
plus d’intelligence au CP (auto-modification de l’objectif local, possession d’un
comportement intelligent) nous mènerait vers l’utilisation naturelle d’un agent cognitif et
d’une approche multi-agents pour la modélisation du processus de pilotage. Cette approche
fournit effectivement, une puissance d’expression pour la modélisation de la communication,
de la coordination, de la coopération et de la résolution des conflits. Ainsi, le comportement
du CP peut être amélioré pour gagner en efficacité et réactivité à l’aide des relations de
coordination et de coopération. Un système multi-agents adapté au CP est sûrement une piste
de recherche intéressante à long terme.
2.3.2. Définition de la problématique
Il s’agit de la conception d’un système multi-agents pour la modélisation et la simulation du

processus de pilotage dans le cadre de la plate-forme Apollo. Nous chercherons à combiner les
concepts développés sur le problème de pilotage industriel (CPs) et l’approche multi-agents.
Ainsi, pour résoudre des problèmes de modélisation complexe en pilotage, la méthodologie
sera basée sur la décomposition hiérarchique du problème en une série de problèmes partiels.
La solution à ces problèmes pourrait être représentée par des agents. La cohérence du modèle
global sera obtenue en combinant des agents élémentaires par utilisation d’opérateurs de
coordination et de coopération. Les opérateurs utilisés devraient permettre l’utilisation
combinée de différentes techniques en utilisant une description uniforme. La difficulté
principale dans la résolution de ce type de problème n’est pas liée à la manière de résolution
des problèmes élémentaires mais plutôt à la manière de décomposition du problème global en
une série de modèles élémentaires et à la manière d’agrégation des solutions individuelles en
une solution globale et cohérente. Les concepts déjà définis et formalisés dans nos travaux
ainsi qu’un système multi-agents peut aider à résoudre ce type de problème. Ainsi, ce travail
de recherche consiste en la définition des étapes suivantes :
• les propriétés devant être satisfaites par le système multi-agents d’après les concepts
proposés,
• le modèle de l’agent à représenter le CP (réactif, cognitif,…),
• l’architecture du système multi-agents en se basant sur les structures proposées,
• les mécanismes de coordination entre agents,
• une méthode de validation des propriétés du système.
2.3.3. Pourquoi l’approche multi-agents ?
2.3.3.1. Le CP vu comme un agent
Le paradigme multi-agents [Oquendo 1995] repose sur la répartition des connaissances et des
capacités de raisonnement. Il permet la multiplicité des points de vue et la multiplicité des
compétences dans des cadres distribués, coopératifs et évolutifs tels que les processus de
pilotage. La conception du paradigme multi-agents pour les processus de pilotage doit reposer
sur des agents artificiellement intelligents qui ont des connaissances sur leur environnement et
qui peuvent interagir avec d’autres agents par le biais de communications.
%
) * + )
Le concept d’agent a été utilisé pour différentes raisons comme par exemple l’extension du
concept objet et la conception de systèmes multi-agents dédiés à la résolution de problèmes
distribués [Durfee 1999] [Ferber 1999] où chaque agent est désigné de manière plus ou
moins indépendante du groupe pour résoudre une part particulière de l’ensemble du problème.
Vu l’utilisation étendue et évolutive du concept agent, une définition générale et acceptée de
l’agent n’est pas chose simple. Il est toutefois fréquent que les chercheurs donnent à l’agent la
définition suivante : un agent est un objet autonome ayant un objectif [Wooldridge 1999].
Franklin et al. [Franklin et al. 1996] proposent une notion d’agent plus étendue : an
autonomous agent is a system situated within and part of an environment that senses that
environment and acts on it, over time, in pursuit of its own agenda and so to effect what it
senses in the future. Cette définition ressemble de très près au concept de CP proposé. En
effet, le CP est aussi un système conçu pour prévoir et agir en vue de satisfaire une
performance à travers un objectif donné. Les concepts d’agent et de CP sont fortement
associés à la localisation. L’agent et le CP ont une représentation partielle du système de
pilotage. L’agent et le CP sont autonomes, ils décident en fonction d’objectifs locaux et sont
responsables de leurs propres comportements. De plus dans un système multi-agents, chaque
agent cherche à satisfaire ses objectifs locaux mais en coopérant avec les autres agents, un
réseau STP/CP l’est aussi. Ceci fait en sorte qu’un système multi-agents est pertinent pour
représenter un réseau de CPs. Ainsi, un Agent/CP peut représenter un CP comme il est défini
et formalisé dans nos travaux. L’Agent/CP cherchera à satisfaire l’objectif du CP. Le
comportement du CP définit la manière dont un Agent/CP doit agir. La mesure associée à un
indicateur de performance d’un STP correspond à une information d’entrée de l’Agent/CP.
Les valeurs associées aux seuils d’alerte et limite d’un objectif ainsi que la mesure fournie par
un STP définissent, par exemple, les conditions d’activation d’un Agent/CP. L’Agent/CP
génère un plan d’action selon la logique décrite dans un CP et le met en place en agissant sur
les variables d’action définies à cet effet. Un Agent/CP se désactive si la dérive d’un STP est
fausse ou si le plan d’action est mis en place. Un Agent/CP coopère avec d’autres Agent/CPs
du réseau grâce aux relations de coordination et de coopération, définies entre CPs.
Ainsi, dans ce travail nous chercherons à combiner des concepts définis sur le pilotage et de
l’agent. Nous souhaitons obtenir une méthode de conception structurée et générale adaptée à
nos besoins, pour résoudre le problème de pilotage dans un modèle de simulation.
Conceptuellement, l’agent fournit un avantage pratique, car tout ce qui est lié à une solution
particulière et partielle est implémenté dans un agent. Ce qui rendra plus facile toute
modification future dans le système multi-agents.
2.3.3.2. Conception d’un système multi-agents des CPs
La conception du système multi-agents basé sur les concepts développés doit tenir compte des
travaux existant dans ce domaine. En effet, il existe dans le domaine du pilotage des
architectures multi-pilotes (multi-controller) connues sous le nom d’approches à modèles
multiples (multiple models approach, local controller/model networks, operating regime
approach) [Breemen et al. 2000a] [Breemen et al. 2000b]. Ces architectures sont nées pour
répondre à un besoin d’approches de résolution de modèles complexes et de problèmes de
pilotage. Toutefois, elles sont limitées dans le sens où elles utilisent un seul type de pilote et
une technique particulière d’agrégation. L’utilisation d’un décideur centralisé appelé
superviseur pour décider de l’activation des pilotes et du moment d’activation, limite
l’évolutivité de l’architecture puisque des pilotes ne peuvent être ni ajoutés ni supprimés, à
condition que le superviseur soit adapté pour. Elles apparaissent sous différentes formes, de
) * + )
ce fait elles manquent de cadre de conception général. Pour pallier ces limites, l’architecture à
proposer doit posséder entre autres, les propriétés suivantes :
• la localisation et l’abstraction (les aspects liés à un sous-problème sont contenus dans un

objet),
• l’extensibilité (les modules sont indépendants de manière à pouvoir modifier, supprimer
ou ajouter de manière facile d’autres modules),
• l’hétérogénéité des techniques de pilotage (heuristiques classiques, réseaux de neurone,
logique floue, indicateurs de performance),
• l’hétérogénéité des techniques d’agrégation (utilisation d’opérateurs de coordination).
Suite au manque de cadre général de conception et malgré l’existence de similarités dans les
systèmes existants, une méthode de conception du système multi-agents reste à développer.
Toutefois, Voland [Voland 1999] propose un paradigme de conception itératif comprenant les
étapes suivantes : la définition du problème, la synthèse des solutions possibles, l’analyse,
l’évaluation et le choix de la solution la mieux adaptée, l’implémentation de la solution
choisie. Durfee [Durfee 1999] propose une stratégie de conception de systèmes multi-agents
consistant globalement en l’éclatement de l’étape d’analyse en trois tâches fondamentales : la
décomposition appelée aussi structuration, la résolution et l’agrégation. Ces tâches sont
également communes à notre vision du sous-système de pilotage. La décomposition consiste à
éclater le problème global en une série de problèmes partiels et indépendants. La résolution
consiste à trouver des solutions adaptées aux problèmes partiels en concevant des agents
capables d’accomplir une tâche particulière. L’agrégation consiste à associer la série d’agents
obtenus dans un tout cohérent en coordonnant proprement les activités des agents (utilisation
de mécanismes de coordination).
La conception doit résulter en un diagramme d’organisation hiérarchique d’Agent/CPs

et/ou de groupements d’Agent/CPs correspondant à la structure définie du réseau STP/CPs.
Ce diagramme doit représenter deux aspects importants : une décomposition fonctionnelle et
une structure temporelle. La structure globale de pilotage proposée dans nos travaux est un
exemple de ce type de diagramme. D’après [Ferber 1999], la décomposition d’un problème
peut se faire selon trois axes : objet, espace, fonction. En réalité, les axes selon lesquels un
problème peut être décomposé dépendent du problème et de sa nature. Un problème peut être
décomposé selon : un objet physique, un phénomène naturel, un objectif, un régime
opératoire, une série mathématique... Mais, quel que soit l’axe de décomposition, la
décomposition n’est pas unique et il n’existe pas de méthode formelle pouvant l’optimiser. Un
problème est décomposé en sous-problèmes jusqu’à ce que une solution soit trouvée pour
chacun des sous-problèmes. Le choix de l’axe définit la manière selon laquelle le problème
est conceptualisé et la solution est structurée fonctionnellement.
2.3.3.3. Définition des mécanismes de coordination
Du fait que chaque Agent/CP a son propre objectif, un comportement incohérent peut survenir
lors de l’agrégation de l’ensemble des Agent/CPs. Ainsi, il est nécessaire d’accomplir une
tâche complémentaire. Cette tâche cherche à former un tout cohérent, elle est appelée tâche de
coordination. Des objets, des agents ou des opérateurs de coordination sont à définir pour
mettre en place cette tâche (les différents mécanismes de coordination entre Agent/CPs). La
cohérence du réseau STP/CPs est assurée par ces mécanismes. Il est aussi fréquent de
) * + )
rencontrer certains types de problèmes, la tâche de coordination doit fournir une solution à
certains de ces problèmes :
• la détection (détection de l’état de dérive et activation du pilote concerné),

• l’initialisation (initialisation si nécessaire de l’Agent/CP après détection et activation),
• le pilotage en boucle ouverte (interconnexion avec les autres Agent/CPs),
• le conflit d’objectifs entre différents Agent/CPs,
• la réception de messages envoyés par d’autres Agent/CPs,
• l’envoi de messages à d’autres Agent/CPs,
• l’impasse de réagir à un problème non couvert par des Agent/CPs,
• l’activation simultanée de plusieurs Agent/CPs,
• la priorité d’activation affectée à un Agent/CP responsable de plusieurs STPs ou autres
Agent/CPs, …
Les mécanismes de coordination peuvent avoir différentes formes. Les deux formes les plus
familières sont connues par les mécanismes de coordination globale et locale (connue aussi
par coordination réactive [Ferber 1999]). Dans le cas d’une coordination globale, un
superviseur central prend la décision d’activer un agent comme il a été souligné auparavant.
Une coordination locale rassemble plutôt des conventions qui s’appliquent à tous les membres
d’une communauté et qui sont utilisées pour guider leurs activités. Les règles de circulation
sont un exemple de ces conventions. Dans le système multi-agents à développer, nous nous
orienterons vers les mécanismes de coordination locale. Les opérateurs de coordination font
partie de ce type de mécanismes. Comparées aux mécanismes de coordination globale, les
différences principales sont telles que les opérateurs de coordination :
• rendent les relations temporelles et structurelles entre les modèles locaux explicites,
• permettent la création d’une architecture évolutive et ouverte (les opérateurs de
coordination ne sont pas affectés par l’ajout ou la suppression d’un Agent/CP),
• offrent une manière uniforme pour appliquer des techniques d’agrégation différentes dans
un modèle.
Un groupe d’Agent/CPs coordonnés peut être lui-même vu comme un Agent/CP, et on peut

ainsi écrire :
Agent_CP1 := Ccoordination(Agent_CP2, Agent_CP3,…)

Qui signifie que le comportement de l’agent “Agent_CP1” est le résultat de
comportements coordonnés de l’ensemble des agents {Agent_CP2,
Agent_CP3,…}. Ainsi, des agents à comportement complexe peuvent être
définis de manière récursive à partir d’agents à comportement simple.
Un exemple de réseau STP/CPs dans un système multi-agents, peut être schématisé par la
figure 4.2. Dans cet exemple, les STPs représentent des ressources physiques, l’agent
“Agent_CP0” un responsable de ligne et les “Agent_CP1 à 3”des opérateurs. En utilisant des
opérateurs de coordination nous pouvons écrire :
Agent_CPate1 := Chor(Agent_CP1, Agent_CP2, Agent_CP3);

Agrégation des agents : “Agent_CP1”, “Agent_CP2”, et “Agent_CP3” de
même niveau en un agent “Agent_CPatel” à l’aide de l’opérateur de
coordination horizontale Chor.
) * + )
Agent_CPate := Cver(Agent_CPate1, Agent_CP0);

Agrégation de l’agent “Agent_CPatel” et de l’agent “Agent_CP0” de
niveaux différents en un agent “Agent_CPate” à l’aide de l’opérateur de
coordination verticale Cver.
Agent_CP0
Sous-système
Cver
de Pilotage : CPate Opérateur de coor. verticale
Agent_CP1 Agent_CP2 Agent_CP3

Chor Système de
Opérateur de coor. horizontale
Production
STP1 STP2 STP3

Sous-système
Opérationnel
Figure 4.2. - Exemple de réseau STP/CPs dans un système multi-agents.
Par ce travail, nous espérons contribuer à l’amélioration de l’accessibilité de la simulation des

systèmes industriels de manière globale… en tant qu’approche, technique ou outil d’aide à la
décision, et la rendre ainsi, un peu plus « active et intelligente » à travers une utilisation plus
aisée et plus conviviale.
&
) * + )
!
*-
./ 0 !1
1. OUVRAGES
[Afgi 1992] Association Française de Gestion Industrielle, « Évaluer pour évoluer, les indicateurs de
performance au service du pilotage industriel », Ouvrage Collectif AFGI, octobre 1992.
[APICS 1995] Apics Dictionary, 8th edition, Editors : J.F. Cox, J.H. Blackstone, M.S. Spencer, American
Production and Inventory Control Society, Inc. 1995.
[Bailly et al. 1987] C. Bailly, J.F. Challine, H. C. Ferri, B. Marchesin, « Les langages orientés objets, concepts,
langages et applications », Éditions Cépadues, 1987.
[Birtwistle et al. 1973] G. Birtwistle, O.J. Dahl, B. Myhrhaug, K. Nygaard, « Simula Begin », Petrocelli Charter,
New York, 1973.
[Booch 1991] G. Booch, « Object-oriented design with applications », The Benjamin/Cummings Publishing
Company, Inc., Redwood City, CA, 1991.
[Carrie 1988] A. Carrie, « Simulation of manufacturing systems », John Wiley & Sons Ltd., New York, 1988.
[Cernault 1988] A. Cernault « La simulation des systèmes de production », Éditions Cépadues, 1988.
[David et al. 1988] R. David, H. Alla, « Du Grafcet aux réseaux de Petri », Éditions Hermès, 1988.
[Durfee 1999] E. Durfee, « Distributed problem solving and planning », In: G. Weiss (ed.), Multiagent Systems,
The MIT Press, Cambridge, 1999.
[Evans 1988] J.B. Evans, « Structure of discrete event simulation », Ellis Horwood, Chichester, 1988.
[Ferber 1999] J. Ferber, « Multi-Agent Systems – An introduction to distributed artificial intelligence »,
Addison-Wesley, Harlow, England, 1999.
[Giard 1988] V. Giard, « Gestion de la production », 2ème édition, Economica, 1988.
[Goldberg 1984] A. Goldberg, « Smalltalk 80 : the interactive programming environment », Addison Wesley,
1984.
[Goldberg et al. 1985] A. Goldberg, D. Robson, « Smalltalk 80 : the language and its implementation »,
Addison Wesley, 1985.
[Hill 1989] T. Hill, « Manufacturing strategy – text and cases », Irwin, Homewood, Boston, 1989.
- / 0 1 2 ) 3
[Hoover et al. 1989] S. Hoover, R. Perry, « Simulation – A problem solving approach », Addison-Wesley,
Reading, MA, 1989.
[Kettani et al. 1999] N. Kettani, D. Mignet, P. Paré, C. Rosenthal-Sabroux, « De Merise à UML », Editions
Eyrolles, 1999.
[Kleijnen 1987] J.P.C. Kleijnen, « Statistical tools for simulation practitioners », Marcel Dekker, Inc., New
York, 1987.
[Lanner 1998] Lanner Group, « WITNESS User Manual », Version 9, Lanner Group, 1998.
[Law et al. 1991] A.M. Law, W.D. Kelton, « Simulation modeling and analysis », Second edition, McGraw Hill,
New York, NY, 1991.
[Le Moigne 1974] J.L. Le Moigne, « Les systèmes de décision dans les organisations », Presses Universitaires
de France, 1974.
[Le Moigne 1990] J.L. Le Moigne, « La théorie du système général : théorie de la modélisation », 2ème édition,
Paris, 1990.
[Mélèse 1972] J. Mélèse, « L’analyse Modulaire des Systèmes, AMS », Homme et techniques, 1972.
[Melnyk et al. 1987] S.A. Melnyk, P.L. Carter, « Production Activity Control », The Business One Irwin /
APICS Series in Production Management, Homewood, Illinois, 1987.
[Mitrani 1982] I. Mitrani, « Simulation techniques for discrete event systems », Cambridge University Press,
Cambridge, 1982.
[Modsim 1995] MODSIM II, « MODSIM II The language for object oriented programming, Reference
Manual », CACI Products Company, 1995.
[O’Keefe 1985] R.M. O’Keefe, « Inter_SIM user manual », Decision Computing, 1985.
[Pegden et al. 1990] C.D. Pegden, R.E. Shannon, R.P. Sadowski, « Introduction to simulation using SIMAN »,
McGraw Hill, New York, NY, 1990.
[Pierreval 1990] H. Pierreval, « Les méthodes d’analyse et de conception des systèmes de production », Éditions
Hermès, 1990.
[Pritsker 1986] A.A.B. Pritsker, « Introduction to simulation and SLAM II », Halsted Press, New York, NY, 3rd
edition, 1986.
[Pritsker 1991] A.A.B. Pritsker, « Introduction to simulation and SLAM II », Halsted Press, New York, NY, 5th
edition, 1991.
[ProModel 1991] « ProModel User’s Manual », ProModel Corporation, Orem, Utah, 1991.
[Proth et al. 1987] J. Proth, J.B. Cavaille, « Pratique de la simulation de production discontinue », Éditions
Siprodis, 1987.
[Roboam 1993] M. Roboam, « La méthode GRAI : principes, outils, démarches et pratiques », Edition Teknea,
1993.
[Rodde 1991] G. Rodde, « Les systèmes de production – modélisation et performance », Éditions Hermès, 1991.
[Rose 1992] O. Rose, « SIM Plus Plus, user manual », University of Karlsruhe, Germany, June 1992.
[Taha 1997] H.A. Taha, « Operations Research – An Introduction », 6th edition, Prentice-Hall, Englewood
Cliffs, NJ, 1997.
[Voland 1999] G. Voland, « Engineering by design », Addison Wesley, 1999.
[Wooldridge 1999] M. Wooldridge, « Intelligent Agents », In: G. Weiss (ed.), Multiagent Systems, The MIT
Press, Cambridge, 1999.
2. REVUES
[Abdallah 1995] M.H. Abdallah., « A knowledge-based simulation model for job shop scheduling »,
International Journal of Operations & Production Management, Vol. 15, No. 10, 1995, pp. 89-102.
[Aghetta 1987] M. Aghetta, « La simulation des systèmes flexibles à la SNECMA », Usinica, 1987, pp. 387-421.
$
- / 0 1 2 ) 3
[Altmyer 2000] D.J. Altmyer, « Using an online stock market simulation as a cross-disciplinary learning
enhancer : simulation as an example of grey literature », The International Journal on Grey Literature, Vol.
1, No. 3, 2000, pp. 121-126.
[Amar et al. 1992] S. Amar, E. Craye, J.C. Gentina, « Une méthode hiérarchique de spécification et de
prototypage des systèmes de production flexible », RAIRO-APII, Vol. 26, No. 5-6, 1992, pp. 483-514.
[Ammar et al. 1985] M. Ammar, J.L. Damret, J.P. Kieffer, « Utilisation d’un macro langage dédié à la
simulation des systèmes de production », APII, Vol. 19, 1985, pp. 437-453.
[Baines et al. 1998] T.S. Baines, D.K. Harrison, J.M. Kay and D.J. Hamblin, « A consideration of modelling
techniques that can be used to evaluate manufacturing strategies », International Journal of Advanced
Manufacturing Technology, Vol. 14, 1998, pp. 369-375.
[Balci 1994] O. Balci, « Validation, verification, and testing techniques throughout the life cycle of a simulation
study », Annals of Operations Research, Vol. 53, 1994, pp. 121-173.
[Balci 1997] O. Balci, « Principles of simulation model validation, verification, and testing », Transactions of
the Society for Computer Simulation International, Vol. 14, 1997, pp. 3-12.
[Ball et al. 1994] P. Ball, D. Love, « Expanding the capabilities of manufacturing simulators through
application of object-oriented principles », Journal of Manufacturing Systems, Vol. 13, No. 6, 1994, pp. 412-
423.
[Ballot 1997] E. Ballot, « La simulation industrielle : aide réelle ou virtuelle à la prise de décision ? », Revue
Française de Gestion Industrielle, Vol. 16, No. 1, 1997, pp. 21-38.
[Banks et al. 1991] J. Banks, E. Aviles, J.R. McLaughlin and R.C. Yuan, « The simulator: new member of the
simulation family », Interfaces, Vol. 21, No. 2, 1991, pp.76-86.
[Bekker et al. 1999] J. Bekker, S. Saayman, « Drawing conclusions from deterministic logistic simulation
models », Logistics Information Management, Vol. 12, No. 6, 1999, pp. 460-466.
[Bézivin et al. 1991] J. Bézivin, P. Cointe, « Le modèle objet : un carrefour d’innovation dans le domaine des
langages et des systèmes informatiques », AFCET / Interfaces, No. 103/104, mai/juin 1991, pp. 34-38.
[Blosch et al. 1999] M. Blosch, J. Antony, « Experimental design and computer-based simulation : a case study
with the Royal Navy », Managing Service Quality, Vol. 9, No. 5, 1999, pp. 311-319.
[Boukachour et al. 1993] J. Boukachour, T. Galinho, J.P. Pécuchet, « Étude comparative entre simulation et
placement en ordonnancement », APII, Vol. 27, No. 5, 1993, pp. 531-585.
[Bourey et al. 1991] J.-P. Bourey, J.-C. Gentina, « Conception structurée et modulaire d’architecture de
contrôle répartie en production flexible manufacturière », RAIRO-APII, Vol. 25, No. 4, 1991, pp. 349-376.
[Brennan et al. 1999] R.W. Brennan, B. Foroughi, « A control framework to support responsive
manufacturing », International Journal of Agile Management Systems, Vol. 1, No. 3, 1999, pp. 159-168.
[Caron et al. 2000] F. Caron, G. Marchet, A. Perego, « Layout design in manual picking systems : a simulation
approach », Integrated Manufacturing Systems, Vol. 11, No. 2, 2000, pp. 94-104.
[Chakravorty et al. 1995] S.S. Chakravorty, J.B. Atwater, « Do JIT lines perform better than traditionally
balanced lines », International Journal of Operations & Production Management, Vol. 15, No. 2, 1995, pp.
77-88.
[Chan et al. 1995] F.T.S. Chan, B. Jayaprakash, N.K.H. Tang, « Design of automated cellular manufacturing
systems with simulation modelling : a case study », International Journal of Computer Applications in
Technology, Vol. 8, No. 1/2, 1995, pp. 1-11.
[Chan et al. 1999] F.T.S. Chan, B. Jiang, « Simulation-aided design of production and assembly cells in an
automotive company », Integrated Manufacturing Systems, Vol. 10, No. 5, 1999, pp. 276-283.
[Chau et al. 1994] P.Y.K. Chau, P.C. Bell, « Decision-support for the design of a new production plant using
visual interactive simulation », Journal of the Operational Research Society, Vol. 45, No. 11, 1994, pp. 1273-
1284.
[Cumenal 1997] Didier Cumenal, « Un modèle de dynamique des systèmes pour l’analyser et comprendre les
changements d’état de l’organisation », Revue Internationale de systémique, Vol. 11, No. 2, 1997, pp. 177-
214.
- / 0 1 2 ) 3
[Dahl et al. 1966] O.J. Dahl, K. Nygaard, « Simula – An algol-based simulation language », Communications of
the ACM, Vol. 9, No. 9, 1966, pp. 671-678.
[Davis et al. 1994] L. Davis, G. Williams, « Evaluating and selecting simulation software using the analytic
hierarchy process », Integrated Manufacturing Systems, Vol. 5, No. 1, 1994, pp. 23-32.
[Denzler et al. 1987] D.R. Denzler, W.J. Boe, « Experimental investigation of flexible manufacturing scheduling
decision rules », International Journal of Production Research, Vol. 25, No. 7, 1987, pp. 979-994.
[Disney et al. 1997] S.M. Disney, M.M. Naim, D.R. Towill, « Dynamic simulation modelling for logistics »,
International Journal of Physical Distribution & Logistics Management, Vol. 27, No. 3/4, 1997, pp. 174-196.
[Doyle et al. 2000] D. Doyle, F.W. Brown, « Using a business simulation to teach applied skills – the benefits
and the challenges of using student teams from multiple countries », Journal of European Industrial Training,
Vol. 24, No. 6, 2000, pp. 330-336.
[Ekere et al. 1989] N.N. Ekere and R.G. Hannam, « An evaluation of approaches to modelling and simulating
manufacturing systems », International Journal of Production Research, Vol. 27, No. 4, 1989, pp.599-611.
[Fishwick 1997] P.A. Fishwick, « Computer simulation : growth through extension », Transactions of the
Society for Computer Simulation International, Vol. 14, 1997, pp. 13-23.
[Garetti et al. 1990] M. Garetti, A. Pozzetti, A. Bareggi, « On-line loading and dispatching in flexible
manufacturing systems », International Journal of Production Research, Vol. 28, No. 7, 1990, pp. 1271-1292.
[Gindy et al. 1998] N.N. Gindy, S.M. Saad, « Flexibility and responsiveness of machining environments »,
Integrated Manufacturing Systems, Vol. 9, No. 4, 1998, pp. 218-227.
[Gopinath et al. 1999] C. Gopinath, J.E. Sawyer, « Exploring the learning from enterprise simulation », The
Journal of Management Development, Vol. 18, No. 5, 1999.
[Goyal et al. 1995] S.K. Goyal, K. Mehta, R. Kodali, S.G. Deshmukh, « Simulation for analysis of scheduling
rules for a flexible manufacturing system », Integrated Manufacturing Systems, Vol. 6, No. 5, 1995, pp. 21-
26.
[Habchi et al. 1992] G. Habchi, F. Deloule, « Study of modeling and simulation for a chemical production
system », Simulation Journal, Society for Computer Simulation International, Vol. 58, 1992, pp. 366-374.
[Habchi et al. 1995] G. Habchi, C. Labrune, « Study of lot sizes on job shop systems performance using
simulation », Simulation Practice and Theory Journal, Elsevier, Vol. 2, 1995, pp. 277-289.
[Habchi 2000] G. Habchi, « Editorial – Modelling and simulation of complex production systems », Simulation
Practice and Theory Journal, Elsevier, Vol. 8, No. 5, 2000, pp. 281-282.
[Hansford et al. 1992] L.C. Hansford, J.R. Grove J.R., P.J. Sweeney, « Using simulation technology in
organisational development », Journal of Systems Management, February, 1992, pp. 28-31.
[Haslett et al. 2000] T. Haslett, C. Osborne, « Local rules : their application in a kanban system », International
Journal of Operations & Production Management, Vol. 20, No. 9, 2000, pp. 1078-1092.
[Hlupic 1994] V. Hlupic, « Manufacturing simulators : an evaluation and comparison », International Journal
of Manufacturing Systems, Vol. 1, No. 3, 1994, pp. 177-185.
[Hlupic et al. 1995] V. Hlupic and R.J. Paul, « A critical evaluation of four manufacturing simulators »,
International Journal of Production Research, Vol. 33, No. 10, 1995, pp. 2757-2766.
[Hlupic et al. 1999] V. Hlupic, Z. Irani and R.J. Paul, « Evaluation framework for simulation software »,
International Journal of Advanced Manufacturing Technology, Vol. 15, 1999, pp. 366-382.
[Hooper et al. 1982] J.W. Hooper, K.D. Reily, « An algorithmic analysis of simulation strategies »,
International Journal of Computer and Information Sciences, Vol. 11, No. 2, 1982, pp. 101-122.
[Hoyt et al. 1999] J. Hoyt, F. Huq, « Research communications – A simulation model of the contract change
process », Kybernetes, Vol. 28, No. 6/7, 1999, pp. 826-836.
[Huq et al. 1995] F. Huq, Z. Huq, « The sensitivity of rule combinations for scheduling in a hybrid job shop »,
[Irani et al. 2000] Z. Irani, V. Hlupic, L.P. Baldwin, P.E.D. Love, « Re-engineering manufacturing processes
through simulation modelling », Logistics Information Management, Vol. 13, No. 1, 2000, pp. 7-13.
#
- / 0 1 2 ) 3
[Ito 2000] Y. Ito, « Adaptive dynamic input-output analysis using neural networks (Japanese industrial
structure) », Kybernetes, Vol. 29, No. 9/10, 2000, pp. 1087-1102.
[Jacobs et al. 1994] L.W. Jacobs, J. Lauer, « DSS for job shop machine scheduling », Industrial Management &
Data Systems, Vol. 94, No. 4, 1994, pp. 15-23.
[Jahangirian et al. 2000] M. Jahangirian, G.V. Conroy, « Intelligent dynamic scheduling system : the
application of genetic algorithms », Integrated Manufacturing Systems, Vol. 11, No. 4, 2000, pp. 247-257.
[Kallel et al. 1985] G. Kallel, X. Pellet, Z. Binder, « Conduite décentralisée coordonnée d’atelier », RAIRI-
APII, Vol. 19, 1985, pp. 371-387.
[Kuljis 1994] J. Kuljis, « User interfaces and discrete event simulation models », Simulation Practice and
Theory Journal, Elsevier Science, Vol. 1, 1994, pp. 195-205.
[Kosturiak et al. 1998] J. Kosturiak, M. Gregor, « FMS simulation : some experience and recommendations »,
Simulation Practice and Theory Journal, Elsevier, Vol. 6, No. 5, 15 July 1998, pp. 423-442.
[Lehaney et al. 1998] B. Lehaney, H. Kogetsidis, A. Platt, S. Clarke, « Windows-based simulation software as
an aid to learning », Journal of European Industrial Training, Vol. 22, No. 1, 1998, pp. 12-17.
[Lehtonen et al. 1997] J.M. Lehtonen, U. Seppälä, « A methodology for data gathering and analysis in a
logistics simulation project », Integrated Manufacturing Systems, Vol. 8, No. 6, 1997, pp. 351-358.
[Leu et al. 1995] B.Y. Leu, J.W. Nazemetz, « Comparative analysis of group scheduling heuristics in a flow
shop cellular system », International Journal of Operations & Production Management, Vol. 15, No. 9, 1995,
pp. 143-157.
[Lyons et al. 2000] A.C. Lyons, M. Nemat and W.B. Rowe, « A comparative study of alternative approaches to
modelling the operations of a small enterprise », Work Study, Vol. 49, No. 3, 2000, pp. 107-114.
[Marin et al. 1998] R.M. Marin, J. Garrido, J.L. Trillo, J. Saez, J. Armesto, « Design and simulation of an
industrial automated overhead warehouse », Integrated Manufacturing Systems, Vol. 9, No. 5, 1998, pp.
308-313.
[Nance 1994] R.E. Nance, « The conical methodology and the evolution of simulation model development »,
Annals of Operations Research, Vol. 53, 1994, pp. 1-45.
[Paul 1991] R.J. Paul, « Recent developments in simulation modelling », Journal of Operations Research
Society, Vol. 56, No. 2, 1991, pp. 91-103.
[Pelagagge et al. 1998] P.M. Pelagagge, G. Cardarelli, A. Santalucia, « Comparison of conventional and
dynamic FMS periodic loading rules », Integrated Manufacturing Systems, Vol. 9, No. 1, 1998, pp. 15-22.
[Pierreval et al. 1990] H. Pierreval, H. Ralambondrainy, « A simulation and technique for generating knowledge
about manufacturing systems behaviour », Journal of Operational Research Society, Vol. 41, 1990, pp. 461-
474.
[Pierreval et al. 1998] H. Pierreval, L. Plaquin, « An evolutionary approach to multicriteria cell formation
problems », International Transactions in Operational Research, Vol. 5, No. 1, 1998, pp. 13-25.
[Polajnar et al. 1995] A. Polajnar, B. Buchmeister, M. Leber, « Analysis of different transport solutions in the
flexible manufacturing cell by using computer simulation », International Journal of Operations & Production
Management, Vol. 15, No. 6, 1995, pp. 51-58.
[Rachamadugu et al. 1994] R. Rachamadugu, K.E. Stecke, « Classification and review of FMS scheduling
procedures », Production Planning and Control, Vol. 5, No. 1, 1994, pp. 2-20.
[Roberts et al. 1998] C.A. Roberts, Y.M. Dessouky, « An overview of object-oriented simulation », Simulation
Journal, The Society for Computer Simulation International, Vol. 70, No. 6, June 1998, pp. 359-368.
[Robinson 1994] S. Robinson, « Simulation projects : building the right conceptual model », Industrial
Engineering, September 1994, pp. 34-36.
[Rogers et al. 1991] P. Rogers, M.T. Flanagan, « Online simulation for real-time scheduling of manufacturing
systems », Industrial Engineering, Vol. 37, 1991, pp. 37-40.
[Rooks 2000] B. Rooks, « Winning ways for manufacturing », Assembly Automation, Vol. 20, No. 1, 2000, pp.
35-39.
%
- / 0 1 2 ) 3
[Rosen 1987] J.P. Rosen, « Méthode de conception orientée objets », Revue Génie Logiciel, No. 9, Editions
EC2, novembre 1987.
[Saad et al. 1998] S.M. Saad, M.D. Byrne, « Comprehensive simulation analysis of a flexible hybrid assembly
system », Integrated Manufacturing Systems, Vol. 9, No. 3, 1998, pp. 156-167.
[Spedding et al. 1997] T.A. Spedding, W.L. Lee, R. de Souza, S.S.G. Lee, « Adaptive simulation of a keyboard
assembly cell », Integrated Manufacturing Systems, Vol. 8, No. 1, 1997, pp. 50-58.
[Spedding et al. 2001] T.A. Spedding, K.K. Chan, « System level improvement using discrete event
simulation », International Journal of Quality & Reliability Management, Vol. 18, No. 1, 2001, pp. 84-103.
[Soon et al. 1997] T.H. Soon, R. de Souza, « Intelligent simulation-based scheduling of workcells : an
approach », Integrated Manufacturing Systems, Vol. 8, No. 1, 1997, pp. 6-23.
[Tabucanon et al. 1998] M.T. Tabucanon, D.N. Batanov, S. Basu, « Using simulation to evaluate the batching
approach to part type selection in flexible manufacturing systems », Integrated Manufacturing Systems, Vol.
9, No. 1, 1998, pp. 5-14.
[Taylor 1999] L.J. Taylor III, « A simulation study of WIP inventory drive systems and their effect on financial
measurements », Integrated Manufacturing Systems, Vol. 10, No. 5, 1999, pp. 306-315.
[Trego 1997] L. Trego, « Factory layout and manufacturing simulation », Automotive Engineering, Vol. 105,
No. 5, 1997, pp. 113-115.
[Tucker et al. 1998] W.V. Tucker, L. Stuckey, Jr., « The roles of modeling and simulation at Boeing »,
Transactions of The SCSI, Vol. 15, No. 1, March 1998, pp. 3-9.
[Welgama et al. 1995] P.S. Welgama, R.G.J. Mills, « Use of simulation in the design of a JIT system »,
3. CONGRÈS
[Bakalem et al. 1996] M. Bakalem, G. Habchi, A. Courtois, « Conceptual frames for physical and control
systems modelling in manufacturing simulation », 8th European Simulation Symposium, Simulation in
Industry, Genoa, Italy, Vol. 1, October 24-26, 1996, pp. 319-323.
[Banks 1994] J. Banks, « Pitfalls in the simulation process », Conference on New Directions in Simulation for
Manufacturing and Communications, Operations Research Society of Japan, Tokyo, Japan, 1994, pp. 57-63.
[Bel et al. 1990] G. Bel, J.B. Cavaille, « Integration of simulation within production systems design : advantages
and dangers of the object-oriented language », CIM’90, Bordeaux, France, June 1990, pp. 597-603.
[Bensen 1996] D. Bensen, « Simulation modeling and optimization using ProModel », Winter Simulation
Conference, San Diego, USA, 1996.
[Berchet et al. 1999a] C. Berchet, G. Habchi, A. Courtois, « Pilotage et prise de décision industrielle », 3ème
Congrès International de Génie Industriel, Montréal, Canada, Vol. 3, mai 1999, pp. 1955-1964.
[Berchet et al. 1999b] C. Berchet, G. Habchi, A. Courtois, « Intégration du processus de pilotage à la
simulation des systèmes de production », MOSIM’99, 2ème Conférence Francophone de Modélisation et
Simulation, Annecy, France, 6-8 octobre 1999, pp. 337-343.
[Berchet et al. 2000] C. Berchet, G. Habchi, « The control centre: a basic concept for modelling industrial
control in simulation », ASI’2000, Bordeaux, France, 18-20 septembre 2000.
[Berchet et al. 2001] C. Berchet, G. Habchi, « Formalisation du Centre de Pilotage pour la Simulation des
Systèmes Industriels », MOSIM’01, 3ème Conférence Francophone de Modélisation et Simulation, Troyes,
France, 25-27 avril 2001, pp. 451-457.
[Bézivin 1989] J. Bézivin, « Smalltalk 80 et le modèle objet », Greco de Programmation – PRC, Montparnasse,
Paris, 1989.
[Bischak et al. 1991] D.P. Bischak, S.D. Roberts, « Object-oriented simulation », Winter Simulation
Conference, Phoenix, AZ, USA, 1991, pp. 187-193.
- / 0 1 2 ) 3
[Breemen et al. 2000a] A.J.N. van Breemen, T.J.A. de Vries, “An agent-based framework for designing multi-
controller systems”, 5th International Conference on The Practical Applications of Intelligent Agents and
Multi-Agent Technology, Manchester, U.K., 10th-12th April 2000, pp. 219-235.
[Breemen et al. 2000b] A.J.N. van Breemen, T.J.A. de Vries, J.B. Striper, “An agent-based framework for local
model approaches”, 16th IMACS World Congress 2000 on Scientific Computation, Applied Mathematics and
Simulation, EPFL, Lausanne, Switzerland, August, 2000.
[Chung et al. 1994] K.H. Chung , F. Knop, « Efficient approaches for designing a process-interaction
simulation kernel », Summer Computer Simulation Conference, 1994, pp. 23-28.
[Corthier et al. 1991] G. Corthier, P. Castagna, J.J. Lesage, « Définition d’un modèle Siman au moyen de la
méthode SA/RT », 23ème CIRP, Séminaire international sur les systèmes de production, Nancy, juin 1991.
[Dijk 1999] N.M. van Dijk, « On hybrid combination of queuing and simulation », DSI’99, Decision Sciences
Institute, 5th International Conference, Athens, Greece, 4-7 July 1999, pp. 1131-1133.
[Esquirol et al. 1994] P. Esquirol, P. Lopez, L. Haudot, M. Sicard, « Un Système COopératif en
Ordonnancement de Production », AGI’94, Colloque Automatique – Génie Informatique – Image, Poitiers,
France, 2-3 juin, 1994.
[Franklin et al. 1996] S. Franklin, A. Graesser, « Is it an agent, or just a program », 3rd International Workshop
on Agent Theories, Architectures and Languages, Budapest, Hungary, 1996, pp. 193-206.
[Fritschy 1990] D. Fritschy, « Object-oriented simulation, new requirements for temporal simulation of flows in
FMS », SIM’90, Bordeaux, France, June 1990, pp. 585-595.
[Garzia et al. 1986] R.F. Garzia, M.R. Garzia, B.P. Zeigler, « Discrete event simulation », IEEE Spectrum,
December 1986, pp. 32-36.
[Habchi et al. 1993] G. Habchi, M. Bakalem, « A dynamic study using simulation to well-balance an assembling
transfer line », SIMTEC’93 International Simulation Technology MultiConference, San Francisco, USA,
November 7-10, 1993, pp. 132-138.
[Habchi et al. 1994] G. Habchi, M. Bakalem, A. Courtois, « The PPS : a processor object for modelling and
simulation of manufacturing systems », CISS – First Joint Conference of International Simulation Societies,
ETH Zurich, Switzerland, August 1994, pp. 515-519.
[Habchi et al. 1996] G. Habchi, P. Sénéclauze, « Computer integration of fractional experimental designs and
job shop system simulation », 1996 Simulation Multiconference, Simulators International XIII, New Orleans,
USA, April 8-11, 1996, pp. 117-122.
[Habchi 1997] G. Habchi, « La simulation et la conduite des systèmes manufacturiers – Optimisation d’un
programme de production », MOSIM’97, 1ère Conférence Francophone de MOdélisation et SIMulation,
Rouen, France, 5-6 juin 1997, pp. 221-228.
[Habchi 1998] G. Habchi, « Study of the effect of process time variability on the production flow of a
manufacturing system », ASTC’98, Advanced Simulation Technologies Conference, Boston, USA, April 5-9,
1998, pp. 221-226.
[Habchi et al. 1999] G. Habchi, C. Berchet, « Analysis of decision making and industrial control process »,
DSI’99, Decision Sciences Institute, 5th International Conference, Athens, Greece, 4-7 July 1999, pp. 777-
779.
[Hlupic et al. 1994] V. Hlupic and R.J. Paul, « How to improve manufacturing simulators », CISS – First Joint
Conference of International Simulation Societies, ETH Zurich, Switzerland, August 1994, pp. 445-450.
[Hollinger 1987] D. Hollinger, « Les langages orientés objet en spécification et simulation de systèmes
productiques », Siprodis, Actes du séminaire, EC2, 1987, pp. 77-91.
[Kellert 1992] P. Kellert, « Méthodologie orientée objet pour la modélisation des systèmes de production »,
INFORSID’92, Clermont-Ferrand, France, 1992.
[Khalfoun et al 1995] M. Khalfoun et A. Gharbi, « Sélection d’une configuration d’un FMS; une approche
multicritère », Congrès International de Génie Industriel, Montréal, Octobre 1995.
[Kieffer et al. 1991] F. Kieffer, J.J. Lesage, « Intégration des phases de modélisation fonctionnelle et d’analyse
des données », 23th CIRP, Nancy, 6-7 juin 1991.
- / 0 1 2 ) 3
[Kindler 2000] E. Kindler, « Simulation of systems with simulating components », Management and Control of
Production and Logistics, MCPL’2000, Grenoble, 5-8 juillet 2000.
[Kouiss et al. 1995] K. Kouiss, H. Pierreval, N. Mébarki, « Toward the use of a multi-agent approach to the
dynamic scheduling of flexible manufacturing systems », International Conference on Industrial Engineering
and Production Management, IEPM’95, Maroc, avril 1995, pp. 118-125.
[Law 1994] A. Law, « How to successfully simulate your system », Conference on New Directions in Simulation
for Manufacturing and Communications, Operations Research Society of Japan, Tokyo, Japan, 1994, pp. 1-3.
[Muller et al. 1990] D.J. Muller, J.K. Jackman, C. Fitzwater, « A simulation-based work order release
mechanism for a flexible manufacturing system », Winter Simulation Conference, 1990, pp. 599-602.
[Musselman 1993] K.J. Musselman, « Guidelines for simulation project success », Winter Simulation
Conference, IEEE, New York, NY, USA, 1993, pp. 58-64.
[Novak 2000] P. Novak, « Reflective simulation of production and logistic systems with simula and java »,
Management and Control of Production and Logistics, MCPL’2000, Grenoble, 5-8 juillet 2000.
[Ogle et al. 1991] M.K. Ogle, T.G. Beaumariage, C.A. Roberts, « The separation and explicit declaration of
model control structures in support of object-oriented simulation », Winter Simulation Conference, 1991, pp.
1173-1179.
[Peck et al. 1992] S.N. Peck, S.J.E. Taylor, « Modelling discrete-event systems using co-opting processes »,
Summer Computer Simulation Conference, 1992, pp. 53-57.
[Pesin et al. 1998] P. Pesin, D. Trentesaux, C. Tahon « Towards a design methodology of a multi-agents
structure integrating the human operator for the activity control of complex industrial systems », 17th
European Annual Conference on human decision making and manual control, 1998.
[Paris et al. 1998] J.L Paris, H. Pierreval, L. Tautou, « Computational Intelligence in simulation optimisation : a
distributed tool using PVM and its application in manufacturing », EUROSIM'98 Conference, Helsinky,
Finlande, Vol. 2, 14-15 April, 1998, pp.340-346.
[Pierreval 1999] H. Pierreval, « Proposition de typologie des décisions en temps réel agissant sur les flux des
systèmes de production », MOSIM’99, 2ème Conférence Francophone de MOdélisation et SIMulation,
Annecy, France, 6-8 octobre 1999, pp. 331-336.
[Rothenberg 1986] J. Rothenberg, « Object-Oriented Simulation : where do we go from here ? », Winter
Simulation Conference, 1986, pp. 464-469.
[Sargent 1984] R.G. Sargent, « A tutorial on verification and validation of simulation models », Winter
Simulation Conference, IEEE Computer Society, Dallas, USA, 1984.
[Sargent 1999] R.G. Sargent, « Verification and validation of computer-based models », DSI’99, Decision
Sciences Institute, 5th International Conference, Athens, Greece, July 4-7, 1999, pp. 1127-1130.
[Tautou et al. 1998] L. Tautou-Guillaume, J.L. Paris, H. Pierreval, « Configuration of a simulated flexible
manufacturing system at a design stage: a case study using a distributed evolutionary optimisation
approach », SCSC'98 Conference, Reno, Nevada, USA, 19-22 July, 1998.
[Tumay 1987] K. Tumay, « Factory simulation with animation : the no programming approach », Winter
Simulation Conference, Atlanta, GA, USA, 1987.
[Vernadat 1999] FB. Vernadat, « Requirements for simulation tools in enterprise engineering », 15th Int.
Conference On CAD/CAM, Robotics and Factories of the Future (CARs & FOF’99), Aguas de Lindoia, SP
Brazil, August 18-20, 1999, Vol. 1, pp. MT5-19 – MT5-24.
[Ye 1994] X. Ye, « Object oriented process simulation », ESM’94, Modelling and Simulation, Barcelona, Spain,
June 1994, pp. 393-398.
[Yucesan et al. 1992] E. Yucesan, S.H. Jacobson, « Building correct simulation models is difficult », Winter
Simulation Conference, IEEE, New York, NY, USA, 1992, pp. 783-789.
- / 0 1 2 ) 3
4. MEMOIRES
[Ait Hssain 1993] A. Ait Hssain ou Bouhouch, « Conduite hiérarchisée intégrée des ateliers manufacturiers
flexibles : une approche mixte objets / réseaux de Petri », Thèse de doctorat en Automatique – Productique,
INP de Grenoble, décembre 1993.
[Archimède 1991] B. Archimède, « Conception d’une architecture réactive distribuée et hiérarchisée pour le
pilotage des systèmes de production », Thèse de doctorat, Université de Bordeaux I, 1991.
[Avenier 1984] M.J. Avenier, « Pilotage de l’entreprise et environnement complexe, une aide à la conception
d’un pilotage plus effectif », Thèse d’État en Sciences Économiques, Université de Droit, d’Économies des
Sciences d’Aix-Marseille, juillet 1984.
[Bakalem 1996] M. Bakalem, « Modélisation et simulation orientées objet des systèmes manufacturiers »,
Thèse de doctorat en Électronique – Électrotechnique – Automatique, Université de Savoie, juillet 1996.
[Barakat 1991] O. Barakat, « Contribution à la modélisation et à la simulation orientées objet des systèmes de
production », Thèse de doctorat de l’université de Franche Comté, 1991.
[Berchet 2000] C. Berchet, « Modélisation pour la simulation d’un système d’aide au pilotage industriel »,
Thèse de Doctorat en Génie Industriel, INP de Grenoble, décembre 2000.
[Berrah 1997] L. Berrah, « Une approche d’évaluation de la performance industrielle – Modèle d’indicateur et
techniques floues pour un pilotage réactif », Thèse de doctorat en Génie Industriel, INP de Grenoble,
septembre 1997.
[Billaut 1993] J.-C. Billaut, « Prise en comptes des ressources multiples et des temps de préparation dans les
problèmes d’ordonnancement en temps réel », Thèse de doctorat de l’Université Paul Sabatier, Toulouse,
décembre 1993.
[Bitton 1990] M. Bitton, « Ecograi : méthode de conception et d’implantation de systèmes de mesure de
performances pour organisations industrielles », Thèse de doctorat en Automatique, Université de Bordeaux
I, septembre 1990.
[Boukachour 1992] J. Boukachour, « Ordonnancement d’atelier par simulation – une approche orientée
objet », Thèse de doctorat en Informatique, Université de Rouen, mai 1992.
[Bourey 1993] J.-P. Bourey, « Méthodes de conception de la commande des systèmes flexibles de production
manufacturière », Habilitation à Diriger des Recherches, Université de Lille, février 1993.
[Breuil 1984] A. D. Breuil, « Outils de conception et de décision dans les organisations de gestion de
production », Thèse d’État en Sciences, Université de Bordeaux, 1984.
[Briand 1995] C. Briand, « Conception orientée-objet et basée réseaux de petri de la conduite temps réel des
systèmes flexibles de production manufacturière », Thèse de doctorat en Informatique Industrielle, Université
Paul Sabatier de Toulouse, janvier 1995.
[Carbone 1994] P. Carbone, « Intégration des plans d’expériences et des systèmes experts à la simulation »,
DEA d’automatique industrielle, Université de Savoie, juillet 1994.
[Carré 1989] B. Carré, « Méthodologie orientée objet pour la représentation de connaissances : concepts de
point de vue, de représentation multiple et évolutive d’objet », Thèse de doctorat de l’université des sciences
et techniques de Lille Flandres Artois, janvier 1989.
[Caux 1993] C. Caux, « Analyse et spécification de systèmes de production pour l’évaluation des performances
et la recherche d’ordonnancement », Thèse de doctorat de l’université de Clermont Ferrand, 1993.
[Dallery 1985] Y. Dallery, « Les méthodes analytiques : un outil complémentaire de la simulation », Thèse de
doctorat de l’INP de Grenoble, 1985.
[Dindeleux 1992] E. Dindeleux, « Proposition d’un modèle et d’un système interactif d’aide à la décision pour
la conduite d’atelier », Thèse de doctorat de l’université de Valenciennes, janvier 1992.
[Dindeleux 1998] R. Dindeleux, « Propilot : une contribution à la modélisation des processus industriels »,
Thèse de doctorat en Électronique – Électrotechnique – Automatique, Université de Savoie, décembre 1998.
[Doumeingts 1984] G. Doumeingts, « Méthode GRAI : méthode de conception des systèmes en productique »,
Thèse d’état de l’université de Bordeaux I, 1984.
&
- / 0 1 2 ) 3
[Elkhattabi 1993] S. Elkhattabi, « Intégration de la surveillance de bas niveau dans la conception des systèmes
à événements discrets : application aux systèmes de production flexible », Thèse de doctorat de l’université
de Lille, 1993.
[Guetari 1995] R. Guetari, « Conception orientée objet de systèmes d’information et de décision », Thèse de
doctorat en Informatique, Université de Savoie, juillet 1995.
[Iung 1992] B. Iung, « Intelligence distribuée dans les processus industriels complexes », Thèse de doctorat de
l’université de Nancy I, janvier 1992.
[Kallel 1985] G. Kallel, « Proposition d’une conduite décentralisée coordonnée (CODECO) pour un atelier de
fabrication », Thèse de doctorat en Automatique, INP de Grenoble, juin 1985.
[Labrune 1993] C. Labrune, « Influence de la taille des lots sur la production d’un atelier fonctionnel », DEA
en automatique industrielle, Université de Savoie, 1993.
[Lenclud 1993] T. Lenclud, « Contribution à la conception d’un système intégré de simulation des systèmes de
production », Thèse de doctorat en Automatique et Informatique Humaine, Université de Valenciennes et du
Hainaut-Cambrésis, novembre 1993.
[Long 1993] J. Long, « Sur la conduite hiérarchisée des systèmes flexibles de production », Thèse de doctorat de
l’INP de Grenoble, juin 1993.
[Mébarki 1995] N. Mébarki, « Une approche d’ordonnancement temps réel basée sur la sélection dynamique
de règles de priorité », Thèse de doctorat de l’université Claude Bernard Lyon I, 1995.
[Nagi 1991] G. Nagi, « Design and operation of hierarchical production manufacturing systems », PhD. Thesis
Report, University of Maryland, USA, 1991.
[Oquendo 1995] F.S. Oquendo, « Une approche formelle des environnements de génie logiciel assisté par
ordinateur : de la gestion des objets à l’automatisation des processus logiciels », Habilitation à Diriger des
Recherches en Informatique, Université Joseph Fourier, Grenoble I, 1995.
[Pierreval 1987] H. Pierreval, « Analyse, modélisation et simulation des systèmes de production – application
au cas d’une fonderie », Thèse de doctorat de l’université Claude Bernard, Lyon, 1987.
[Roy 1998] D. Roy, « Une architecture hiérarchisée multi-agents pour le pilotage réactif d’ateliers de
production », Thèse de doctorat en Automatique-Productique, Université de Metz, janvier 1998.
[Sénéclauze 1995] P. Sénéclauze, « Intégration informatique des plans d’expériences à la simulation », DEA
Génie Industrielle, ENSGI – INP Grenoble, octobre 1995.
[Serin et al. 1996] F. Serin, L. Villefranche, « Simulateur de gestion d’un terminal à conteneurs – simulation
discrète par macro-processus et processus complémentaires », Thèses de doctorat en Informatique,
Université de Rouen, janvier 1996.
[Tahon 1992] C. Tahon, « Systèmes d’aide à la décision pour la conduite des systèmes de production »,
Habilitation à Diriger des Recherches de l’université de Valenciennes, janvier 1992.
[Trad 1996] H. Trad, « Un environnement de pilotage dirigé par les objectifs pour les applications robotiques
manufacturières », Thèse de doctorat en Electronique-Electrotechnique-Automatique, Université de Savoie,
décembre 1996.
[Trentesaux 1996] D. Trentesaux, « Conception d’un système de pilotage distribué, supervisé et multicritère
pour les systèmes automatisés de production », Thèse de doctorat en Automatique-Productique, INP
Grenoble, janvier 1996.
[Youssef 1998] A. Youssef, « Architecture distribuée muli-experts avec contrôle hiérarchique pour le pilotage
des systèmes de production », Thèse de doctorat en Productique Automatisée, Université de Metz, juin 1998.
5. RAPPORTS
[André et al. 1993] C. André, M.A. Péraldi, « Simulation of temporal behaviour based on a synchronous
language », CNRS – URA 1376, Technical Report, No. 93-54, June 1993.
[Cohen et al. 1983] G. Cohen, D. Dubois, « Analyse du comportement périodique de systèmes de production par
la théorie des dioïdes », Rapport de recherche INRIA, No. 191, 1983.
!
- / 0 1 2 ) 3
[Kay et al. 1976] A. Kay, A. Goldberg, « Smalltalk-72 instruction manual », Technical report SSL-76-6, Xerox
PARC, Palo Alto, California, 1976.
"
- / 0 1 2 ) 3
&$
&#
3
Nous joignons dans cette dernière partie du mémoire un certain nombre d’articles sélectionnés
parmi l’ensemble de nos publications de manière à montrer : la nature de l’action qui a mené à
cette publication, le cadre dans lequel l’article a été publié, la continuité de travail réalisé par
des actions diverses.
• L’article (1) publié en 1992 dans la revue internationale SIMULATION est le résultat d’un
travail collectif et une validation du projet réalisé entre le LLP/CESALP, le LGIS et la
société CELLIER.
• Les articles (2) et (3) présentés dans 2 conférences (IEEE SMC’94 et SCSC’95) sont le
résultat du travail d’encadrement de la thèse de M. Bakalem. Ces 2 articles ne reportent
qu’une partie des travaux développés dans cette thèse.
• L’article (4) publié en 1995 dans la revue internationale SIMPRA et l’article (5) présenté à
la conférence SMC’96 sont le résultat de travaux d’encadrement dans le cadre de DEA.
• Les articles (6) et (7) publiés respectivement à la conférence DSI’99 et dans la revue
RFGI en 1999 sont une partie des résultats des travaux encadrés dans le cadre de la thèse
de C. Berchet.
• Les articles (8), (9) et (10) sont le résultat d’un travail personnel. L’article (8) est le
résultat d’une étude sur l’influence de la variabilité des temps de processus présenté à la
conférence ASTC’98. L’article (9) est un éditorial d’un numéro spécial de SIMPRA publié
en décembre 2000. L’article (10) portant sur le développement d’une nouvelle méthode de
modélisation de la fiabilité dans le cas des essais suspendus, est accepté pour être publié
dans la revue IJQRM.
4
Liste des articles joints :
(1) G. HABCHI and F. DELOULE

Study of Modeling and Simulation for a Chemical Production System.
Simulation, Vol. 58, Number 6, June 1992, pp. 366-374. Simulation Councils, Inc. Society for
Computer Simulation International, California, USA.
(2) M. BAKALEM, G. HABCHI and A. COURTOIS

PPS: An Integrated Object Approach for Modeling and Simulation of Manufacturing Systems.
IEEE, SMC’94 International Conference on Systems, Man and Cybernetics, San Antonio,
Texas, USA, October 2-5, 1994, pp. 2184-2189.
(3) M. BAKALEM, G. HABCHI and A. COURTOIS

PPS: A Contribution for Manufacturing Systems Simulation.
SCSC’95, 1995 Summer Computer Simulation Conference, Ottawa, Ontario, CANADA, July
24-26, 1995, pp. 390-395.
(4) G. HABCHI and C. LABRUNE

Study of Lot Sizes on Job-Shop Systems Performance Using Simulation.
Simulation Practice and Theory Journal, Elsevier, 2 (1995) pp. 277-289.
(5) G. HABCHI and P. SENECLAUZE

Computer Integration of Fractional Experimental Designs and Job Shop System Simulation.
SMC’96 SIMULATION MULTICONFERENCE, New Orleans, Louisiana, USA, April 8-11,
1996, pp. 117-122.
(6) G. HABCHI and C. BERCHET

Some Concepts for Industrial Control Process Modelling.
DSI’99, 5th International Conference, Athens - Greece, July 4-7, 1999, Volume I, pp. 777-779.
(7) G. HABCHI et C. BERCHET

Le Pilotage Industriel : Concepts de Base pour une Approche Intégrée.
RFGI, Revue Française de Gestion Industrielle, Vol. 18, N° 2, 1999, pp. 55-72.
(8) G. HABCHI
Study of the Effects of Process Time Variability on the Production Flow of a Manufacturing
System.
ASTC’98, 1998 Advanced Simulation Technologies Conference, Boston, USA, April 5-9,
1998, pp. 221-226.
(9) G. HABCHI
Modelling and Simulation of Complex Production Systems.
Editorial, Special Issue of SIMPRA, vol. 8, n° 5, December 2000.
Guest Editor – Selected Papers from the 2nd French Conference on MOdelling and SIMulation
(MOSIM'99).
(10) G. HABCHI
An Improved Method of Reliability Assessment from Suspended Tests.
Article proposé et accepté pour publication dans la revue internationale IJQRM –
International Journal of Quality & Reliability Management.
- 174

Georges Habchi: Document de Synthèse

Transféré par

Droits d'auteur :

Formats disponibles

Georges Habchi: Document de Synthèse

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Georges Habchi: Document de Synthèse

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITE DE SAVOIE

L’HABILITATION A DIRIGER DES RECHERCHES

Date de soutenance : 5 décembre 2001

M. Pierre LADET (Président jury) Professeur à l’INP de Grenoble

LLP/CESALP – ESIA – Université de Savoie – BP 806 – Annecy Cedex

5. Etat de l’art actuel de la simulation dans les SdPs 64

4. Modélisation Orientee Objet du réseau STP/CP 129

• d’abord, un curriculum vitæ et une synthèse d’activités succincte,

La troisième partie propose de présenter, à travers quelques publications sélectionnées, un

Nom et prénom : HABCHI Georges

1981 MAITRISE DE TECHNOLOGIE DE CONSTRUCTION

1983 DIPLÔME D'INGÉNIEUR

1992 CPIM de L’APICS

d’octobre 1986 à septembre 1988 :

Assistant Associé au département « Génie Mécanique et Productique »

depuis octobre 1988 :

Maître de Conférences au département « Organisation et Génie de la Production »

1.1. Actions à des fins pédagogiques

Année Manifestation Objectifs

2000 Journées pédagogiques nationales du Réflexions sur la mise en place

Année Matière enseignée Etablissement et niveau Nature des

1.3. Enseignements assurés depuis octobre 1988

Ainsi, mes diverses activités pédagogiques et administratives (définition des programmes,

Outre la mise en place des enseignements fondamentaux inhérents à ma formation

• La modélisation et la simulation des SdPs peuvent être définies comme étant « un

Le tableau ci-après résume les enseignements dispensés jusqu’à ce jour.

Un encadrement permanent d’étudiants en stages en entreprises et en projets scientifiques ou

2. ACTIVITES DE RECHERCHE ET D’ENCADREMENT

2.1.1. La fissuration de solidification (mars 1982 – septembre 1986)

2.1.2. La plasticité dynamique (octobre 1986 – septembre 1988)

Au Laboratoire FORSEM (Laboratoire de FORmage Sans Enlèvement de Matière), les

2.1.3. La modélisation et la simulation des SdPs (depuis octobre 1988)

La simulation est principalement une technique d’optimisation et d’aide à la prise de décision.

Après la restructuration des équipes du LLP/CESALP en 1999, « la modélisation et la

La valorisation de nos recherches dans le milieu industriel s'effectue par :

• une participation au projet SIMPROD – SIMulation en PRODuction pour optimiser le

• une collaboration universitaire autour du thème de la simulation avec le Laboratoire de

2.2. Activités d’encadrement

2.2.1. Encadrements et co-encadrements de DEA

2.2.1.1. La fissuration de solidification (octobre 1983 – septembre 1986)

Co-encadrement avec le professeur S.K. MARYA et participation aux jurys de 2 DEA.

Année Sujet DEA Laboratoire d’accueil

2.2.1.2. La plasticité dynamique (octobre 1986 – septembre 1988)

Co-encadrement avec le professeur Maurice LEROY et participation au jury d’1 DEA.

Année Nom Sujet DEA Laboratoire d’accueil

Encadrement et participation à des jurys de DEA :

Année Nom Sujet DEA Laboratoire d’accueil

1994/95 Philippe Une démarche d’intégration des plans LLP/CESALP – ESIA

1995/96 Prève L’intégration informatique des plans LLP/CESALP – ESIA

1997/98 Claire La conception d’un système LLP/CESALP – ESIA

2000/01 Jean-Noël Modélisation avec UML et LLP/CESALP – ESIA

2001/02 Laetitia Recherche d’une méthodologie de LLP/CESALP – ESIA

2001/02 Benjamin Modélisation avec UML et LLP/CESALP – ESIA

Participation à des jurys de DEA :

Année Nom Sujet DEA Laboratoire d’accueil

1995/96 Tarek Utilisation du fonctionnement LAMII/CESALP –

Année Nom Sujet de thèse – date de soutenance – Laboratoire d’accueil

1997 - Claire Sujet : modélisation pour la simulation LLP/CESALP – INP

M. Bakalem est depuis septembre 1996 enseignant chercheur à Alger.