Arena Cour Avec Exemple

Simulation Modeling
and
Analysis with Arena
This page intentionally left blank
Simulation Modeling
and
Analysis with Arena
Tayfur Altiok
Rutgers University
Piscataway, New Jersey
Benjamin Melamed
Rutgers University
Piscataway, New Jersey
AMSTERDAM • BOSTON • HEIDELBERG • LONDON

NEW YORK • OXFORD • PARIS • SAN DIEGO
SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO
Academic Press is an imprint of Elsevier
Chapter 11
Modélisation des lignes de production

Dans de nombreux secteurs industriels, les installations de fabrication sont
structurées en une série d'étapes de production. étapes de production. Les
travaux, sous diverses formes, sont transférés d'une étape à l'autre pour être
traités dans un ordre déterminé. d'une étape à l'autre pour être traitées dans un
ordre prescrit ; ces tâches quittent finalement le système sous forme de produits
finis ou semi-finis. produits finis ou semi-finis. Ces systèmes sont appelés lignes
de production.
La flexibilité offerte par les machines commandées par ordinateur permet aux
lignes de production de traiter un large éventail d'opérations. de gérer un large
éventail d'opérations. Diverses opérations permettent le déploiement d'une
séquence de postes de travail intelligents sur la ligne de production. séquence de
postes de travail intelligents dans l'atelier pour le traitement ou l'assemblage de
divers produits. divers produits. Ce chapitre traite de la modélisation de la
simulation des séquences de postes de travail dans le contexte d'une ligne de
production.
11.1 LIGNES DE PRODUCTION
Considérons la représentation d'une installation de fabrication générique

décrite sous une forme plutôt abstraite dans la figure 11.1. L'installation de
fabrication est une ligne de production composée d'étapes de fabrication
constituées de postes de travail avec des tampons intermédiaires pour retenir les
produits qui circulent le long de la ligne. Chaque poste de travail contient une ou
plusieurs machines, un ou plusieurs opérateurs (éventuellement des robots) et
une mémoire tampon pour les travaux en cours (WIP). Lorsque le processus est
terminé à un poste de travail, les travaux qui partent rejoignent la mémoire
tampon des travaux en cours au poste de travail suivant, à condition qu'il y ait de
la place disponible ; dans le cas contraire, ces travaux sont généralement
conservés au poste de travail actuel jusqu'à ce que de la place se libère dans la
mémoire tampon suivante.
De nombreux modèles pratiques peuvent être formulés comme des variantes
de la chaîne de production générique de la figure 11.1, ou avec des particularités
supplémentaires. Par exemple, un modèle peut nécessiter une ou plusieurs
répétitions d'un certain processus ou d'un ensemble de processus, ou certains
postes de travail peuvent traiter des travaux par lots. Dans d'autres cas, le
transfert des travaux d'un poste de travail à l'autre est d'une importance capitale,
de sorte que le transport par véhicules ou convoyeurs est modélisé de manière
assez détaillée (voir le chapitre 13 pour un traitement approfondi de ce sujet).
Finalement, les tâches quittent le système et ces départs peuvent se produire, en
principe, à partir de n'importe quel poste de travail. En général, les chaînes de
production utilisent un régime de poussée, dans lequel peu d'attention est
accordée à l'inventaire des produits finis. La chaîne de fabrication se contente de
produire (pousser) autant de produits que possible en partant du principe que
tous les produits finis seront utilisés. Dans le cas contraire, lorsque
l'accumulation de produits finis
Simulation Modeling and Analysis with Arena
Copyright 2007 by Academic Press, Inc. All rights of reproduction in any form reserved. 223
224
Operator
Incoming material storage
...
Outgoin
g
material
Machinery
storage
Workstation 2 Workstation K
Workstation 1
Figure 11.1 A generic production line.
Si la production devient excessive, la chaîne de fabrication peut cesser de

produire, auquel cas le régime "push" est remplacé par un régime "pull" (le
processus ne produit qu'en réponse à des demandes spécifiques ; voir les
exemples au chapitre 12). Les systèmes de fabrication de type "push" et "pull"
sont étudiés en détail dans Altiok (1997) et Buzacott et Shanthikumar (1993).
Plus généralement, les limitations de stockage dans les postes de travail donnent
lieu à un phénomène de goulot d'étranglement, impliquant à la fois le blocage et
la famine. Les sources de ce phénomène sont les limitations d'espace et les
considérations de coût, qui imposent des niveaux cibles explicites ou implicites
pour le stockage entre les étapes d'une production.
Explicites ou implicites pour le stockage entre les étapes d'une chaîne de
production. Les limitations d'espace (tampons finis) dans un poste de travail en
aval peuvent donc provoquer des arrêts dans les postes de travail en amont - un
phénomène connu sous le nom de blocage. Les politiques de blocage diffèrent
quant au moment exact de l'arrêt. L'une d'entre elles prévoit l'arrêt immédiat du
traitement des nouveaux travaux dans le poste de travail en amont dès que le
poste de travail en aval est bloqué.
Poste de travail en amont dès que la mémoire tampon en aval est pleine. Le
poste de travail en amont est alors contraint de rester inactif jusqu'à ce que le
tampon en aval ait de la place pour un autre travail, après quoi le poste de travail
en amont reprend le traitement. Ce type de blocage est souvent appelé blocage
des communications, car il est courant dans les systèmes de communication
(voir chapitre 14). Une autre politique consiste à traiter le travail suivant, mais à
le conserver (une fois terminé) dans la machine en amont jusqu'à ce que le
tampon en aval puisse accueillir un nouveau travail. Ce type de politique de
blocage est appelé blocage de la production, car il se produit souvent dans le
contexte de la fabrication. Les différents types de mécanismes de blocage sont
examinés en détail dans Perros (1994).
Il est important de comprendre que le blocage a tendance à se propager vers
l'arrière aux postes de travail successifs situés en amont de la ligne de
production. De même, certains postes de travail peuvent être paralysés en raison
de l'absence de flux de travail en provenance des postes de travail situés en
amont. Ce phénomène est appelé famine pour des raisons évidentes. Il est
également important de comprendre que la famine a tendance à se propager vers
les postes de travail successifs situés en aval de la chaîne de production. Le
Modeling Production Lines 225
blocage et l'inanition sont, en fait, les revers d'un phénomène commun et ont
tendance à se produire ensemble - un blocage et une inanition sont les revers
d'un phénomène commun.
Il est possible d'identifier un poste de travail goulot d'étranglement qui sépare

une ligne de production en deux segments, de sorte que les postes de travail
situés en amont subissent des blocages fréquents et que les postes de travail
situés en aval subissent des blocages fréquents. Les postes de travail en amont
subissent des blocages fréquents et les postes de travail en aval sont
fréquemment privés d'énergie.
Un autre type d'inactivité (forcée) dans les lignes de production est causé par les
pannes. Habituellement, un poste de travail en panne est réparé dès que possible
et reprend son fonctionnement une fois la réparation terminée ; les périodes
alternées de fonctionnement et de panne sont appelées respectivement temps de
fonctionnement et temps d'arrêt. . Il est évident qu'un poste de travail défaillant
peut devenir un poste de travail goulot d'étranglement, provoquant le blocage
des postes de travail en amont et la famine des postes de travail en aval.les
postes de travail en aval. En cas de défaillance, il faut concevoir des procédures
pour traiter les travaux interrompus (ceux qui sont en cours de traitement
lorsqu'une défaillance survient). Par exemple, un travail interrompu peut avoir
besoin d'être retraité à partir de zéro ou simplement de reprendre le traitement.
Dans certains cas, cependant, le travail interrompu est simplement rejeté.
226
11.2 MODÈLES DE LIGNES DE PRODUCTION
Des pertes de productivité sont potentiellement encourues chaque fois que

des machines sont inactives (bloquées ou affamées) en raison de pannes ou
de goulets d'étranglement résultant d'une accumulation excessive de stocks
entre les postes de travail. En outre, les chaînes de production sont rarement
déterministes ; leur caractère aléatoire est dû à des temps de traitement
variables, ainsi qu'à des défaillances aléatoires et aux réparations qui
s'ensuivent. Ce caractère aléatoire rend difficile le contrôle de ces systèmes
ou la prévision de leur comportement. Un modèle mathématique ou un
modèle de simulation est alors utilisé pour faire de telles prédictions.
Les problèmes de conception des lignes de production sont principalement
des problèmes d'allocation des ressources. Ces problèmes comprennent
l'allocation de la charge de travail et l'allocation de la capacité tampon pour
un ensemble donné de postes de travail avec les temps de traitement
associés. En général, les problèmes de conception sont assez difficiles à
résoudre dans les systèmes de fabrication. Cela est dû en partie à la nature
combinatoire de ces problèmes.
L'analyse des performances des lignes de production s'efforce d'évaluer
leurs mesures de performance en fonction d'un ensemble de paramètres du
système. Les mesures de performance les plus couramment utilisées sont les
suivantes :
● Débit Niveaux de stocks moyens dans les tampons
● Probabilités de temps d'arrêt
● Probabilités de blocage aux postes de travail goulots d'étranglement
● les temps de passage moyens du système (également appelés délais de
fabrication).
L'utilisation de ces mesures pour analyser les systèmes de fabrication peut
révéler de meilleures conceptions en identifiant les domaines où la perte de
productivité est la plus néfaste. Pour une étude approfondie des problèmes
de conception, de planification et d'ordonnancement dans les systèmes de
production et d'inventaire, voir Altiok (1997), Askin et Standridge (1993),
Buzacott et Shanthikumar (1993), Elsayed et Boucher (1985), Gershwin
(1994), Johnson et Montgomery (1974), et Papadopoulos et al. (1993), parmi
d'autres.
11.3 EXEMPLE : UNE LIGNE DE

CONDITIONNEMENT
Considérons une ligne d'emballage générique pour un produit donné, par
exemple une usine pharmaceutique produisant un médicament emballé, ou
une usine de transformation alimentaire produisant des aliments ou des
boissons emballés. La ligne se compose de postes de travail qui effectuent
les processus de remplissage, de bouchage, d'étiquetage, de scellage et
d'emballage en carton. Les unités de produit individuelles seront simplement
appelées unités.
Nous faisons les hypothèses suivantes
1. Le poste de remplissage a toujours du matériel devant lui, de sorte qu'il ne
souffre jamais de la faim.
2. L'espace tampon entre les postes de travail peut contenir au maximum
cinq unités.
228
3. Un poste de travail est bloqué s'il n'y a pas de place dans le tampon situé
immédiatement en aval (blocage de fabrication).
4. Les temps de traitement pour le remplissage, le bouchage, l'étiquetage, la
fermeture et l'emballage en carton sont respectivement de 6,5, 5, 8, 5 et 6
secondes.
Ces hypothèses font de notre ligne d'emballage une ligne de production à
régime poussé. Pour simplifier les choses, aucun élément aléatoire n'a été
introduit dans le système, c'est-à-dire que notre ligne d'emballage est
déterministe.
Il est intéressant d'élaborer et d'analyser le comportement de la ligne
d'emballage étudiée. Le premier poste de travail (remplissage) pilote le système
en ce sens qu'il alimente en unités tous les postes de travail situés en aval. Il est
clair que l'un des postes de travail de la ligne est le plus lent (s'il y a plusieurs
postes de travail plus lents, nous prenons le premier d'entre eux). Le débit (taux
de production) de ce poste de travail coïncide alors avec le débit de l'ensemble
de la ligne d'emballage. En outre, les postes de travail situés en amont du poste
le plus lent connaîtront une accumulation excessive de stocks d'encours dans
leurs tampons. En revanche, les postes de travail situés en aval du poste le plus
lent auront toujours des tampons d'encours peu occupés ou vides. Ainsi, le poste
de travail le plus lent agit comme un goulot d'étranglement dans notre ligne
d'emballage. Bien entendu, ce comportement est valable pour toute ligne de
production déterministe à régime de poussée.
11.3.1 UN MODÈLE D'ARÈNE

La figure 11.2 illustre un modèle Arena pour la chaîne d'emballage, dans lequel
les modules Arena représentent chaque processus et les unités sont transférées
d'un processus à l'autre. La logique du modèle s'efforce de maintenir un nombre
suffisant d'unités (entités Arena) dans la station de remplissage, de manière à ce
qu'elle reste occupée le plus longtemps possible. Pour atteindre cet objectif, un
total de 30 entités unités sont créées au temps 0, et leur attribut d'heure d'arrivée,
ArrTime, se voit attribuer la valeur actuelle de TNOW dans le module Assign
Arrival Times (Assigner les heures d'arrivée). Ces entités sont rapidement
introduites dans la mémoire tampon du processus de remplissage (toujours au
temps 0). Avant de quitter le système à partir du module Tally, appelé
Interdeparture Time, les entités unitaires ne sont pas éliminées, mais renvoyées
au module Assign Arrival Times. Notez bien qu'il s'agit simplement d'un
dispositif de modélisation destiné à éviter la famine dans la station de
remplissage, conformément à la première hypothèse ci-dessus. En commençant
par le processus de remplissage, les entités unitaires passent par les modules
associés aux processus de remplissage, de bouchage, d'étiquetage, de scellage et
d'emballage dans cet ordre, et passent enfin aux modules de collecte des
statistiques. La logique du modèle sera examinée en détail dans la section
suivante.
11.3.1MODULES-DE-PROCÉDÉ-DE
FABRICATION
Chaque processus de la chaîne de production est modélisé dans la figure 11.2 par
un module Process du panneau de modèle Basic Process. Chaque processus a été
déclaré comme ayant une file d'attente devant lui, comme le montrent les
graphiques de la barre en T de la figure 11.2. Rappelons que les paramètres de la
file d'attente peuvent être examinés sous forme de feuille de calcul dans le
module File d'attente du panneau de modèle de processus de base. A titre
d'exemple, considérons le module de processus appelé Processus de remplissage,
dont la boîte de dialogue est affichée à la figure 11.3. Ce module de processus
possède une file d'attente appelée Processus de remplissage. Cette file d'attente se
trouve devant une ressource appelée Remplisseur. Le champ Action de la boîte
de dialogue Processus de remplissage est Saisir le délai, de sorte que les entités
unitaires attendent dans la file d'attente Processus de remplissage.File d'attente
chaque fois que la ressource Remplisseur est occupée. Dès que la ressource
Remplisseur devient disponible, elle est
230
Figure 11.2 Arena model for the packaging line system.
saisi par la première entité unitaire (le cas échéant) dans la file d'attente Filling
Process.Queue, et un délai de traitement de 6,5 secondes est alors mis en œuvre dans
le bloc DELAY associé.
Une fois le traitement terminé, l'entité unitaire passe au module de mise en
attente suivant, appelé Filler Blocked, qui met en œuvre le blocage si nécessaire (ce
point est expliqué en détail à la section 11.3.3). Ce n'est que lorsqu'il y a de la place
dans le processus d'écrêtement qui suit le processus de remplissage que l'unité est
autorisée à passer au module de libération, appelé Libération du remplisseur, dans
lequel la ressource Remplisseur est libérée, ce qui termine le processus de
remplissage. En fait, la séquence des modules de traitement, de mise en attente et de
libération est répétée pour chacun des quatre premiers processus (le cinquième et
dernier processus, le processus d'emballage, n'est pas bloqué).
11.3.3 BLOCAGE DE MODÈLE À L'AIDE DU

MODULE HOLD
Rappelons que le module Hold est utilisé pour conserver des entités dans une
file d'attente associée jusqu'à ce qu'une condition soit remplie ou jusqu'à ce qu'un
événement futur se produise. En particulier, ces modules peuvent être utilisés
pour mettre en œuvre le blocage de la production.
Le modèle Arena de la figure 11.2 utilise quatre modules Hold à cette fin
(observez les graphiques de la barre en T de la file d'attente correspondante dans
la figure 11.2). A titre d'exemple, la Figure 11.4 affiche la boîte de dialogue du
module Hold, appelé Filler Blocked, associé au module Filling Process.
Figure 11.3 Dialog box of the Process module Filling Process.
Le champ Condition de la boîte de dialogue du module Hold a été configuré pour

rechercher la condition suivante :
NQ(Processus de bouchage : File d'attente) < 5 :
En d'autres termes, cette condition vérifie si un espace tampon est
disponible dans le processus de bouchage, l'étape de fabrication qui suit
immédiatement le processus de remplissage. Si cette condition est remplie,
l'entité unitaire correspondante quitte le processus de remplissage et rejoint le
tampon de bouchage.
Dans le cas contraire, cette entité unitaire est bloquée et reste dans le
module Hold, ou plus précisément dans la file d'attente associée (dans notre
exemple, Filler Blocked.Queue) jusqu'à ce que la condition soit remplie. Dès
que l'entité unitaire quitte le module Hold, elle entre dans le module Release,
appelé Release Filler, et rejoint la file d'attente Capping Process.Queue. Il est
clair que la ressource Filler doit être occupée chaque fois qu'une unité réside
dans la file d'attente Filler Blocked.Queue. En outre, comme la capacité de la
ressource Filler a été déclarée comme étant d'une unité, il ne peut y avoir
qu'une seule entité unitaire dans la file d'attente Filler Blocked.Queue à tout
moment. Il s'ensuit que
Pr{NQ(Remplisseur bloqué:File d'attente) > 0¼ Time Filler Blocked:La file d'attente est occupée
= Durée totale de la simulation ,
qui se trouve également être le nombre moyen d'entités unitaires dans Filler
Blocked.Queue. Ce fait sera utilisé ultérieurement pour obtenir des probabilités de
blocage pour n'importe quel processus quelque_processus en définissant
simplement (dans le module Statistique) une statistique persistante dans le temps
pour l'expression NQ(quelque_processus.File d'attente).
232
Figure 11.4 Dialog box of the Hold module associated with the filling process.
Il convient de noter qu'un module de libération suit chaque module de maintien

pour chaque processus. En conséquence, le temps passé par une entité unitaire
dans la file d'attente de blocage du module Hold est mesuré par Arena comme
faisant partie du temps d'occupation des ressources du module Process
précédent. Ce point sera
Nous reviendrons sur ce point à la section 11.3.6 lorsque nous étudierons les
utilisations effectives des processus du modèle.
11.3.4 RESSOURCES ET FILES D'ATTENTE

Rappelons que le module Ressource du panneau de modèle Processus de base
permet d'obtenir une feuille de calcul de toutes les ressources du modèle, comme
illustré à la figure 11.5.
De même, le module File d'attente fournit une feuille de calcul de toutes les files
d'attente du modèle, y compris les files d'attente bloquantes, comme illustré à la
figure 11.6.
Figure 11.5 Dialog spreadsheet of the Resource module.

Figure 11.6 Dialog spreadsheet of the Queue module.
La colonne sous l'en-tête Type de la figure 11.6 est utilisée pour spécifier une
discipline de service pour chaque file d'attente via une option d'un menu
déroulant dans chaque entrée sélectionnée. Les options de discipline de service
sont FIFO, LIFO, Valeur d'attribut la plus basse et Valeur d'attribut la plus
haute. Les deux dernières options sont mises en œuvre à l'aide d'un attribut
particulier des entités unitaires de la file d'attente. Un exemple courant est le
service basé sur la priorité qui utilise un attribut Priority dans les entités. Un
autre exemple est la règle SPT, qui admet en service le travail dont le temps de
traitement est le plus court. Pour mettre en œuvre cette règle, le modélisateur
devrait déclarer un attribut, par exemple Processing_Time, et sélectionner les
options Lowest Attribute Value ou Highest Attribute Value dans la colonne
Type. Cette sélection crée automatiquement une colonne supplémentaire dans la
figure 11.6, intitulée Nom de l'attribut, dans laquelle l'utilisateur saisit le nom de
l'attribut approprié (dans notre cas, Temps_de_traitement). La modélisation
d'une capacité finie pour une file d'attente peut être mise en œuvre de manière
analogue au blocage (voir la section 11.3.3). Les entrées de la colonne sous l'en-
tête Shared sont vérifiées si une file d'attente est partagée par plus d'un module
Seize ou bloc SEIZE.
11.3.5 COLLECTE DE STATISTIQUES

La figure 11.7 affiche la boîte de dialogue du module d'enregistrement, appelée
Tally Flow Time, qui calcule le temps écoulé depuis l'heure stockée dans
l'attribut ArrTime de l'entité unité. En particulier, si ArrTime est un attribut
d'entité unitaire qui stocke son heure d'arrivée dans le système et que le champ
Type est défini sur l'option Intervalle de temps, et si les entités unitaires sortent
du module d'enregistrement Tally Flow Time pour être éliminées, ce module
d'enregistrement comptabilisera les temps de passage des entités unitaires dans
le système.
La figure 11.8 affiche la feuille de dialogue du module Statistic spreadsheet pour
le modèle de ligne d'emballage. Les lignes 1 à 4 et la ligne 9 recueillent des
statistiques de fréquence (estimations de probabilité en régime permanent) pour
les états des ressources de remplissage, de bouchage, de scellage, d'emballage et
d'étiquetage, respectivement. La probabilité de tout événement prescrit peut être
234
spécifiée de la même manière par le biais d'une expression, à condition que le
champ Type soit défini sur l'option Persistant dans le temps. Par exemple, la
probabilité que la file d'attente de la ressource de remplissage ait deux tâches ou
plus dans sa mémoire tampon peut être spécifiée par l'expression.
Figure 11.7 Dialog box of the Record module Tally Flow Time.
NQ (Filling_ R_Q) >¼ 2:
La ligne 5 recueille une statistique de type Output spécifiée par une expression
qui définit la réciproque de la moyenne temporelle de la variable, appelée
Interdeparture Time, qui calcule les temps d'inter-départ des entités unitaires du
système. Si l'on se souvient que l'expression est calculée après la fin de la
réplication, il s'ensuit que cette statistique de sortie fournit une estimation du
débit du système.
Enfin, les lignes 6 à 10 recueillent les probabilités de blocage des processus de
remplissage, de bouchage, de scellage et d'étiquetage, respectivement (rappelons
que le processus d'emballage ne connaît pas de blocage). Notez que chaque
expression associée recueille une moyenne temporelle de la taille de la file
d'attente de blocage dans le module Hold correspondant. Comme chaque file
d'attente ne peut contenir qu'un seul travail, la moyenne temporelle calculée est
simplement la probabilité de blocage correspondante.
11.3.6 RAPPORTS DE SORTIE DE

SIMULATION :
Le modèle de ligne d'emballage a été simulé pendant 100 000 secondes. La
figure 11.9 affiche le rapport Files d'attente du panneau Rapports pour ce
modèle.
Notez que chaque file d'attente possède des statistiques sur le temps d'attente et
le nombre d'unités en attente, y compris les files d'attente bloquantes des
modules de mise en attente. La file d'attente Filling Process.Queue avait un
maximum de 29 unités (rappelons que des entités de 30 unités y ont été placées
initialement), et une moyenne de 15,64 unités. La file d'attente Capping
Process.Queue était presque pleine la plupart du temps, contenant en moyenne
4,96 unités avec un délai moyen de 39,9 secondes. La file d'attente Labeling
Process.Queue était également pleine la plupart du temps, avec une moyenne de
4,99 unités. En revanche, les files d'attente de scellage et d'emballage étaient
236
vides en permanence. Le rapport sur les files d'attente comprend également des
statistiques sur les files d'attente de mise en attente (blocage). Celles-ci seront
toutefois examinées ultérieurement dans le contexte des probabilités de blocage.
232
Figure 11.8 Dialog spreadsheet of the Statistic module.
Modeling Production Lines

La figure 11.10 affiche le rapport Ressources du panneau Rapports pour le
modèle de ligne d'emballage. La colonne Inst Util du rapport montre que les
ressources Capper, Filler et Labeler sont occupées à 100%. On s'attend à ce que
ce soit le cas pour la ressource Remplisseuse, puisque le système a été conçu de
cette manière. Les ressources Capper et Filler n'ont pas connu d'inactivité, tandis
que les ressources Sealer et Packer ont été occupées à 75 % et 62 %,
respectivement. Le rapport sur les ressources contient d'autres statistiques
détaillées similaires à celles du rapport sur les files d'attente, qui ne sont pas
présentées ici.
La Figure 11.11 affiche le rapport Spécifié par l'utilisateur du panneau Rapports pour le modèle
de ligne d'emballage. Rappelons que ces statistiques sont collectées à la suite de déclarations dans
le fichier
234 Modeling Production Lines
Figure 11.9 Queues report for the packaging line model.
Modules de statistiques et d'enregistrement. La section Tally de la figure 11.11

fournit des statistiques sur le temps d'inter-départ et le temps d'écoulement. Le
temps moyen d'inter-départ pour l'exécution a été estimé à 8 secondes (toutes
les observations ayant la même valeur, 8). Malgré son apparente banalité,
cette statistique contribue à la vérification du modèle de simulation - un sujet
qui sera traité plus en détail à la section 11.4. Le temps d'écoulement moyen
entre le point de remplissage
Figure 11.10 Resources report for the packaging line model.
Le temps de traitement du module Interdeparture Time a été estimé à 239,78

secondes, sur la base de 12 497 observations (départs d'entités unitaires). Les
durées minimales et maximales observées sont respectivement de 30,5 secondes
et 262,5 secondes. Il est à noter que le temps de débit moyen est plus proche de
l'observation maximale que de l'observation minimale, ce qui montre que la
majorité des observations de temps de débit étaient biaisées vers 262,5
secondes.
La section Compteur indique qu'un total de 12 497 départs du système ont été
observés au cours de l'intervalle de réplication.
La section "Time Persistent" fournit des estimations des probabilités de
blocage. Il est évident que le système a connu un blocage important au niveau
du processus de bouchage (le blocage s'est produit 37 % du temps) en raison de
la longueur des délais d'étiquetage. Le blocage au niveau du processus de
bouchage s'est propagé en amont au processus de remplissage, qui connaît un
blocage de 18,7 %.
La section "Output" estime le débit du système à 0,125 unité par seconde
(soit une unité toutes les 8 secondes), ce qui correspond au temps moyen
d'inter-départ dans la section "Tally".
La figure 11.12 affiche les statistiques de fréquences du panneau Rapports pour
la première réplication du modèle de ligne d'emballage. Les statistiques
affichées concernent les probabilités des états occupés et inactifs pour chaque
ressource. Une observation immédiate est que les probabilités d'occupation
estimées pour les ressources Remplisseuse, Etiqueteuse, Emballeuse et
Scelleuse incluent les probabilités de blocage correspondantes, puisqu'une
ressource bloquée n'est pas libérée et est donc considérée comme occupée.
Ainsi, pour estimer l'utilisation effective d'une resource l'utilisation effective
d'une ressource (la fraction de temps pendant laquelle elle effectue un "travail
réel"), sa probabilité de blocage estimée est soustraite de sa probabilité estimée
dans l'état occupé. occupé. Le tableau 11.1 présente l'utilisation effective de
chaque resource du processus.
Figure 11.11 User Specified report for the packaging line model.
Figure 11.12 Frequencies report for the packaging line model.
Table 11.1
Effective process utilization from Filling to Packing
Process Filling Capping Labeling Sealing Packin
g
Utilization 0.813 0.625 0.999 0.625 0.750
11.4 COMPRÉHENSION DU COMPORTEMENT DU

SYSTÈME ET VÉRIFICATION DU MODÈLE :
Le modèle générique de la ligne d'emballage de la section 11.3 peut être
résumé comme une séquence de postes de travail (ou de serveurs) ayant des
temps de traitement fixes par unité de produit et avec des temps de traitement
fixes. De postes de travail (ou de serveurs) ayant des temps de traitement fixes
par unité de produit, à condition que le premier poste de travail ne soit jamais
inactif. La condition que le premier poste de travail ne soit jamais inactif. Ainsi,
le débit du système (taux de production) coïncide avec celui du poste de travail
le plus lent de la séquence. Dans l'exemple de la section 11.3, le poste de travail
d'étiquetage (ressource Etiqueteur) est le plus lent, avec 8 secondes d'unité. Le
plus lent, avec 8 secondes de temps de traitement unitaire. Par conséquent,
l'utilisation du poste d’étiquetage devrait être de 100%, puisque tous les postes
de travail en amont ont des temps de traitement unitaires (fixes) plus courts.
Étant donné que les postes de remplissage et de bouchage sont tous deux plus
rapides que le poste d'étiquetage, le tampon d'étiquetage finira certainement par
se remplir, ce qui bloquer le poste de bouchage et, plus tard, le poste de
remplissage, ce qui donne lieu à des probabilités de blocage importantes. De
remplissage, ce qui donne lieu à des probabilités de blocage significatives dans
ces stations de travail. En outre, chaque
départ du poste d'étiquetage se répercute sur les postes de travail situés en aval
(scellage, et l'emballage de cartons) à l'état d'inactivité, étant donné qu'ils ont
également des temps de traitement plus courts que les postes d'étiquetage. Le
poste d'étiquetage. Par conséquent, les postes d'étiquetage et de scellage ne sont
jamais bloqués. Ne sont jamais bloqués. Par conséquent, une unité de produit
quitte le poste d'étiquetage toutes les 8 secondes - qui est également le temps
d'inter-départ dans les machines en aval - ce qui se traduit par un débit du
système de 1/8 ¼ ¼. Débit du système de 1/8 ¼ 0,125 unités par seconde. En
fait, le débit de chaque poste de travail du système devrait également être de
0,125. En effet, en utilisant l'Eq. 8.7, qui exprime le débit o comme le rapport
entre l'utilisation et le temps de traitement unitaire moyen, le débit du poste de
remplissage est tandis que le débit
du poste de bouchage est
Dans le cadre de la vérification du modèle de simulation, nous vérifions ensuite

que le temps d'écoulement moyen et le nombre moyen d'unités de produit
obéissent à la formule de Little (8.8). et le nombre moyen d'unités de produit
obéissent à la formule de Little (8.8).
Dans la section 11.10. Définissons le sous-système S comme étant la séquence
de processus allant du module du module du processus de remplissage jusqu'au
module du processus d'emballage inclus (le stockage des matières premières en
amont du processus de remplissage est un élément essentiel de la chaîne de
production). (le stockage des matières premières en amont du processus de
remplissage est inclus dans S). Le temps de passage moyen dans le sous-
système S est est mesuré depuis l'arrivée d'une entité unitaire dans la file
d'attente du processus de remplissage jusqu'à l'arrivée de l'entité unitaire dans le
module interdépartemental.
jusqu'à l'arrivée de l'entité unitaire au module Interdeparture Time. La
réplication a estimé ce temps moyen de 239,79 secondes (voir figure 11.10). Le
nombre moyen d'unités dans S, Ns,
est simplement la somme des contenus moyens des tampons correspondants
(voir Figure 11.8) plus le nombre moyen d'unités en S, Ns, est simplement la
somme des contenus moyens des tampons correspondants (voir Figure 11.8)
plus le nombre moyen d'unités en service (temps moyen en état d'occupation ;
voir Figure 11.11), soit
ce qui est proche de la valeur théorique attendue de 30 (notons qu'il s'agit d'un
système fermé avec 30 entités unitaires circulantes). Ainsi, dans ce cas, la
formule de Little devient la relation suivante :
où Ns est le nombre moyen d'unités dans S, o est le débit de S tel que discuté
plus haut
(le débit de S est égal au taux d'arrivée en S en régime permanent), et Fs est le
temps de passage moyen dans S.
temps moyen d'écoulement à travers S. En utilisant le temps moyen
d'écoulement et le débit de la figure 11.11 pour calculer le côté droit de l'Eq.
calculer le côté droit de l'Eq. 11.2, on obtient
Comme les côtés droits des équations 11.1 et 11.3 sont approximativement
les mêmes, ce fait tend à vérifier les estimations de la réplication. à vérifier les
estimations de la réplication. En fait, l'écart entre les équations 11.1 et 11.3
devient progressivement plus faible à mesure que la durée de la réplication
augmente.
Ensuite, nous effectuons une analyse de sensibilité en étudiant l'impact des
capacités des tampons sur le comportement du système. comportement du
système. Cette analyse nous aidera à mieux comprendre le blocage, un
phénomène qui découle de l'inadéquation entre les capacités des tampons et
celles du système. phénomène résultant d'une inadéquation entre les taux de
service et les capacités finies de la mémoire tampon. La figure 11.13 présente
trois mesures de performance en fonction de l'augmentation simultanée des
simultanément dans le processus d'étiquetage et le processus de plafonnement.
De gauche à droite, les
De gauche à droite, les mesures représentées sont le débit de S, le niveau
d'encours au niveau du processus d'étiquetage et le temps de passage moyen à
travers S, à l'exclusion de la capacité de stockage. le temps de passage moyen
dans S, à l'exclusion du tampon de remplissage. (Si les temps de passage
devaient .Si les temps d'écoulement incluaient le temps passé dans le tampon de
remplissage, ils resteraient constants. Pourquoi ?)
Il est intéressant de noter que le débit de S n'est pratiquement pas affecté, tandis
que le niveau moyen de l'encours de production dans le processus d'étiquetage
et le temps de passage moyen dans S augmentent au fur et à mesure que les
capacités des tampons sont augmentées.
augmentent. Pour comprendre ces observations, rappelons que le système étudié
a des temps de traitement fixes.
des temps de traitement fixes. Rappelons également que des tampons sont
placés sur les lignes de production afin de
des temps de traitement fixes. Rappelons également que des tampons sont
placés sur les lignes de production afin d'absorber les fluctuations du flux de
produits dues au caractère aléatoire du système (par exemple, temps de
traitement aléatoires, temps d'arrêt aléatoires, etc). Ces événements introduisent
une variabilité qui tend à ralentir le mouvement des produits. Mais dans les
systèmes sans variabilité (comme le nôtre), l'emplacement des tampons n'aurait
aucun impact sur le flux de produits. l'emplacement des tampons n'aurait aucun
impact sur le débit, comme le montre la figure 11.13(a).
Toutefois, le fait de placer des tampons plus importants en amont des postes
de travail à goulot d'étranglement ne fait que
Cependant, le fait de placer des tampons plus importants en amont des postes de
travail goulots d'étranglement entraîne simplement des niveaux de WIP plus
importants à cet endroit et, par conséquent, des temps de passage plus longs. En
revanche, les tampons aux postes de travail situés en aval du goulot
d'étranglement sont toujours vides, quelle que soit la capacité.
En résumé, notre analyse de sensibilité a révélé des principes de conception
utiles et quelque peu inattendus pour les lignes de production déterministes.
Principes de conception précieux et quelque peu inattendus pour les lignes de
production déterministes, à savoir que des tampons plus grands peuvent en fait
avoir un effet de suppression global. Les tampons plus importants peuvent en
fait avoir un effet délétère sur le système. D'une part, l'augmentation de la taille
des tampons n'augmente pas le débit. D'autre part, de telles augmentations
d'autre part, de telles augmentations se traduiront par des stocks plus importants,
immobilisant ainsi un capital précieux dans les stocks.
Pire encore, les travaux prendraient plus de temps pour traverser le système. Ces
effets peuvent préjudiciables sur le plan économique (pensez à la pénalité que
représente l'allongement des délais de fabrication).
Des tampons de taille raisonnable sont toutefois nécessaires pour absorber les
effets de la variabilité des flux de produits, en présence d'aléas. Dans la section
11.6, nous discuterons de l'effet bénéfique de la mise en place de tampons
lorsque les machines ne sont pas en état de fonctionner.
11.5 MODÉLISATION DES LIGNES DE PRODUCTION PAR

FILES ET RESSOURCES INDEXÉES
INDEXÉES ET DES RESSOURCES :
Lorsque les modèles contiennent des composants dont la logique est

répétitive, la construction du modèle peut devenir fastidieuse et, par conséquent,
sujette à des erreurs. Devenir fastidieuse et, par conséquent, sujette à des
erreurs. Le modèle de la ligne d'emballage de la section 11.3 en est un bon
exemple. D’emballage de la section 11.3, où les processus des composants ont
une logique analogue (bien que les paramètres soient différents). paramètres
soient différents). Plus précisément, dans chaque processus (remplissage,
bouchage, étiquetage, scellage et emballage en carton), les processus sont
analogues, l'étiquetage, le scellement et la mise en carton), les unités saisissent
une ressource, la traitent, vérifient si elle est bloquée, puis la libèrent. S’il y a
blocage, puis libèrent la ressource correspondante. Pour les modèles présentant
une telle logique répétitive, Arena prend en charge une approche efficace,
appelée indexation, qui l'indexation, qui élimine en grande partie l'ennui de la
répétition. Cette approche exploite le fait que chaque objet dans Arena possède
un numéro d'identification entier implicite au sein de sa classe ; des exemples de
classes d'objets comprennent des constructions d'Arena telles que les files
d'attente, les ressources et les expressions. Ainsi, les objets d'une classe peuvent
être considérés comme des tableaux d'objets, où chaque objet se voit attribuer
un index pour l'accès et la manipulation. Pour l'accès et la manipulation. Un
index est un nombre entier qui identifie le numéro de série de l'objet.
Numéro de l'objet dans le tableau, et à ce titre il varie de 1 à la taille du tableau
(le nombre d'objets créés). Nombre d'objets créés). Notez que la taille du tableau
est dynamique et que le modélisateur peut imposer un ordre particulier des
objets dans le tableau pour faciliter la logique d'indexation. À cette fin, le
modélisateur peut utiliser la pour ce faire, le modélisateur peut utiliser les
éléments Queues, Ressources et Expressions du panneau de gabarit éléments,
accessible à partir du bouton Attacher un modèle de la barre d'outils Standard de
la barre d'outils Standard.
Pour illustrer l'utilisation de l'indexation dans la modélisation des composants
répétitifs, nous allons modifier l'exemple de la ligne d'emballage. L’exemple de
la ligne d'emballage de la section 11.3. En exploitant la fonction d'indexation de
l'arène, nous numérotons d'abord toutes les ressources de 1 à 5, toutes les files
d'attente de ressources de 1 à 5, et toutes les files d'attente de blocage de 6 à 10,
puis déclarons ces objets et leur numérotation. Bloquantes de 6 à 10, puis nous
déclarons ces objets et leurs index à l'aide des anciens éléments Arena de
ressources et de files d'attente.
La figure 11.14 illustre la boîte de dialogue de l'élément appelé Queues
élément (à gauche) et la boîte de dialogue associée à une file d'attente
particulière (à droite). la boîte de dialogue associée à une file d'attente
particulière (à droite). Initialement, l'élément Queues à gauche est vide. Gauche
est vide. Le modélisateur clique sur le bouton Ajouter pour faire apparaître la
boîte de dialogue de droite afin de définir les attributs de file d'attente pertinents
pour la file d'attente sélectionnée dans le champ Nom (ici Filler Queue). Les
champs les plus importants de la boîte de dialogue Queues sont l'index de la file
d'attente.
L'attribution de numéros d'index spécifiés par l'utilisateur aux ressources est
similaire. La figure 11.15 illustre la boîte de dialogue de l'élément appelé
Élément Ressources (en haut) et la boîte de dialogue associée à une ressource
particulière (en bas). Associée à une ressource particulière (en bas). Notez que
la boîte de dialogue Ressources est pratique pour spécifier des informations
supplémentaires pour une ressource (dans ce cas, la ressource Filler). Outre
l'index et le nom de la ressource, le modélisateur peut utiliser le champ Capacité
ou Calendrier pour saisir une ressource statique. Pour saisir soit une capacité
statique de la ressource, soit un nom de programme régissant une capacité
dynamique en fonction du temps. une capacité dynamique dépendant du temps.
Dans la figure 11.15, nous utilisons la boîte de dialogue Ressources simplement
pour attribuer un numéro d'index à la ressource Filler. Dans le tableau des files
d'attente de l'Arène (spécifié dans le champ Numéro), et la discipline de la file
d'attente (spécifiée dans le champ Classement). file d'attente (spécifiée dans le
champ Critère de classement). En outre, le modélisateur peut sélectionner l'un
des deux types de spécifications dans le champ Associated Block : soit spécifier
un bloc (SIMAN) avec lequel la file d'attente actuelle sera reliée. Avec lequel la
file d'attente actuelle sera associée, soit saisir le mot-clé shared, signalant ainsi
que la file d'attente sera utilisée dans plusieurs modules de mise en attente et de
saisie.
Figure 11.14: Dialog boxes of Queues Element (left) and Queues (right).
Figure 11.15: Dialog boxes of Resources Element (top) and Resources

(bottom).
Enfin, l'indexation des expressions Arena dans la ligne d'emballage est

illustrée dans la Figure 11.16, qui représente la boîte de dialogue de l'élément
appelé Expressions élément (à gauche) et la boîte de dialogue associée à une
expression particulière (à droite). Les tableaux d'expressions peuvent être des
vecteurs (unidimensionnels) ou des matrices (bidimensionnelles). Pour spécifier
un vecteur, l'utilisateur Pour spécifier un vecteur, l'utilisateur saisit sa dimension
dans le champ Index du tableau à une dimension. De même, pour spécifier une
matrice, l'utilisateur l'utilisateur saisit ses dimensions dans les champs 1-D
Array Index et 2-D Array Index. Les éléments du tableau d'expressions sont
saisis dans l'ordre, colonne par colonne, une expression par ligne. Expression
par ligne. Ici, les expressions saisies sont des constantes qui spécifient les temps
de traitement et les capacités de la mémoire tampon.
La version équivalente du modèle Arena de la section 11.3, modifiée pour
incorporer l'indexation, est illustrée à la figure 11.17. L’indexation, est illustrée
à la figure 11.17, où toutes les files d'attente, expressions et ressources indexées
sont présentées dans cet ordre sous les en-têtes correspondants du côté droit.
Ressources sont présentées dans cet ordre sous les titres correspondants sur le
côté droit de la figure. Droite de la figure. En commençant par le coin supérieur
gauche, le module Cérate, appelé Cérate Jobs, fonctionne exactement comme le
module Cérate 1, son homologue de la figure 11.2 (les "emplois" auxquels il est
fait allusion sont, bien entendu, des unités de produit).
Figure 11.16: Dialog boxes of Expressions Element (left) and Expressions

(right).
Ce module génère 30 entités unitaires au temps 0, qui circulent à plusieurs

reprises dans le modèle. Cependant, la logique d'acheminement des unités de
produit à travers les postes de travail de la ligne d'emballage est implémentée
dans le modèle. Les postes de travail de la ligne d'emballage est mise en œuvre
d'une manière analogue à une boucle dans un langage de programmation
procédural. langage de programmation procédural. Dans notre cas, l'attribut
Proc_Index de l'entité unité assure le suivi de l'indice d'exécution de la boucle.
Lorsqu'une entité d'unité émerge du module Cérate Jobs, elle passe au module
Assign
appelé Assign Process Index and Time, où son attribut Proc_Index est initialisé
à 1 (ainsi que l'enregistrement du temps de simulation actuel dans l'attribut
Arr_Time pour la simulation).
Figure 11.17 : Modèle d'arène avec indexation pour le système de la ligne

d'emballage.
la collecte ultérieure d'observations sur le temps de passage total (au dernier

poste de travail mettant en œuvre le processus d'emballage). Notez que les
postes de travail de la ligne d'emballage modélisent les ressources Filler,
Capper, Labeler, Sealer, etPacker, et ceux-ci sont indexés par 1, 2, 3, 4, et 5,
respectivement, comme l'indique la liste des ressources sous l'en-tête
Ressources de la figure 11.17.
Les files d'attente de ressources correspondantes sont indexées de la même
manière, comme l'indique la liste des files d'attente sous l'en-tête Queues de la
figure 11.17. Chaque entité de l'unité sera ensuite acheminée à travers la même
séquence de modules, et son attribut Proc_Index sera incrémenté après chaque
itération de manière à correspondre au prochain poste de travail à visiter.
Comme on le verra, la distribution de services appropriée pour chaque
processus de poste de travail sera également sélectionnée par cet attribut.
L'entité unité passe au premier module de la boucle, à savoir le module Seize
appelé Seize Process. La boîte de dialogue de ce module est affichée à la figure
11.18. Ici,
le champ Ressources indique que la ressource à sélectionner pour la saisie est
spécifiée par le numéro d'index courant stocké dans l'attribut Proc_Index
(initialement l'index
est 1, ce qui correspond à la ressource Filler). La boîte de dialogue pour la
ressource courante dans la boucle est illustrée à la Figure 11.19. Notez que dans
cette boîte de dialogue, la ressource appropriée est sélectionnée par attribut
(dans le champ Type) et que le champ Nom de l'attribut spécifie l'attribut.
Après avoir saisi la ressource sélectionnée, l'unité passe au deuxième module
de la boucle, à savoir le module Délai appelé Temps de traitement. La boîte de
dialogue de ce module
est affichée dans la figure 11.20. Ici, le champ Délai indique qu'un délai pour ce
module est la valeur à laquelle la ressource a été sélectionnée. pour ce module
est la valeur à la position d'index actuelle du vecteur d'expression ProcTimes
(rappelons que ce vecteur d'expression
a été initialisé précédemment, comme illustré à la Figure 11.16).
Une fois que l'entité unitaire a terminé son délai et est sortie du module
Temps de traitement son traitement au poste de travail actuel est également
terminé. Elle doit maintenant prendre la décision suivante :
Figure 11.18 : Boîte de dialogue du premier module (Seize) de la boucle.
Figure 11.19 : Boîte de dialogue de la ressource courante dans la boucle.

Figure 11.20 : Boîte de dialogue du deuxième module (Delay) dans la boucle.
Figure 11.21 : Boîte de dialogue du troisième module (Decide) dans la boucle.
Dans ce cas, l'unité procédera au module de libération, appelé Release Last

Process (Libération du dernier processus), pour libérer la dernière ressource, et
entrera dans le module Record (Enregistrement), appelé Flow Time, pour
collecter la prochaine observation du temps d'écoulement du système, avant de
se diriger vers le module Assign, appelé Assign Process Index and Time, pour la
prochaine tournée des cinq postes de travail (traitement d'un nouveau travail).
Toutefois, si Proc_Index < 5 est vrai, l'unité passe au quatrième module de la
boucle, à savoir le module Hold, intitulé See if Le processus est bloqué ; voir la
boîte de dialogue du module à la Figure 11.22. Dans ce module, l'entité unit
vérifie si le poste de travail suivant (indexé par Proc_Indexþ1) est plein (c'est-à-
dire que le transfert vers le processus suivant est bloqué), en vérifiant
l'expression logique dans le champ Condition,
Figure 11.22 : Boîte de dialogue du quatrième module (Hold) de la boucle.
Rappelons que Buffer Caps est un vecteur d'expression contenant les capacités
des tampons, qui ont été préalablement initialisés par le modélisateur. ont été
préalablement initialisées par le modélisateur. Notez bien que les index des files
d'attente bloquantes sont spécifiés par des expressions (champ Queue Type)
dont les valeurs sont données par Proc_Index
+ 5 (champ Expression). Ainsi, ce module Hold est utilisé pour tous les
processus, sauf le
dernier ; il retient une entité unitaire bloquée à la file Proc_index+5 jusqu'à ce
que le poste de travail suivant ait la place de l'accueillir.
Dès que le poste de travail suivant a de la place (c'est-à-dire que le processus
suivant est non bloquant), l'entité de l'unité se déplace vers le cinquième module
de la boucle, c'est-à-dire le module de l'unité de travail à savoir le module
Release, appelé Release Process, pour libérer la ressource actuelle (celle qui est
indexée dans la boucle). L'unité passe ensuite au sixième et dernier module de la
boucle, à savoir le module Assign, appelé Next Process, où l'attribut Proc_Index
de l'entité unitaire est incrémenté. à savoir le module Seize, appelé Seize
Process, pour démarrer la prochaine itération de la boucle.
11.6 : UNE MÉTHODE ALTERNATIVE DE

MODÉLISATION BLOCAGE :
Il existe plusieurs façons de modéliser le blocage dans Arena. Dans l'exemple

de la ligne d'emballage de la section 11.3, nous avons choisi de modéliser le
blocage via le module Hold du panneau de modèle Basic Process. Une autre
solution consisterait à traiter chaque tampon comme une ressource. La figure
11.23 illustre cette approche de modélisation alternative pour un tampon dans le
modèle de ligne d'emballage de la figure 11.2.
Dans la figure 11.23, la ressource du poste de travail d'étiquetage, qui
contrôle le nombre d'unités dans la file d'attente du processus d'étiquetage, est
appelée tampon d'étiquetage. L'entrée Capacity (nombre de serveurs) de cette
ressource est fixée à 5 unités afin de correspondre à une de 5 dans le processus
d'étiquetage. Une implémentation Arena de cette approche de la modélisation du
blocage est décrite dans l'illustration suivante modélisation du blocage est
illustrée à la Figure 11.24.
Figure 11.23 : Feuille de calcul du module Ressources pour la modélisation du

blocage
Figure 11.24 : Modélisation alternative de l'arène de blocage via les modules de

ressources.
Process.Queue, et attend son tour pour s'emparer de la ressource Labeler.
Pendant cette attente, l'entité unitaire conserve son espace unitaire de la
ressource Labeling Buffer, et ne libère cet espace que lorsqu'elle réussit à
s'emparer de la ressource Labeler.
qu'une fois qu'elle a réussi à s'emparer de la ressource Etiquetteur. Puisqu'il n'y
a que cinq unités de ressources disponibles pour la saisie dans le tampon
d'étiquetage, il y aura au plus cinq entités unitaires dans le tampon "physique"
d'étiquetage.
Notez que cette approche de la modélisation du blocage dans Arena est plus
coûteuse que celle utilisée dans la modélisation de la ligne d'emballage dans la
section 11.3. Dans ce cas, un seul module (Hold) a été utilisé pour modéliser le
blocage par processus.
pour modéliser le blocage par processus, alors qu'ici trois modules (Seize,
Release et
Resource) sont utilisés dans le même but. Cette complexité accrue peut devenir
problématique. Par exemple, la version étudiante d'Arena ne permet d'utiliser
qu'un nombre limité de modules dans un processus donné.
11.7 : MODÉLISATION DES DÉFAILLANCES DES
MACHINES :
Les arrêts de processus sont inévitables dans les systèmes de fabrication et de
services. En particulier, les pannes de machines de toutes sortes constituent une
source importante d'inactivité et de variabilité dans ces systèmes. Lorsqu'il
modélise des systèmes sujets à des défaillances, le modélisateur s'intéresse
généralement aux probabilités à long terme des arrêts de production.
Certainement, efficace exige que les temps d'arrêt soient réduits au minimum,
puisqu'ils représentent une perte de temps de production. La simulation peut
aider le modélisateur à comprendre l'impact des défaillances sur les
performances du système.
Un processus stochastique qui modélise les défaillances est caractérisé soit par
les propriétés statistiques des intervalles de temps séparant des défaillances
consécutives, soit par le processus de comptage qui suit le nombre de
défaillances. Ces deux caractérisations sont mathématiquement équivalentes.
Cependant, la première caractérisation est couramment utilisée pour générer
des échecs dans les simulations. En fait, les défaillances peuvent être comme un
processus d'arrivée spécialisé de haute priorité, dont les transactions préemptent
simplement le serveur.
Un scénario de panne typique sur un poste de travail unique se déroule comme
suit. Après une période de fonctionnement normal (uptime), une panne survient,
le poste de travail arrête son traitement, et subit ensuite un temps d'arrêt pendant
la réparation.
Le délai de mise en place de la réparation doit être modélisé, mais ce délai
peut généralement être absorbé dans un temps de réparation plus long. Les
défaillances qui se produisent lorsque les machines sont en train de traiter des
tâches sont appelées "dépendantes des opérations".
Cependant, la nouvelle génération de machines hautement informatisées peut
tomber en panne à tout moment, quel que soit l'état de la machine. Ces pannes
sont dites indépendantes de l'opération. et peuvent inclure des
dysfonctionnements de la machine, des démarrages, des nettoyages, des
ajustements et d'autres retards spécifiques à un système particulier, et d'autres
retards spécifiques à un système particulier. Les deux états fondamentaux de la
machine.
PANNES DE LA MACHINE À MODÉLISER :
Les arrêts de processus sont inévitables dans les systèmes de fabrication et de

service. En particulier, les pannes de machines de toutes sortes constituent une
source importante d'inactivité et de variabilité dans un tel système. Lors de la
modélisation de systèmes sujets à des défaillances, le modélisateur s'intéresse
généralement aux probabilités à long terme d'états de panne, qui se traduisent
opérationnellement par la fraction de temps à long terme passée dans ces états.
Certes, un fonctionnement efficace nécessite que les temps d'arrêt soient
minimisés, car ceux-ci représentent une perte de temps de production. La
simulation peut aider le modélisateur à comprendre l’impact des pannes sur les
performances du système.
Un processus stochastique qui modélise les pannes est caractérisé soit par les
propriétés statistiques des intervalles de temps séparant les pannes consécutives,
soit par le processus de comptage qui permet de suivre le nombre de pannes sur
une période donnée. Ces deux caractérisations sont mathématiquement
équivalentes. Cependant, la première caractérisation est couramment utilisée
pour générer des échecs dans les simulations. En fait, les échecs peuvent être
modélisés comme un processus d’arrivée spécialisé de haute priorité, dont les
transactions préemptent simplement le serveur.
Un scénario de défaillance typique sur un seul poste de travail se déroule
comme suit. Après une période de fonctionnement normal (up time), un
événement de panne se produit, le poste de travail arrête son traitement, puis
subit un temps d'arrêt lors d'une réparation. (Parfois un supplément le délai de
configuration de la réparation doit être modélisé, mais ce délai peut
généralement être absorbé dans un temps de réparation plus long).
Les pannes qui se produisent pendant que les machines traitent réellement des
tâches sont dites dépendantes de l'opération. Cependant, la nouvelle génération
de machines hautement informatisées peut tomber en panne à tout moment, quel
que soit l'état de la machine. De telles pannes sont dites indépendantes du
fonctionnement et peuvent inclure des dysfonctionnements de la machine, des
démarrages, des nettoyages, des ajustements et d'autres retards spécifiques à un
système particulier. Les deux états fondamentaux de la machine, Inactif et
Occupé, doivent ensuite être complétés par des états de panne et d'arrêt
supplémentaires, tels qu’Arrêt, Nettoyage, Ajustement, etc.
Arena admet n'importe quel nombre d'états définis par l'utilisateur en plus de
ceux intégrés (appelés états automatiques). En particulier, une ressource Arena a
quatre états automatiques : en repos, Occupé, En échec (en panne) et Inactif, et à
tout moment, une ressource se trouve dans l'un de ces états.
Le passage d'un état à un autre est provoqué par l'occurrence d'un événement.
Par exemple, un événement d’échec entraîne automatiquement une transition de
la machine vers l’état Échec. D'un autre côté, les états définis par l'utilisateur et
leurs transitions peuvent être programmés entièrement à la discrétion du
modélisateur. Nous nous intéressons généralement aux probabilités à long terme
de ces états ; ces probabilités peuvent être estimées via l'option Fréquence dans
le module Statistiques.
Le modélisateur peut moduler la capacité d'une ressource dans le temps en
définissant un niveau de capacité variable dans le temps dans le module
Planification (voir Section 5.8 pour plus de détails). En particulier, pour
modéliser les temps d'arrêt forcés (par exemple, maintenance préventive), une
ressource peut être inactivée en définissant sa capacité à zéro, auquel cas l'état
automatique Inactif aura une probabilité non nulle.
Supposons que le processus de remplissage dans le modèle de ligne d'emballage
de la section 11.3 échoue de manière aléatoire et qu'il nécessite un ajustement
tous les 250 départs du poste de travail. Supposons que les temps de
disponibilité (temps entre l'achèvement d'une réparation et la panne suivante, ou
temps jusqu'à la panne) sont distribués de manière exponentielle avec une
moyenne de 50 heures, tandis que les temps de réparation sont uniformément
répartis entre 1,5 heure et 3 heures. Aussi, le temps d'ajustement précité est
uniformément réparti entre 10 minutes et 25 minutes. Supposons en outre que le
processus d'emballage puisse également connaître des pannes mécaniques
aléatoires et que les temps d'arrêt soient répartis de manière triangulaire avec un
minimum de 75 minutes, un maximum de 2 heures et un mode à 90 minutes.
Les temps de disponibilité correspondants sont distribués de manière
exponentielle avec une moyenne de 25 heures. Enfin, supposons que des pannes
aléatoires se produisent uniquement lorsque les machines sont occupées (pannes
dépendantes du fonctionnement). Nous appellerons le modèle de ligne de
conditionnement modifié le modèle modifié en cas de défaillance.
La figure 11.25 illustre comment les échecs dans le modèle modifié par échec
sont spécifiés dans une feuille de calcul de dialogue pour le module Échec du
panneau de modèle de processus avancé. La colonne Nom de la Figure 11.25
spécifie les noms des échecs, tandis que la colonne Type sélectionne le type
d'arrivées d'échecs : Heure (pour les arrivées basées sur l'heure) ou Nombre
(pour les arrivées basées sur le nombre). Par exemple, les pannes mécaniques
aléatoires sont normalement basées sur le temps, puisque leurs arrivées
nécessitent une spécification du temps entre les pannes. En revanche, si une
machine nécessite une action de nettoyage chaque fois qu'elle termine le
traitement d'un nombre prescrit d'unités, l'arrêt du nettoyage est alors basé sur le
nombre. Notez que dans la figure 11.25, la défaillance/arrêt nommé Ajustement
est déclaré basé sur le nombre.
Pour les pannes basées sur le temps, la colonne Temps de disponibilité spécifie
l'intervalle de temps jusqu'à la panne suivante (après l'achèvement d'une
réparation), tandis que la colonne Unités de temps de disponibilité spécifie
l'unité de temps correspondante. De même, pour les échecs basés sur le nombre,
la colonne Nombre spécifie le nombre de départs d'entités vers l'échec suivant
(250 pour l'échec d'ajustement). Notez que les entrées de colonne inutilisées
sont ombrées en fonction du type d'échec.
La colonne Temps d'arrêt spécifie la durée des temps d'arrêt, tandis que la
colonne Unités de temps d'arrêt spécifie l'unité de temps correspondante. Enfin,
la colonne Disponibilité dans cet état uniquement est utilisée pour les pannes
temporelles afin de spécifier l'état dans lequel la ressource doit se trouver pour
que la panne se produise. Par exemple, les pannes temporelles de la figure 11.25
ne peuvent se produire que lorsque les ressources sous-jacentes sont à l'état
Occupé.
Arena fournit un mécanisme pour définir les états des ressources et pour les lier
aux pannes/arrêts sous la forme du module de feuille de calcul StateSet du
panneau de modèle de processus avancé. La figure 11.26 illustre l'utilisation du
module StateSet pour le modèle de ligne de conditionnement de la section 11.3.
La feuille de calcul de la boîte de dialogue de gauche de la figure 11.26 spécifie
un nom d'ensemble d'états (sous la colonne Nom) et le nombre d'états associés
(sous la colonne États). Par exemple, la première ligne spécifie un ensemble
d'états, appelé Filling States, pour la ressource Filler avec 4 états (le bouton
intitulé 4 lignes). Cliquer sur ce bouton fait apparaître la boîte de dialogue à
droite, qui affiche des informations détaillées sur l'état. Là, la colonne State
Name affiche les noms définis par l'utilisateur ou d'état automatique, tandis que
la colonne AutoState ou Failure indique l'association de chaque nom d'état avec
le nom d'état automatique ou d'échec défini par l'utilisateur correspondant.
Enfin, la figure 11.27 illustre pour le modèle modifié par échec comment le
module Resource est utilisé pour associer les états des ressources aux échecs et
l'action à entreprendre en cas d'occurrence d'échec. La feuille de calcul de la
boîte de dialogue inférieure de la figure 11.27 spécifie dans la première ligne
que la ressource Filler (nom de la colonne) a 2 types d'échecs (le bouton intitulé
2 lignes dans la colonne Échecs). En cliquant sur ce bouton, la feuille de calcul
de dialogue apparaît en haut de la figure 11.27, qui montre que la ressource
Filler a deux échecs, appelés Random Failures_F et Ajustement (colonne Nom
de l'échec). La colonne Règle de défaillance spécifie l'action requise à
entreprendre sur l'entité (ou les entités) d'unité en cours de traitement lorsqu'une
défaillance basée sur le temps se produit (elle ne s'applique pas aux défaillances
basées sur le nombre). Les actions sont spécifiées via des options, dont les plus
courantes sont les suivantes :
 L'option Préempter démarre un temps d'arrêt en suspendant la ressource

immédiatement à l'arrivée de l'échec, de sorte que le traitement restant de l'entité
unitaire actuelle reprenne une fois le temps d'arrêt terminé.
 L'option Attendre permet à l'entité d'unité actuelle de terminer le traitement,
après quoi la ressource est suspendue et le temps d'arrêt commence.
 L'option Ignorer démarre le temps d'arrêt une fois le traitement de l'entité d'unité
actuelle terminé. Cependant, seule la partie du temps d'arrêt suivant
l'achèvement de l'entité unité en cours est enregistrée (en revanche, l'option
Attendre enregistre le temps d'arrêt complet).
Dans notre exemple, l'échec Random Failures_F appliquera l'option Preempt,
tandis que l'ajustement des échecs, étant basé sur le nombre, appliquera
formellement l'option Wait, même si toute autre option aurait pu être
sélectionnée (rappelons que les options ne s'appliquent pas aux échecs basés sur
le nombre).
Les probabilités d'état de chaque ressource peuvent être obtenues en demandant la

collecte de statistiques de fréquence dans le module Statistiques avec l'option
État sélectionnée dans sa colonne Type de fréquence. La figure 11.28 affiche le
rapport Fréquences résultant pour le modèle modifié en cas de panne.
Il est instructif de comparer les performances du modèle de ligne de
conditionnement d'origine de la section 11.3 avec sa version modifiée en cas de
panne. Tout le reste étant pareil, nous nous attendons à ce que le modèle
modifié en cas d'échec affiche des performances inférieures à celles du modèle
d'origine.
En effet, une comparaison de la Figure 11.28 à la Figure 11.12 révèle que les
ressources en aval de la ressource Filler dans le modèle modifié par défaillance
révèlent une inactivité nettement accrue. L’explication de ce résultat est simple.
Étant donné que la ressource Filler dans le modèle modifié en cas de panne est
arrêtée par des pannes aléatoires, elle ne peut pas produire autant que dans le
modèle d'origine. Par conséquent, les processus en aval sont plus souvent sous-
alimentés, ce qui entraîne une inactivité globale accumulée du système. Dans le
même ordre d'idées, la figure 11.29 affiche le rapport spécifié par l'utilisateur
résultant pour le modèle modifié en cas de défaillance.
Une comparaison de la figure 11.29 avec la figure 11.11 révèle des preuves
supplémentaires que le modèle modifié en cas de défaillance fonctionne à un
niveau inférieur à celui d'origine. Étant donné que le processus de remplissage a
augmenté l'inactivité dans le modèle modifié par défaillance, son interdépart
moyen.
Le temps augmente jusqu'à environ 12,5 secondes (contre 8 secondes dans le

modèle d'origine) et, parallèlement, le débit du système n'est que d'environ 0,08
(contre 0,125 unités par seconde dans le modèle d'origine). Ainsi, cet exemple
démontre amplement les effets délétères des pannes et des arrêts des machines
sur les mesures de performances du système. Les conséquences économiques
des performances du système qui en résultent doivent nécessairement suivre.
L'impact des pannes de machines sur les performances du système et la réduction

de cet impact en plaçant des tampons entre les machines ont été largement
étudiés. Pour des discussions plus approfondies sur le sujet, voir Buzacott et
Shanthikumar (1993), Gershwin (1994), Altiok (1997) et Papadopoulos et al.
(1993). L'analyse des réseaux de fabrication avec des tampons infinis se trouve
dans Whitt (1983).
11.8 ESTIMATION DES RÉPARTITIONS DES TEMPS DE

SÉJOUR :
Les statistiques de fréquence sont des constructions d'arène pratiques qui

simplifient la tâche d'estimation de la distribution du nombre d'unités dans une
file d'attente ou un tampon. Cependant, l’estimation de la distribution d’un
temps de séjour (temps total passé dans un système ou un sous-système)
nécessite un peu plus de travail. Par exemple, supposons que nous soyons
intéressés par la distribution du temps de retard Dp qu’une unité de produit
passe dans le tampon d’emballage du modèle de ligne d’emballage de la section
11.3. Plus précisément, nous souhaitons estimer les probabilités de retard
suivantes :
Pr{Dp < 1},Pr{1≤Dp < 3},Pr{3≤ Dp < 5} and Pr{ Dp ≥5}
La figure 11.30 affiche un fragment Arena pour estimer ces probabilités de temps
de retard. Ici, une entité unitaire arrivant traverse le fragment de gauche à droite
sur la figure 11.30. A son arrivée au poste de conditionnement, le premier
module (Assign) horodate l'heure actuelle (Tnow) dans l'attribut Delay Start
Time de l'entité unitaire. L'entité unitaire entre alors dans le deuxième module
(Seize) et réussit finalement à s'y emparer de la ressource de packaging Packer,
éventuellement après avoir attendu dans sa file d'attente. À ce stade, il entre
dans le troisième module (Assign), où son temps de retard dans le tampon de
compression est calculé par l'expression :
Delay in Pack_Q =Tnow-Delay Start Time
Et stocké dans l'attribut Delay in Pack_Q de l'unité. Les temps de retard calculés
sont comptabilisés en additionnant les résultats des conditions entre parenthèses,
qui sont évaluées à 1 ou 0 (si elles sont vraies ou fausses, respectivement). Par
exemple, la variable N1 compte le nombre d'observations de retard strictement
inférieur à 1, N3 compte celles qui tombent dans l'intervalle [1, 3), N5 compte
celles qui tombent dans l'intervalle [3, 5), et NM compte celles qui sont
supérieurs ouégal à 5. A noter que chaque entité unitaire entrante incrémente
une et une seule des variables N1, N3, N5 et NM. Enfin, la variable Nombre
d'observations suit le nombre total d'observations de retard. Lorsque la
réplication se termine, les probabilités de délai requises sont calculées via des
statistiques de type Sortie, définies dans le module Statistic. La figure 11.31
affiche la feuille de calcul de dialogue pour estimer les quatre probabilités de
temps de retard requises à l'aide d'expressions de rapport appropriées. Dans le
même ordre d'idées, on peut également estimer d'autres probabilités de temps de
séjour, comme la répartition du délai de fabrication (le temps écoulé entre le
début de la première opération et la fin de la dernière). La mise en œuvre d'une
telle estimation du temps de séjour est laissée en exercice au lecteur.
Equal to 5. Note that every incoming unit entity increments one and only one of
the variables N1, N3, N5, and NM. Finally, the variable No of Observations
tracks the total number of delay observations.
Lorsque la réplication se termine, les probabilités de délai requises sont calculées
via des statistiques de type Sortie, définies dans le module Statistic. La figure
11.31 affiche la feuille de calcul de dialogue permettant d'estimer les quatre
probabilités de temps de retard requises à l'aide d'expressions de ratio
appropriées.
Dans le même ordre d'idées, on peut également estimer d'autres probabilités de

temps de séjour, comme la répartition du délai de fabrication (le temps écoulé
entre le début de la première opération et la fin de la dernière). La mise en
œuvre d’une telle estimation du temps de séjour est laissée en exercice au
lecteur.
11.9 BATCH PROCESSING :
Dans les environnements de fabrication typiques, il est assez courant de

rencontrer des processus ou des machines qui fonctionnent sur un certain
nombre de tâches (unités de produits) en tant que groupe. La taille du groupe est
généralement un nombre fixe prescrit, mais elle peut également être aléatoire.
Dans de nombreux cas, le groupe d'emplois devient un ensemble permanent et
poursuit son processus de fabrication comme une seule unité. Dans certains cas,
l’inverse se produit et un groupe d’emplois est divisé en membres individuels
constitutifs. Dans le langage industriel, on dit que les groupes de tâches sont
traités par lots. Des exemples de processus par lots comprennent la peinture, le
traitement thermique, l'emballage, diverses opérations d'assemblage et de
montage dans les industries automobile et électronique, ainsi qu'une variété
d'opérations telles que la stérilisation, l'agitation et la centrifugation dans les
installations chimiques et pharmaceutiques et bien d'autres. Les constructions
Arena qui prennent en charge la fonctionnalité de traitement de groupe sont les
modules Batch et Separate. Le module Batch prend en charge les lots
permanents et temporaires. A l'inverse, leUn module séparé récupère les
membres individuels constitutifs des groupes temporaires ; les groupes
permanents ne peuvent pas être divisés en leurs membres constituants.
Pour illustrer le traitement par lots, nous modifions la ligne de conditionnement

modifiée en cas d'échec de la section 11.7 en incorporant le traitement par lots et
la séparation, comme le montre la figure 11.32, et nous appelons ce système le
modèle de ligne de conditionnement modifiée par lots. Laissez les temps
d'interarrivée des unités de produit dans le modèle modifié par lot être
uniformément répartis entre 5 et 10 secondes. Supposons que le processus
d'étiquetage étiquette des lots de cinq unités à la fois, après quoi les unités sont
traitées séparément en tant qu'unités individuelles. Supposons en outre que des
lots de 10 unités soient emballés ensemble dans le processus d'emballage. Le
temps d'étiquetage de chaque lot est de 25 secondes et le temps d'emballage de
chaque lot est de 30 secondes. Pour permettre le regroupement et la séparation,
nous devons augmenter la capacité tampon du processus d'emballage afin de
prendre en charge les lots. Pour plus de simplicité, nous définissons simplement
toutes les capacités du tampon à l'infini, éliminant ainsi le blocage. Cependant,
les pannes et arrêts machine sont conservés dans le modèle modifié par lots.
Nous nous intéressons au temps d'écoulement moyen des entités unitaires
depuis leur arrivée à la file Filling Process. Queue jusqu'à leur arrivée au
module Interdeparture Time.
La figure 11.33 affiche la boîte de dialogue du premier module Batch suite à
l'opération de plafonnement. Ce module Batch, appelé Batch 1, collecte les
entités unitaires en lots temporaires (champ Type) de taille 5 (champ Taille du
lot). Rappelons que l'étiquetage est ensuite réalisé pour chaque lot dans son
ensemble. Le champ Règle spécifie que les lots seront constitués de n'importe
quelle entité unitaire (option Toute entité), plutôt que de limiter le traitement par
lots aux entités unitaires ayant la même valeur d'un attribut prescrit (option Par
attribut). Ensuite, l'option Temporaire dans le champ Type affiché dans la
Figure 11.33 précise que ce lot doit être fractionné ultérieurement
(contrairement à l'option Permanent). Enfin, le champ Save Criterion permet de
sélectionner l'ensemble des attributs associés à chaque lot. Par exemple, dans la
boîte de dialogue de la Figure 11.33, l'option Dernier a été sélectionnée,
indiquant que les attributs du lot sont hérités de la dernière entité unitaire du lot
(celle qui termine le lot).
Suite à l'opération d'étiquetage, chaque lot entre dans le module Séparé appelé
Split, dont la boîte de dialogue est affichée dans la Figure 11.34. L'option
Fractionner le lot existant dans le champ Type stipule que les lots doivent être
divisés en leurs membres constitutifs individuels. L'autre option du champ
Type, Dupliquer l'original, est utilisée pour créer des doublons de l'entité qui
entre dans ce module. L'option Conserver les valeurs d'entité d'origine
sélectionnée dans le champ Attributs des membres garantit que les attributs
d'origine de tous les membres du lot seront récupérés lors du fractionnement.
Une fois l'opération de scellage terminée, les unités sont emballées lors du
processus d'emballage dans des boîtes en carton par lots de 10. Les entités
d'emballage entrent ensuite dans des modules supplémentaires, où elles sont
comptés et leur temps d'écoulement dans le système est compté avant d'être
éliminés au module Terminé. Le rapport de ressources de simulation pour une
réplication du modèle modifié par lots est affiché dans la figure 11.35. Enfin, le
rapport spécifié par l'utilisateur correspondant est affiché dans la figure 11.36.
11.10 OPÉRATIONS DE MONTAGE :
Il est assez courant dans les environnements de fabrication d'avoir des

opérations d'assemblage, où un certain nombre de pièces provenant de différents
tampons sont assemblées pour produire une seule unité de produit fini ou semi-
fini. Les unités de pièces correspondantes qui arrivent sont mises en mémoire
tampon dans des tampons correspondants devant le poste d'assemblage, comme
le montre la figure 11.37.
Le nombre d'unités prélevées dans les tampons correspondants pour l'opération
d'assemblage peut varier d'un cas à l'autre. Dans tous les cas, cependant,
l'opération d'assemblage ne peut démarrer qu'une fois que toutes les unités
correspondantes sont présentes dans les tampons correspondants.
Arena fournit un module appelé Match, qui peut être utilisé pour assembler des
pièces correspondantes. Plus généralement, le module Match est utilisé pour
synchroniser le mouvement de différentes entités unitaires dans un modèle. Par
exemple, les entités correspondantes qui arrivent peuvent s'attendre les unes les
autres dans des tampons jusqu'à ce qu'un lot soit terminé, moment auquel
chaque entité recommence à suivre son chemin logique dans le modèle.
Le module Match et sa boîte de dialogue sont illustrés dans la figure 11.38.
Notez que l'icône du module contient autant de tampons correspondants (barres
T) que la valeur du champ Nombre à correspondre dans la boîte de dialogue. De
plus, il y a autant de points d'entrée et de sorties de connexion dans le module
Match.
Le module Match fonctionne comme suit. Dès que chaque tampon contient au
moins une entité, précisément une entité est sélectionnée dans chaque tampon
correspondant, et celles-ci sont envoyées aux destinations de connexion
associées. Ainsi, ce module peut être utilisé pour synchroniser les mouvements
d'entités. En particulier, le module Match peut être utilisé pour modéliser les
opérations d'assemblage en connectant exactement un point de sortie au poste
d'assemblage désigné (l'entité correspondante représente le produit unitaire
assemblé), et tous les autres à un module Dispose. Le point de synchronisation
est spécifié par le champ Type : l'option Any Entities synchronise toutes les
entités dans les tampons correspondants, tandis que l'option Based on Attribute
sélectionne les entités synchronisées comme celles qui ont la même valeur dans
l'attribut spécifié. Par exemple, si les entités ont un attribut de couleur, seules les
entités de même couleur seront mises en correspondance. Ainsi, un lot peut être
déclaré si chaque tampon correspondant contient au moins une entité rouge.
Cependant, une seule entité rouge est alors sélectionnée dans chaque tampon
correspondant. Si différents nombres d'unités sont assemblées à partir de
tampons correspondants, alors un Le module Batch peut être utilisé en premier,
puis les unités par lots peuvent être assemblées à l'aide d'un module Match.
Batch module can be used first, and then the batched units can be assembled
using a
Match module.
11.11MODEL-VERIFICATION-FOR-
PRODUCTION LINES :
This section generalizes certain aspects of production lines that play an

important role in understanding line behavior and verifying its logic.
Consider the production line depicted in Figure 11.39. Here, Mi denotes the i-
th machine and Bi denotes the buffer between Mi—1 and Mi with finite-capacity
Ni (excluding the server positions in both machines). Let Xi be the random
variable representing the processing time in Mi. We may assume that M1 has a
sufficient amount of raw material, so that it never starves. Another possibility is
that M1 has a buffer at which product units arrive in a particular manner (either
randomly or according to a schedule).
Define the following probabilities:
Pi(I ) is the probability that Mi is idle. Pi(B) is the probability that Mi is
blocked. Pi(D) is the probability that Mi is down.
Pi(U ) is the probability that Mi is up (producing).
Then, the utilization of Mi is given by
Pi(U ) ¼ 1 — P i(I ) — Pi(B) — Pi(D), (11:4)
indicating that Mi is in the up state when it is neither idle, nor blocked, nor down.
While Mi is actually busy (with probability Pi(U ), it is producing at rate 1=E ½ ]Xi
yielding a throughput ¯oi given by
Pi(U )
¯oi ¼ i : (11:5)
E½X ]
In the event that product units are not lost, the long-run flow rate (throughput) of
units in a production line with K machines is the same at every machine,
namely,
o¯1 ¼ ¯o2 ¼ · · · ¼ o¯K : (11:6)
Thus, workstation throughputs are identical, each equal to the line
throughput, ¯o‘ . If product units are lost at a particular workstation j due to
scrapping or rejection (with some prescribed probability), then the throughput
¯oj should be adjusted accordingly. In addition, all throughputs of
downstream workstations would be similarly
B2 M2 B3 BK MK
1 2 K
N2 N3 NK
Figure 11.39 Schematic representation of a generic production line.

adjusted. Equations 11.4–11.6 can assist the modeler in verifying production

line models.
Little’s formula (Eq. 8.8) can also apply to the entire production line (see
Section 11.4). Consider again the production line in Figure 11.39 with K
workstations and K – 1 buffers, and let F¯S be the average total time a product
unit spends in the line. Let N¯j denote the average contents in buffer Bj, and let
N¯S denote the average total number of units in the system. Little’s formula is
given by
N¯S ¼ ¯o‘ F¯S , (11:7)
which was used in model verification in Section 11.4. On the other hand, N¯S
can be computed directly as
K K K—1 X X X
N¯ S ¼ N¯ j þ Pj (U ) þ Pj (B), (11:8)
j¼2 j¼1 j¼1
where the first term on the right side is the average total buffer contents of the
line (excluding the first machine that has no buffer and further excluding server
positions), the second term is the average total number of units in service
positions while the servers are busy, and the last term is the average total number of
units in server positions while the servers are blocked. For verification purposes,
the modeler should check the agreement of computations for Eqs. 11.7 and
11.8.
EXERCISES
1. Three-stage production line. Consider the filling and inspection system
consisting of three stages in series shown in the next illustration. Bottles
arrive with iid exponentially distributed interarrival times with a mean of 2
minutes. They enter a filling operation with an infinite buffer in front of it to
accommodate arriving bottles. The filler fills a batch of five bottles at a
time. Filling times are iid uniformly distributed between 3 and 5 minutes.
The entire batch of 50 bottles then attempts to join the sealer queue (of 10-
bottle capacity) as individual bottles. However, if the sealer queue cannot
accommodate the entire batch, the filler becomes blocked until space
becomes available in the sealer queue. The filler is subject to failures with
iid exponential times to failure with a mean of 50 minutes, and with iid
triangularly distributed downtimes with parameters (2, 5, 10) minutes.
Failures may occur at any point in time. The sealing operation is performed
on a batch of three bottles at a time. It takes precisely 3 minutes to seal all
three bottles. The inspection queue has a finite capacity of 10 bottles.
Inspection takes precisely 1.45 minutes per bottle. Experience shows that
80% of bottles pass inspection and depart from the system, while the rest
are routed to a rework station to modify the fill volume. The rework station
has an infinite-capacity queue and a single server. Rework times are iid
uniform between 1 and 4 minutes. After rework, bottles are routed back to
the inspection queue for another inspection. However, rework bottles
have a higher priority than nonrework bottles. Note that a bottle may go
through rework more than once.
Filling Sealing Inspection

Bottles 0.8
0.2
Rework
a.Develop an Arena model for the production line, and simulate it for 1
year, assuming 365 days of work per year and 8 hours of work per day.
b. Estimate the following statistics:
Average WIP contents in each buffer
●
Server utilization for each workstation

●
Average flow time through the system

●
Distribution (histogram) of flow times with five intervals

●
State probabilities (busy, idle, down, blocked) of every resource in the

●
system
Probability that the filling, sealing, and rework workstations are
●
simultaneously blocked by the inspection station

2. Production system with inspection and rework. Consider the following
production system, which produces printed circuit boards in multiple
stages with unlimited buffer capacities. Unit interarrival times are iid
exponential with a mean of 2.2 hours. Arriving boards have two parts: part
1 and part 2. Upon arrival, parts separate and proceed to their respective
processes separately in two branches. Part 1 units proceed along the first
branch to a chemical disintegration process followed by a circuit layout 1
process, where disintegration times are iid uniform between
0.5 and 2 hours, and circuit layout times are iid uniform between 1 and 2
hours. Part 2 units proceed along the second branch to an
electromechanical cleaning process followed by a circuit layout 2 process,
and the corresponding processing times are iid exponentially distributed
with means 1.4 and 1.5 hours, respectively. An assembly workstation then
picks one unit from each branch and assembles them in an operation that
lasts precisely 1.5 hours. Assembled units proceed to a testing station
where batches of five units are tested simultaneously. Testing times are iid
triangularly distributed with parameters 6, 8, and 10 hours. After testing,
batches are split into individual units, which then depart from the system.
After every 8-hour period, all processes shut down for a 1-hour
maintenance operation. The following random stoppages are observed in
each process.
Station Name Failure Type Time to Failure Time to

(hours) Repair
(hours)
Disintegration Random Expo(1/20) Unif(1, 2)

Cleaning Random Expo(1/30) Beta(5, 1)
Layout 1 Random Expo(1/25) Unif(2, 5)
Layout 2 Random Expo(1/25) Beta(5, 1)
Testing Adjustment Every 200 units Tria(1, 3, 4)
Recall that in Arena, the parameters of the beta distribution are in reverse
order, and the parameter of the exponential distribution is the mean (not
the rate).
a.Develop an Arena model for the production system, and simulate it for 1
year of operation.
Utilization of each process
●
Average delay at each process

●
Average system flow time of assembled units

●
Distribution of the number of jobs in the testing buffer

●
Probability that the system is in maintenance

●
State probabilities of each process (idle, busy, failed, and maintenance)

●
3. Two-stage manufacturing system with warehousing. Consider the

following two- stage manufacturing system, where a product is produced at
stage 1 and packaged at stage 2.
Demand arrivals
M1 M2
WIP buffer Warehouse
Customers arrive at the warehouse with product demands and their orders
are filled (possibly backordered) from warehouse inventory. When the
reorder point at the warehouse is reached, machine M2 starts producing
using material from the buffer, which is fed by machine M1.
Stage 1 consists of machine M1 and an output WIP buffer capacity of 40
units. Machine M1 always has material to process (never starves) and takes
1 hour to process a unit. Stage 2 consists of machine M2 and a finished
product warehouse. Machine M2 takes 0.75 hours to process a unit.
Customers arrive at the finished product warehouse according to a Poisson
process at the rate of 1 per 9 hours. The demand size distribution is
Disc({(0.3, 3), (0.3, 6), (0.4, 12)}), and excess customer demand is
backordered.
Machine M1 is blocked whenever a finished unit cannot enter the WIP
buffer due to lack of space, and remains blocked until room becomes
available in the WIP buffer. Machine M2 strives to maintain a level of 60
units in the warehouse: Production is in progress at M2 as long as the
inventory level at the warehouse is below 60, and gets blocked when that
inventory level reaches 60. (Note: warehousing will be covered in the
next chapter in more detail in the context of supply chains.)
a. Develop an Arena model for the manufacturing system, and simulate
it for 10 years.
●
Actual machine utilizations (excluding any idleness)
●
Blocking probabilities for each machine
●
Average inventory levels in the WIP buffer and the warehouse
●
Average backorder level in the finished product warehouse
●
Probability of backordering upon customer arrival
This page intentionally left blank

Arena Cour Avec Exemple

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

Arena Cour Avec Exemple

Transféré par

Droits d'auteur :

Formats disponibles

Simulation Modeling

AMSTERDAM • BOSTON • HEIDELBERG • LONDON

Modélisation des lignes de production

11.1 LIGNES DE PRODUCTION

Considérons la représentation d'une installation de fabrication générique

Si la production devient excessive, la chaîne de fabrication peut cesser de

Il est possible d'identifier un poste de travail goulot d'étranglement qui sépare

11.2 MODÈLES DE LIGNES DE PRODUCTION

Des pertes de productivité sont potentiellement encourues chaque fois que

11.3 EXEMPLE : UNE LIGNE DE

11.3.1 UN MODÈLE D'ARÈNE

Figure 11.2 Arena model for the packaging line system.

11.3.3 BLOCAGE DE MODÈLE À L'AIDE DU

Figure 11.3 Dialog box of the Process module Filling Process.

Le champ Condition de la boîte de dialogue du module Hold a été configuré pour

Il convient de noter qu'un module de libération suit chaque module de maintien

11.3.4 RESSOURCES ET FILES D'ATTENTE

Figure 11.5 Dialog spreadsheet of the Resource module.

Figure 11.6 Dialog spreadsheet of the Queue module.

11.3.5 COLLECTE DE STATISTIQUES

NQ (Filling_ R_Q) >¼ 2:

11.3.6 RAPPORTS DE SORTIE DE

Modeling Production Lines

Figure 11.9 Queues report for the packaging line model.

Modules de statistiques et d'enregistrement. La section Tally de la figure 11.11

Figure 11.10 Resources report for the packaging line model.

Le temps de traitement du module Interdeparture Time a été estimé à 239,78

Figure 11.12 Frequencies report for the packaging line model.

Utilization 0.813 0.625 0.999 0.625 0.750

11.4 COMPRÉHENSION DU COMPORTEMENT DU

Dans le cadre de la vérification du modèle de simulation, nous vérifions ensuite

11.5 MODÉLISATION DES LIGNES DE PRODUCTION PAR

Lorsque les modèles contiennent des composants dont la logique est

Figure 11.15: Dialog boxes of Resources Element (top) and Resources

Enfin, l'indexation des expressions Arena dans la ligne d'emballage est

Figure 11.16: Dialog boxes of Expressions Element (left) and Expressions

Ce module génère 30 entités unitaires au temps 0, qui circulent à plusieurs

Figure 11.17 : Modèle d'arène avec indexation pour le système de la ligne

la collecte ultérieure d'observations sur le temps de passage total (au dernier

Figure 11.18 : Boîte de dialogue du premier module (Seize) de la boucle.

Figure 11.19 : Boîte de dialogue de la ressource courante dans la boucle.

Figure 11.20 : Boîte de dialogue du deuxième module (Delay) dans la boucle.

Figure 11.21 : Boîte de dialogue du troisième module (Decide) dans la boucle.

Dans ce cas, l'unité procédera au module de libération, appelé Release Last

Figure 11.22 : Boîte de dialogue du quatrième module (Hold) de la boucle.

11.6 : UNE MÉTHODE ALTERNATIVE DE

Il existe plusieurs façons de modéliser le blocage dans Arena. Dans l'exemple

Figure 11.23 : Feuille de calcul du module Ressources pour la modélisation du

Figure 11.24 : Modélisation alternative de l'arène de blocage via les modules de

PANNES DE LA MACHINE À MODÉLISER :

Les arrêts de processus sont inévitables dans les systèmes de fabrication et de

 L'option Préempter démarre un temps d'arrêt en suspendant la ressource

Les probabilités d'état de chaque ressource peuvent être obtenues en demandant la

Le temps augmente jusqu'à environ 12,5 secondes (contre 8 secondes dans le

L'impact des pannes de machines sur les performances du système et la réduction

11.8 ESTIMATION DES RÉPARTITIONS DES TEMPS DE

Les statistiques de fréquence sont des constructions d'arène pratiques qui

Pr{Dp < 1},Pr{1≤Dp < 3},Pr{3≤ Dp < 5} and Pr{ Dp ≥5}

Dans le même ordre d'idées, on peut également estimer d'autres probabilités de

11.9 BATCH PROCESSING :

Dans les environnements de fabrication typiques, il est assez courant de

Pour illustrer le traitement par lots, nous modifions la ligne de conditionnement

11.10 OPÉRATIONS DE MONTAGE :