Documente Academic
Documente Profesional
Documente Cultură
SYSTÈMES DE PRODUCTION
RÉSEAUX DE PETRI
SIMAN - ARENA
Jean-Louis Boimond
Table des matières
1
I INTRODUCTION À LA SIMULATION
La simulation est un processus qui consiste à :
- Concevoir un modèle du système (réel) étudié,
- Mener des expérimentations sur ce modèle (et non pas des calculs),
- Interpréter les observations fournies par le déroulement du modèle et formuler des
décisions relatives au système.
Le but peut être de comprendre le comportement dynamique du système, de comparer des
configurations, d’évaluer différentes stratégies de pilotage, d’évaluer et d’optimiser des
performances.
La simulation est une technique, appliquée dans ce cours aux systèmes de production,
permettant d'étudier le comportement d'un système dynamique en construisant un modèle
logiciel de celui-ci.
NR(Operateur)
Les domaines d'application sont divers. Sont listés ci-dessous quelques classes d’applications
et quelques exemples de problèmes typiques rattachés à ces classes :
Systèmes de flux de production
- équilibrage de lignes d’assemblage,
- conception de systèmes de transfert entre des postes,
- dimensionnement des stocks d’un atelier,
- comparaison de pilotage,
- évaluation de la charge prévisionnelle,
- étude de la synchronisation entre les réceptions des pièces et l’assemblage.
Flux logistiques et systèmes de transport
- conception et dimensionnement d’entrepôts,
- dimensionnement d’une flotte de camions,
- étude de procédures de contrôle des flux de véhicules en circulation.
2
Production des services
- étude de transactions bancaires,
- gestion de restaurants,
- comparaisons de politiques de maintenance des avions.
Systèmes informatiques et télécommunications
- évaluation de protocoles de gestion des transactions de bases de données,
- étude de la file d’attente mémoire d’un serveur,
- étude des comportements des utilisateurs,
- conception et dimensionnement de hubs (« moyeu »).
Autres classes d’applications
- domaine militaire (support logistique, coordination des opérations, …),
- gestion d’hôpitaux (personnel, lits, service d’urgence, …),
- le nucléaire, la météo, les jeux, ...
Méthodologie générale
Validation
Système (réel) Modèle conceptuel
(a)
Analyse & Modélisation
Programmation
Interprétation Correction
& Action Vérification
Expérimentation(b)
Résultats Programme de
Correction simulation
(a) Modèle conceptuel : Le modèle n'est qu'une approximation du système, il est conditionné
par l'objectif de l'étude.
(b) Expérimentation : Il s'agit de construire des théories, ou hypothèses, qui prennent en
compte le comportement observé.
Le passage du système au modèle conceptuel est une étape essentielle pour la simulation.
Dans le cadre de ce cours, on utilise une modélisation conceptuelle par réseaux de Petri (cf.
chp. VII). Le passage du modèle conceptuel au modèle/programme de simulation se fait en
utilisant le langage Siman-Arena ; ce langage de simulation permet également d’extraire des
résultats issus de différentes expérimentations (cf. chp. VIII).
3
I.1 L’ÉTAPE DE MODÉLISATION
L’étape de modélisation est une phase essentielle à la simulation. Différents points doivent
être abordés :
Définir l'objectif de la modélisation (lié au cahier des charges) : Pourquoi modélise-t-on ?
Qu'étudie-t-on ? Que veut-on améliorer, ou faire ?
Définir les éléments du système (via la réalisation d'une fonction, ou d'un processus) et les
limites du système (les entrées, les sorties).
Définir les interactions entre ces éléments (hiérarchie).
Définir la dynamique du système (entités qui circulent entre les éléments, comportement du
système au cours du temps).
Abstraction (choisir les éléments du système pertinents pour l'étude).
Formalisation, conceptualisation : Modèle mathématique (algèbre (max, +), chaînes de
Markov), modèle logiciel (Simulink, Siman-Arena), modèle graphique (réseaux de Petri,
bond graphs).
4
II LA SIMULATION DES SYSTÈMES DE PRODUCTION
Les systèmes automatisés de production - à l'initiative de l'Homme - sont caractérisés
par une forte complexité et flexibilité. Selon un certain point de vue, ils peuvent être spécifiés
par des modèles à événements discrets (un modèle est à événements discrets lorsque l’espace
d'état est à événements discrets, i.e., les transitions entre états sont associées à l'occurrence
d'événements discrets asynchrones). Les systèmes de trafic (aérien, ferroviaire, …), les
systèmes de communication, les systèmes informatiques sont d'autres exemples de systèmes
dynamiques dont l'activité est due à des événements discrets, dont certains sont provoqués
(départ d’un train, appui sur une touche d'un clavier) et d'autres pas (panne d'un équipement).
Modèle
Système de Historique, Evaluation de
production statistiques performances
Programme
Un système de production est constitué d'un système opérant (physique), d'un système de
conduite (partie commande) et d'un système d'informations reliant ces deux derniers. Il est
traversé par un flux d'informations (présence d'une pièce, état d'une machine) et un flux
physique (matière première, pièces). Le système à étudier peut être existant, à modifier ou non
encore construit.
L'historique et les statistiques portent sur les déplacements (temps de séjour des pièces, temps
de transports des pièces d'un lieu à un autre, ...), les taux d'engagements des ressources, les
longueurs des files d'attente, ...
1
L’évaluation de performances se base souvent sur le taux de production (nombre moyen de pièces par unité de
temps), le WIP (Work In Process, nombre total de pièces dans le système à chaque instant), le makespan
(intervalle de temps entre le début et la fin de la production des pièces).
5
La simulation permet de répondre à la question « que se passe-t-il si ... ? » pour l'étude de
systèmes de production complexes (structure, comportement dynamique, taille, choix
multiples).
Exemple :
M2
Pièces A M1
Pièces B
t1A M3
t1B
L'état du système à un instant donné est caractérisé par l'ensemble des valeurs des variables
et des attributs de tous les objets. Le modèle reproduit l'évolution au cours du temps de l'état3
du système sous l'effet des activités qui y sont réalisées.
2
Les changements d’état de tels systèmes s’opèrent instantanément, à des moments discrets dans le temps. Par
exemple, si une variable représente le nombre de pièces dans un stock alors ses valeurs varient seulement aux
instants où des pièces entrent, ou sortent, du stock.
3
Dans le cas d’une évolution continue de l’état, le modèle est continu, la description se fait, par exemple, via des
équations différentielles, ou des variables d’état. Dans le cas où les changements d’état s’effectuent,
instantanément, à des instants discrets dans le temps, le modèle est à événements discrets, la description se fait,
par exemple, à l’aide d’un réseau de Petri. Certains problèmes nécessitent des modèles dits hybrides, où
apparaissent conjointement des comportements continus et des comportements dus à des événements discrets.
6
Evolution d'une simulation événementielle : Le modèle du système passe au cours du temps
d'un état à un autre suite au déclenchement d'un événement. A chaque événement est associée
une fonction à exécuter laquelle peut modifier l'état du système à travers le déclenchement
d'un, ou de plusieurs événements.
Événement X
Moteur
Exécution de
Échéancier l’événement
Événement C dont la date
d’occurrence
Événement B Événements est la plus
Événement A datables proche
- Volume de production :
- Nombre et type de pièces produites,
- Nombre et type de pièces défectueuses, ...
Ces indicateurs de performances sont ensuite agrégés pour des prises de décisions relatives à
l'aide à la conception, à la conduite, ...
7
3. A quel niveau ?
Système de Modèle de
commande Proposition commande
de décisions
Modèle du
Système
Décisions Résultats système
physique
physique
Le système présente un problème (il ne répond plus aux besoins des utilisateurs).
Bien mettre en évidence les dysfonctionnements par rapport aux besoins et proposer des
solutions permettant de pallier à ces dysfonctionnements au moindre coût.
Définir les performances à mesurer.
Déterminer les ressources goulets (machines, stocks, moyens de manutention,
personnel, ...) qui agissent le plus sur les performances, et pour un scénario de production
donné.
On peut chercher à améliorer le système, soit en agissant sur la capacité des ressources, soit
sur la manière dont on utilise ces ressources (règles de gestion).
8
b) La simulation : une aide à la traçabilité (implicite/explicite)
Réalité Simulation
Système de Modèle de
commande Proposition commande
de décisions
Identification Identification
Identification Identification
Système Modèle du
Décisions Résultats système
physique
physique
On peut chercher à synthétiser un système de traçabilité qui soit fiable (le reflet de la réalité)
et robuste (l'outil de simulation permettant la prise en compte de différents scenarii possibles,
ceci sans risque pour le système (réel)).
Les données à utiliser (recueil non exhaustif) concernent l'ensemble de l'état (dynamique) du
système piloté dans le but « de retrouver l'historique, l'utilisation ou la localisation d'un article
ou d'une activité, au moyen d'une identification enregistrée (1994, ISO 8402) » :
- Produits, articles, lots (entités),
- Moyens de production (capacité des machines),
- Stocks, systèmes de transfert (état),
- Opérateurs (qualification, nombre, horaires),
- Système d'identification,
- Structure de traitement des données recueillies.
9
c) La simulation pour définir un futur système
Simulation Réalité
Modèle de Système de
commande commande
Implémentation
Conception
du système
Modèle du Système
système physique
physique
Aide à la décision d'investissement :
Choix technologiques et organisationnels : Equipements, stratégies de gestion de production
(gestion des stocks, taille des lots, seuils de réapprovisionnement, nombre de Kanban),
organisation du travail (cellules, lignes, mixte), choix de gamme.
Evaluation des différents scénarii en fonction des critères les plus pertinents.
Exemples d'applications :
Dimensionnement d'ateliers : Nombre et type des équipements (en fonction du coût),
capacité des stocks, nature du système de transport
Choix de production (étude de rentabilité)
10
III RAPPELS DE PROBABILITÉS ET STATISTIQUES
Sachant qu'il est impossible – quelle que soit la puissance des ordinateurs - de simuler
toutes les déviations possibles d'un système, l'outil statistique est une alternative pour prendre
en compte, étudier et maîtriser les conséquences des variations aléatoires des systèmes.
La théorie des probabilités, branche des mathématiques, permet de modéliser et d'étudier des
phénomènes aléatoires. On parle alors d'événements aléatoires, de lois de probabilité, de
variables aléatoires, ...
La statistique repose sur l'observation de phénomènes concrets. Le but est de recueillir des
données d'observation, de les traiter et de les interpréter. On parle alors de population
d'individus, de variables caractéristiques, d'échantillons, de moyennes, ...
Les modèles probabilistes permettent de représenter approximativement les données
observées (imprécision, erreurs, répartition dans la population) comme des variables
aléatoires suivant une certaine loi de probabilité → modèles simplificateurs.
L'échantillon étant tiré au hasard, les caractéristiques des données à traiter sont des variables
aléatoires → application de théorèmes de probabilités (par exemple, le théorème centrale
limite4).
4
La moyenne d'un échantillon de taille n extrait d'une population quelconque de moyenne μ et d'écart type σ est
distribuée selon une loi pratiquement normale de moyenne μ et d'écart type
quand la taille de l'échantillon
n
est suffisamment grande. Pour une population de départ de distribution normale, le théorème centrale limite est
valable pour tout n. Pour les distributions rencontrées dans la pratique courante, plus la taille de l'échantillon est
grande, plus la loi se rapproche de la loi normale. On peut considérer qu'à partir de n égale à 30, la moyenne d'un
échantillon est distribuée de façon sensiblement normale.
5
Inférence : Opération intellectuelle par laquelle on passe d'une vérité (une proposition) à une autre vérité
(proposition), jugée telle en raison de son lien avec la première : La déduction est une inférence.
11
→ des fonctions intégrées dans le modèle de simulation (lois de
distributions),
- Interpréter statistiquement les données générées par le modèle
→ moyennes, intervalles de confiance, ...
Définition de la probabilité
Exemple de la loi uniforme continue : Soit X une variable aléatoire susceptible de prendre
toutes les valeurs d'un intervalle fini a, b , sans privilégier aucune région de a, b (on parle
d'événements équiprobables). Aussi, la probabilité que X prenne une valeur appartenant à
l'intervalle u, v ( a, b ) est proportionnelle à la longueur de u, v , d'où
vu v
P (u X v) , soit P(u X v) f ( x) dx
ba u
1 / (b a) si a x b
où f (x) = .
0 sinon
f(x) aire =
0
a u v b x
12
La fonction f (x) , appelée densité de probabilité, définit le comportement aléatoire
(stochastique) de la variable aléatoire X et permet ainsi de caractériser sa loi de probabilité
(distribution).
La loi uniforme (distribution of maximum ignorance) est utilisée lorsque l'on a aucune
information exceptée la connaissance du domaine a, b .
La plus grande partie des phénomènes aléatoires rencontrés dans la pratique peut être étudiée
via un nombre restreint de lois de distribution. Nous allons à présent voir les principales lois
de distributions.
a) LOI TRIANGULAIRE
f(x)
aire = 1
a m b x
13
2( x a )
f ( x ) si a x m
(m a )(b a )
2(b x)
f ( x) si m x b
(b m)(b a )
f ( x) 0 si non
amb a 2 m 2 b 2 am ab mb
D a, b ; M ; 2 .
3 18
b) LOI EXPONENTIELLE
f(x)
1
𝛽
1
f ( x) e x / si x 0 ( 0)
f ( x) 0 sinon
0 x
D 0, ; M ; .
2 2
Application : Cette loi est souvent utilisée en pratique. Par exemple, dans le cas de temps
séparant les arrivées de 2 « clients » successifs dans l'étude d'un phénomène d'attente, ou dans
le cas d'une durée de bon fonctionnement d'un équipement technique.
La loi exponentielle est la seule loi continue à permettre la prise en compte de phénomènes
sans mémoire. En effet, la probabilité que X soit supérieure, ou égale, à x x0 , sachant que X
est supérieure, ou égale, à x0 , dépend de la valeur de x, et est indépendante de la valeur de x0
(on a : P( X x x0 X x0 ) P( X x) ).
Autrement dit, une loi exponentielle modélise la durée de vie d’un phénomène sans mémoire,
ou sans vieillissement, ou sans usure : la probabilité que le phénomène dure au moins s + t
unités de temps sachant qu’il a déjà duré t unités de temps sera la même que la probabilité de
durer s unités de temps à partir de sa mise en fonction initiale. Par exemple, il est souvent
admis que la durée de vie T d'un dispositif électronique obéit à une loi exponentielle. Aussi la
probabilité de bon fonctionnement dans un intervalle de temps u, u t , c'est-à-dire
P(T t u T u) , dépend uniquement de la longueur de cet intervalle, et non de sa position
par rapport à l'axe des temps (on a : P(T t u T u) P(T t ) ).
14
Démonstration : Soient l'événement A correspondant au fait que X x0 et l'événement B
correspondant au fait que X x0 x . On a P ( X x0 ) f ( x) dx et
x0
P ( X x0 x) f ( x) dx . Aussi P( B A) équivaut à P( X x0 x X x0 ) .
x0 x
c) LOI NORMALE
f (x) points d'inflexion
1 f(x) =
𝜎 2𝜋
f (x) 2 petit
2 grand
0
M- M M+ x
Application : Cette loi s'applique dans le cas de processus dont la distribution est symétrique
et pour lesquels la moyenne et l'écart type sont estimés. Exemple : Variations de la longueur
de pièces fabriquées en séries.
Cette loi permet de modéliser une donnée qui est la somme d'un grand nombre de données
aléatoires (théorème central limite).
15
F(x) est une fonction continue, monotone croissante, telle que F ( ) 0 et F ( ) 1 ,
F ' ( x) f ( x) . Elle permet de calculer des probabilités de la forme P(a X b) ) sans
effectuer une intégration (ce qui est le cas en utilisant f (x) ) ; en effet
P(a X b) F (b) F (a) .
p (x ) 1
i 1
i si N couvre l'ensemble des valeurs.
La loi est représentée soit par le diagramme en bâtons suivant indiquant p( xi ) en fonction de
xi :
p(xi)
1/3
1/6
xi
0
1 2 3 4
6
soit par un histogramme :
p(xi)
1/3
1/6
0 1 2 3 4 xi
6
Ensemble de rectangles de même largeur dont les surfaces sont proportionnelles aux probabilités p(xi).
16
Définitions
N
La moyenne (arithmétique) M est égale à xi p( xi ) .
i 1
Exercice : Calculer la moyenne considérée dans l'exemple précédent.
N
La variance 2 est égale à ( xi2 p( xi )) M 2 .
i 1
On définit la probabilité cumulée (notion utilisée dans le logiciel SIMAN-ARENA) par
i
p c ( xi ) p ( x l ) .
l 1
1 1 5
Dans l'exemple précédent, on a : pc ( x1 ) , pc ( x2 ) , pc ( x3 ) , pc ( x4 ) 1.
6 2 6
Application : Les variables aléatoires discrètes s'appliquent dans le cas d'injection directe de
données empiriques dans le modèle. Exemples : Types de pièces, taille des lots.
17
IV DONNÉES D'ENTRÉE DU SYSTÈME
La qualité des données est aussi importante que la qualité du modèle (garbage in -
garbage out) ; ceci concerne, par exemple dans le cas d'un système de production, les temps
opératoires, les temps de bon fonctionnement, les taux de rebut, ...
Deux cas sont à considérer, soit on a une connaissance partielle des données du
système (moyenne, minimum, maximum, ...), soit on dispose des données du système.
18
- Une distribution exponentielle (grande dispersion : forte variabilité) de paramètre M si la
nature du phénomène le justifie.
Il est souvent intéressant, pour des raisons théoriques et pratiques, de pouvoir décrire une loi
de probabilité par une distribution théorique. Ceci revient à exprimer sous forme analytique
les probabilités p( xk ) en fonction de l'indice k. On peut alors appliquer au calcul des
probabilités des méthodes bien connues d'analyse mathématique, évitant ainsi des calculs
numériques fastidieux.
- Si les données empiriques sont directement utilisées, elles sont entrées sous forme de
distributions empiriques cumulatives (histogramme des fréquences : regroupement des
observations en classes, nombres de classes = O( n bre d ' observations )).
- Si on veut faire des tirages à partir des distributions théoriques, il faut :
a) Choisir une distribution en fonction de sa forme (et celle de l'histogramme des
données),
b) Estimer ses paramètres,
c) Tester l'hypothèse (la distribution correspond-elle bien aux données ?).
19
Nbre de valeurs appartenant à la
classe n° 1, n°2, ... (*)
Cl. 1 …. Cl. n
20
V. VÉRIFICATION ET VALIDATION DES MODÈLES
Les programmes de simulation se caractérisent par une évolution constante (tests de
scénarii, que se passe-t-il si ?, ...). La difficulté majeure est de savoir :
Comment avoir confiance dans le modèle ?
Comment le transmettre à l'utilisateur ?
Avant de tirer des inférences des résultats statistiques d'un modèle/programme de simulation,
il faut s'assurer qu'il est correct au sens où il représente bien le système. Ceci passe
habituellement par deux étapes : la vérification et la validation.
V.1 VÉRIFICATION
La vérification consiste à s'assurer que le modèle fonctionne comme le concepteur le
désire (pas d'erreur de logique), ce qui nécessite de pouvoir isoler les erreurs (étape la plus
difficile) afin de les corriger. La vérification est rendue plus facile si on commence par un
modèle simple qu'on améliore (enrichi) progressivement. Les techniques (ou comportement à
avoir) suivantes permettent l'isolation des erreurs :
1. Considérer toujours que le modèle contient des erreurs et les chercher (approche
destructive, plutôt que constructive).
3. Réviser le modèle et les données avec l'aide d'au moins un client et un connaisseur du
langage (en plus du développeur).
5. Générer et analyser la trace du modèle (cf. dans SIMAN au bloc TRACE de la bibliothèque
ELEMENTS) pour vérifier le cheminement des pièces, les changements d'état à l'issue
d'une attente (au niveau d'une file, par une activité, ...).
7. Corriger les erreurs en identifiant les vraies causes et ne pas traiter seulement les
symptômes (le raisonnement logique reste la meilleure approche).
21
- De la phase d'initialisation (unités de mesures),
- Du contrôle du flux,
- De l'existence de blocages,
- Des erreurs arithmétiques (parenthèses, conversion de types, ...),
- Des erreurs d'enregistrement (temps d'arrivée des pièces, compteurs, ...),
- D'une mauvaise utilisation des primitives ou fonctions du langage.
V.2 VALIDATION
Trois questions doivent être posées :
Le modèle représente-t-il correctement le système réel (validité conceptuelle) ?
Les données sur le comportement générées par le modèle sont-elles caractéristiques
de celles du système réel (validité opérationnelle) ?
L'utilisateur a-t-il confiance dans les résultats du modèle (confiance) ?
Les théories et les hypothèses doivent être correctes et la représentation du modèle doit être en
adéquation par rapport à l'utilisation désirée.
22
Il consiste à étudier le comportement du modèle en relation avec le système de référence.
23
VI INTERPRÉTATION DES RÉSULTATS
Selon le logiciel utilisé, l'exécution d'un programme de simulation peut générer :
- Un rapport de simulation comprenant les moyennes, les écarts types, les minimums et
maximums des variables observées, ...
- Un historique de l'évolution de ces variables au cours de la simulation.
Un tel rapport de simulation ne suffit pas pour tirer des conclusions crédibles sur les
performances du système. Il suffit de changer le générateur de nombres aléatoires pour que le
même modèle génère des résultats différents. L'animation graphique n'est pas suffisante non
plus. En fait, on a souvent tendance à se contenter du rapport de simulation et/ou de
l'animation, surtout quand le projet est en retard.
Les résultats générés par un modèle jouent le rôle de mesures sur un échantillon. Il faut donc
les exploiter pour effectuer des procédures statistiques. A chaque variable (inconnue), il faut
associer un intervalle de confiance.
p(C1 C2 ) 1 .
Il existe deux types de systèmes : Les systèmes finis – c'est-à-dire, ayant un événement de fin
qui détermine la fin de la simulation - et les systèmes qui ne se terminent pas - c'est-à-dire,
n'ayant pas d'événement de fin de simulation. Par exemple, un commerce qui ouvre et qui
ferme à intervalles réguliers est un système fini ; par contre, un hôpital où il y a toujours au
moins un patient est un système qui n'est pas fini.
24
VI.1 ANALYSE DES SYSTÈMES FINIS
Ils sont plus faciles à analyser que les systèmes qui ne se terminent pas. On ne peut contrôler
que le nombre des répétitions des expériences. A chaque répétition, on peut utiliser un autre
générateur des nombres aléatoires.
Si l’on change le générateur des nombres aléatoires d'une répétition à l'autre, on peut
considérer que les observations de type b) d'un ensemble de répétitions sont telles que :
- Elles sont indépendantes,
- Les moyennes sont normalement distribuées.
Cette dernière propriété est due au fait qu'elles sont sommes, ou moyennes, d'observations
individuelles (théorème central limite).
Les procédures classiques de statistiques peuvent alors s'appliquer pour les moyennes. Pour
les minimums et maximums, certaines procédures de statistiques s'appliquent encore.
A partir des observations de type b), on peut calculer en particulier :
- Des intervalles de confiance autour de la moyenne, du maximum et du minimum,
- Des intervalles de confiance autour de la différence entre les moyennes, les maximums
et les minimums de deux systèmes différents.
Cette comparaison de deux systèmes est utile pour évaluer par exemple la différence entre
deux dimensionnements, deux règles d'ordonnancement, ... (si l'intervalle de confiance ne
contient pas 0, on peut en déduire que les deux systèmes sont différents).
Procédure générale :
25
VI.2 ANALYSE DES SYSTÈMES QUI NE SE TERMINENT PAS
On s’intéresse à l'étude des performances stationnaires d’un système du fait d’un régime
transitoire souvent favorable aux performances du système ; ce peut être, par exemple, le cas
d’un atelier vide au début de la simulation. L'état stable du système correspond à son
comportement après un certain temps et est indépendant de l'état de départ.
Le but est de calculer un intervalle de confiance autour de la moyenne. Deux problèmes
peuvent se poser :
- Pas de point de passage précis entre le régime transitoire et le régime stationnaire,
- Corrélation entre les observations.
C'est cette dernière méthode qui est couramment utilisée. Il existe certaines règles pour
sélectionner la partie à tronquer, mais il n'y a aucune méthode complètement satisfaisante. La
plus utilisée est d'évaluer (visuellement) la période transitoire à l'aide des graphes (courbes,
histogrammes, moyennes mobiles).
Intervalles de confiance
Deux méthodes sont couramment utilisées :
- Répétition d'expériences indépendantes comme pour les systèmes finis (problème du
régime transitoire à chaque fois),
- Longue simulation et décompositions des données générées en sous-ensembles (batchs).
Ici encore, les conditions du théorème central limite sont considérées vraies et le calcul de
l'intervalle de confiance justifié (indépendance et normalité des observations X j ).
Indications : n = 10. lag*,
m de 10 à 20.
Corrélogramme lag* : Le plus grand nombre d'observations pour lequel la
corrélation est encore significative.
Cette méthode (présentée pour des variables ne dépendant pas du temps comme le nombre de
pièces finies) est évidemment applicable pour les variables persistantes (dépendant du temps)
comme les tailles des files d'attente. Il suffit de définir les batchs par des intervalles de temps
réguliers au lieu d'un nombre fixé de données.
26
VII NOTIONS ELÉMENTAIRES SUR LES RÉSEAUX DE PETRI
VII.1 GÉNÉRALITÉS
Définition (Réseau de Petri)
Un réseau de Petri (RdP) est un graphe constitué de 2 sortes de nœuds : Les places
(représentées par des ronds) et les transitions (représentées par des barres). Le graphe est
orienté : Des arcs vont d'une sorte de nœuds à l'autre (jamais de places à places, ou de
transitions à transitions directement). Voir exemple dans la figure suivante.
T1 T4
P3
P1 P5
T2 T5 P7
P2 P6
P4
T3 T6
De façon plus formelle, un RdP peut-être défini par un 4-uplet <P, T, Pré, Post> tel que :
P P1 , P2 ,, Pn est un ensemble fini et non vide de places ;
T T1 , T2 ,, Tm est un ensemble fini et non vide de transitions ;
Pré : P T 0, 1 est l'application d'incidence avant ;
Post : P T 0, 1 est l'application d'incidence arrière.
Pré ( Pi , T j ) est le poids de l'arc (orienté) reliant la place Pi à la transition T j ; ce poids vaut
1 si l'arc existe et 0 sinon.
Post ( Pi , T j ) est le poids de l'arc (orienté) reliant la transition T j à la place Pi .
27
Exercice : Exprimer sous une forme matricielle les applications Pré et Post relatives au RdP
précédent. Valider à travers quelques exemples le bon fonctionnement de l’équation
d’évolution du marquage : 𝑀𝑘 = 𝑀𝑙 + (𝑃𝑜𝑠𝑡 − 𝑃𝑟é) 𝑇𝑘 𝑙 ,
où 𝑇𝑘 𝑙 est le vecteur de tirs permettant une évolution du vecteur de marquage, de 𝑀𝑙 vers 𝑀𝑘 .
a b c d
t t
On notera aussi l'existence de RdP temporels, pour lesquels on associe aux places et/ou aux
transitions une temporisation dont la valeur peut se situer à l'intérieur d'un intervalle a, b.
28
VII.2 GRAPHES D'ÉVÉNEMENTS
Restrictions et capacités de modélisation
Les graphes d'événements sont une sous-classe de RdP pour lesquels toute place a exactement
une transition amont et une transition aval (les situations représentées dans les figures a et b
précédentes sont interdites). Aussi, les graphes d'événements peuvent modéliser des
phénomènes de synchronisation, mais pas de concurrence.
A l'opposé, les graphes d'état refusent les configurations représentées dans les figures c et d
précédentes pour ne retenir que celles représentées dans les figures a et b. Aussi, les graphes
d'état, tels que toute transition a exactement une place d'entrée et une place de sortie,
permettent de visualiser des phénomènes de concurrence (décision), mais pas de
synchronisation.
VII.3 EXEMPLES
Soit une machine représentée dans la figure suivante. Chaque pièce qui arrive est, soit traitée
immédiatement par la ressource machine, soit mise en attente dans le stock (à capacité infinie)
jusqu'à ce que la ressource machine soit disponible. Le temps de traitement de la ressource
machine est de 3 unités de temps. Après traitement, chaque pièce sort.
arrivée sortie
pièce pièce
stock ressource
machine
Le RdP suivant modélise ce système.
ressource machine libre
Démarrage
Arrivée Sortie
pièce pièce
stock 3
ressource machine occupée
L'état du système modélisé par le RdP est représenté par le marquage définissant le nombre
de jetons contenus dans chaque place. L'évolution de l'état (représentant la dynamique du
système) correspond à l'évolution du marquage (produit par le franchissement de transitions).
29
Modifications
Arrivée
Sortie
pièce
pièce
stock 3
ressource machine occupée
b) Le stock en amont de la ressource machine est remplacé par un convoyeur correspondant à
une file composée de 5 compartiments (gestion First-In, First-Out du convoyeur). Le
temps de déplacement du convoyeur est de 6 unités de temps. Le système est représenté
par le modèle RdP suivant.
Arrivée
pièce … Démarrage
Démarrage
Sortie
pièce
3
ressources machine occupées
d) La machine a un temps de setup de 1,5 unités de temps. Le système est représenté par le
modèle RdP suivant.
ressources machine libres
Démarrage 1,5
Sortie
pièce
3
ressources machine occupées
VII.4 AUTRES CLASSES DE RÉSEAUX DE PETRI
30
Un ensemble d'événements externes est associé au RdP ; ces événements permettent le
franchissement de certaines transitions. Un tel RdP est dit synchronisé.
Considérons le RdP modélisant la machine décrite dans VII.3. On associe à ce RdP l'ensemble
d'événements A, D, S où A désigne l'événement « Arrivée pièce », D l'événement
« Démarrage service », S l'événement « Sortie pièce ». La figure suivante représente le
système modélisé par un RdP synchronisé. ressource machine libre
T1
Démarrage T3
Arrivée Sortie
pièce pièce
T2
stock D 3 S
A ressource machine
occupée
Le tir de la transition T1 est lié à l'occurrence de l'événement A.
Le tir de la transition T2 est lié :
- A la validation de la transition, matérialisée par la présence d'au moins un jeton dans la
place « stock » et d'un jeton dans la place « ressource machine libre » ;
- Au démarrage effectif du service (occurrence de l'événement D).
Le tir de la transition T3 est lié à l'occurrence de l'événement S.
Assemblage
transition transition
franchissable non franchissable
31
VIII LE LANGAGE DE SIMULATION SIMAN-ARENA
SIMAN-ARENA7 - conçu en 1982 par C.D. Pedgen de System Modeling Corporation - est un
langage de simulation du type interaction de processus, ARENA représentant la version
« graphique » de SIMAN. La description du modèle (logiciel) du système simulé se fait à
l'aide d'un assemblage constitué de mise en série, en parallèle ou en feedback de différents
blocs fonctionnels, issus de bibliothèques (templates) d’ARENA. Une telle approche de
modélisation permet d'obtenir une structure du modèle (logiciel) proche de celle du système
(réel) à simuler.
Attribut : Un attribut est une variable associée individuellement aux entités (la variable est
locale) pour représenter leurs états ou des paramètres qui leur sont propres. Par
exemple, chaque entité, représentant une pièce circulant dans un atelier, peut avoir
les attributs suivants :
- Type_de_piece afin de désigner le type d'une pièce (par exemple, Type_de_piece =
A ou B) ;
- Indice_de_priorite afin de désigner l'indice de priorité d'une pièce (par exemple,
Indice_de_priorite = faible ou importante) ;
- Date_arrivee_ds_le_modele (par exemple, Date_arrivee_ds_le_modele = TNOW).
Variable globale : Une variable globale concerne l'ensemble du modèle. Par exemple, la
variable TNOW (variable prédéfinie dans SIMAN) désigne la date à laquelle se trouve
la simulation, c'est le temps courant - mis à jour à chaque avancée dans l'échéancier
des événements – s’écoulant durant une simulation du modèle.
Quand une entité rentre dans un bloc fonctionnel, elle déclenche/active le « service » qui lui
est associé, ce qui provoque une modification de l'état du modèle. Un « service » peut agir :
- sur l'entité au travers de la valeur de ses attributs. Par exemple, à travers un bloc Assign,
on peut affecter à l'attribut indice_de_priorite d'une entité représentant une pièce,
présente dans le bloc, la valeur importante ;
7
Une documentation électronique est fournie avec le logiciel SIMAN-ARENA à travers différents fichiers
(ArenaBEUsersGuide.pdf, ArenaVariablesGuide.pdf, ArenaSEUsersGuide.pdf) accessibles dans le répertoire
\Rockwell Software\Arena\.
32
- sur les variables globales du modèle logiciel. Par exemple, le passage d’une entité dans
un bloc Delay provoque un retard pur, ce qui aura une conséquence sur la variable
TNOW.
Un programme (ou modèle logiciel) élaboré avec ARENA est sauvegardé dans un fichier
ayant pour extension .doe et est constitué :
- d'une partie modèle, qui représente l'algorithme décrivant les caractéristiques statiques et
dynamiques des différents blocs fonctionnels composant le modèle ;
- du cadre expérimental, qui regroupe les données précisant les paramètres spécifiques à
une simulation donnée (conditions initiales, durée de la simulation, …).
En fait, les entités traversent uniquement les blocs fonctionnels de la partie modèle.
Le bloc Create, issu du template Basic Process, est tel qu'une entité est créée à partir de
l’instant 0, ceci toute les 2 unités de temps.
Le bloc Delay, issu du template Advanced Process, force une entité à séjourner 3 unités de
temps dans le bloc.
Le bloc Dispose, issu du template Basic Process, détruit toute entité entrant dans le bloc.
33
A travers le menu Run/Setup/Project Parameters, on peut notamment donner :
- un titre au projet (champ Project Title),
- le nom du programmeur (champ Analyst Name),
- un commentaire (champ Project Description).
Les 2 fichiers générés par SIMAN-ARENA (au format txt) sont accessibles via le menu
Run/SIMAN/View (voir ci-dessous un listage partiel de ces fichiers).
PROJECT,"Premier exemple","ISTIA",,,No,Yes,Yes,Yes,No,No,No,No,No,No;
REPLICATE, 1,,HoursToBaseTime(10),Yes,Yes,,,,24,Hours,No,No,,,Yes;
34
Le modèle RdP correspondant à la partie modèle du modèle logiciel précédent est décrit dans
la figure suivante :
Afin de bénéficier d’une animation, nous allons utiliser les templates Basic Process et
Advanced Process. Sont décrits en Annexe les templates Blocks et Elements lesquels
contiennent des blocs plus élémentaires (à chacun de ces blocs correspond une ligne dans les
fichiers générés par SIMAN-ARENA).
Des liens sont utilisés pour permettre les assemblages en série, en parallèle, en feedback, entre
les blocs, voir une illustration de tels assemblages dans le RdP qui suit.
a) Create (issu du template Basic Process) : Un bloc Create permet de créer des entités. Celui
représenté dans la figure suivante est intitulé Create 1 (champ Name = Create 1). Sont
indiqués dans le cadre Time Between Arrivals :
- la période de création des lots d’entités (par exemple : champ Type = Constant, champ
Value = 2),
35
- la taille des lots (champ Entities per Arrival = 1),
- le nombre total de lots à créer (champ Max Arrivals = Infinite),
- la date de création du premier lot (champ First Creation = 0).
Les valeurs considérées sont telles qu'1 entité est créée toute les 2 unités de temps à partir de
l’instant 0, ceci une infinité de fois.
Entities per
Arrival (1) P
Max First
Arrivals Creation Sortie de
(∞) (0) l’entité du
bloc Create
Type:Value (2)
b) Dispose (issu du template Basic Process) : Un bloc Dispose permet de détruire des entités.
Celui représenté dans la figure suivante est intitulé Dispose 1 (champ Name = Dispose 1), une
entité entrant dans ce bloc est immédiatement détruite.
En termes de RdP, ce bloc, qui n’a pas de sortie, équivaut à une transition puit, c'est-à-dire,
une transition sans place située en aval.
36
c) Delay (issu du template Advanced Process) : Un bloc Delay permet de retarder le passage
d'entités. Celui représenté dans la figure suivante est intitulé Delay 1 (champ Name = Delay
1), quand une entité entre dans ce bloc, elle y reste inconditionnellement pendant la durée
(aléatoire ou non) indiquée dans le champ Delay Time.
Delay Time
Le nombre de jetons présents dans la place correspond au nombre d'entités présentes dans le
bloc Delay.
d) Seize (issus du template Advanced Process) : Une entité présente dans un bloc Seize ne
peut sortir de ce bloc que s’il existe un nombre suffisant de ressources disponibles (le nombre
et le type de ressources étant spécifiés dans le bloc) ; en attendant l’entité est stockée
(« patiente ») dans une file d’attente interne au bloc Seize. Le fait qu'une entité sorte du bloc
indique que les ressources, disponibles en nombre suffisant, sont « saisies » (et donc plus
disponibles).
Le bloc représenté dans la figure suivante est intitulé Seize 1 (champ Name = Seize 1). Pour
simplifier la compréhension, considérons que seulement un type de ressource est concerné
(dans l’exemple, Resource 1), alors :
- le nom de la ressource est spécifié dans le champ Resource Name, soit Resource Name =
Resource 1 (l’ajout d’un autre type de ressource donnerait lieu à une ligne supplémentaire
dans la liste Resources),
- le nombre (minimum) de ressources (de type Resource 1) disponibles est spécifié dans le
champ Quantity, par exemple Quantity = 1.
Sachant qu'une ressource peut ne pas être disponible, les entités, en attente d'un nombre
suffisant de ressources disponibles, sont stockées dans une file d'attente, intégrée (en amont)
au bloc Seize, et dont le nom est indiqué dans le champ Queue Name (soit Queue Name =
Seize 1.Queue).
37
Le RdP suivant permet de décrire un bloc Seize dans le cas où un seul type de ressource (dans
l’exemple, Resource 1) est requis.
File d’attente Saisie de (Quantity = 1) ressources
(Seize 1.Queue) (Resource Name = Resource 1)
Quantity ressources
Entrée d'une entité disponibles
dans le bloc Seize
P2
Sortie de l'entité
T du bloc Seize
P1
Le nombre de jetons présents dans la place P1 correspond au nombre d'entités présentes (en
attente) dans le bloc Seize.
Une file d’attente est caractérisée (configurée) par le bloc Queue (issu du template Basic
Process, appartenant au cadre expérimental et donc non traversé par une entité), voir la
figure suivante :
38
- le champ Name permet de déclarer une file d’attente, par exemple Seize 1.Queue,
- le champ Type permet d’indiquer le mode de gestion de la file d’attente. Par défaut, le
mode de gestion est de type First In, First Out (FIFO).
Le bloc Queue permet de définir plusieurs files d'attente dans un même modèle.
Les types de ressource, ainsi que le nombre pour chaque type de ressources, sont indiqués
dans le bloc Resource (issu du template Basic Process, appartenant au cadre expérimental
et donc non traversé par une entité), voir la figure suivante :
- le champ Name permet de déclarer une ressource, par exemple Resource 1,
- le champ Capacity permet de définir le nombre d’unité de la ressource, par exemple 1.
Le bloc Resource permet de définir plusieurs types de ressources dans un même modèle.
e) Release (issu du template Advanced Process) : Un bloc Release permet de « relâcher » des
ressources. Celui représenté dans la figure suivante est intitulé Release 1 (champ Name =
Release 1). Quand une entité entre dans ce bloc, elle libère (relâche) la, ou les ressources dont
le nom est spécifié dans le champ Resource Name, par exemple Resource 1, le nombre de
ressources libérées est spécifié dans le champ Quantity, par exemple 1. On peut noter que
l’exécution de cette tâche est instantanée, autrement dit le temps de passage d’une entité dans
un bloc Release est nul. Pour simplifier, seul un type de ressource est concerné (dans
l’exemple, Resource 1), l’ajout d’un autre type de ressource donnerait lieu à une ligne
supplémentaire dans la liste Resources.
39
Le RdP suivant permet de décrire un bloc Release dans le cas où un seul type de ressource
(dans l’exemple, Resource 1) est libéré.
P1
ressources Quantity
disponibles
f) Assign (issu du template Basic Process) : Un bloc Assign permet d’assigner une valeur,
notamment, à un attribut, une variable (éventuellement propre à SIMAN, par exemple relative
à l’état d’une ressource), durant l’exécution d’une simulation. Quand une entité entre dans un
bloc Assign, l’expression - logique ou mathématique - spécifiée dans le champ New Value est
évaluée et assignée, selon le contenu du champ Type (Attribute, Variable, …), à un attribut
(rattaché à l’entité « activant » le bloc) ou une variable. Dans la figure suivante, le bloc
intitulé Assign 1 (champ Name = Assign 1) permet de déclarer :
- une variable Variable 1 à 1 ;
- un attribut Attribute 1 à TNOW ;
- une variable Variable 2 à STATE(resource 1). La variable STATE(resource 1) restitue
l’état courant de la ressource resource 1 (les valeurs possibles sont : -1=Idle ; -2=Busy ;
-3=Inactive ; -4=Failed) ;
- une Variable 3 à Attribute 1.
Cet exemple est proposé dans \Exemples\Assign\Assign.doe.
40
Le RdP suivant permet de décrire le bloc Assign 1.
Variable 1 := 1
Attribute 1 := TNOW
Variable 2 := STATE(resource 1)
Variable 3 := Attribute 1
Le bloc Variable (issu du template Basic Process, appartenant au cadre expérimental et donc
non traversé par une entité) permet de déclarer des variables.
g) Decide (issu du template Basic Process) : Un bloc Decide permet d’aiguiller un flux
d’entités vers différents blocs de destination, il comporte une entrée et plusieurs sorties.
L’aiguillage est réalisé, selon le contenu du champ Type, d’après un critère de type condition,
41
ou probabilité. Les conditions sont par exemple basées sur des valeurs d’attributs, de
variables, une expression. Le routage se fait via un ensemble de branches.
Quand une entité entre dans un bloc Decide, chaque condition de branchement est testée de
manière séquentielle (i.e., dans l’ordre de leurs déclarations dans le bloc). La branche
sélectionnée par une entité est la première branche pour laquelle la condition de branchement
est satisfaite ; l’entité est alors aiguillée vers le bloc correspondant. Si aucune branche n’est
satisfaite, l’entité est détruite. Un bloc Decide, intitulé Decide 1 (champ Name = Decide 1),
est décrit dans la figure suivante. Le critère d’aiguillage vers les 2 sorties possibles est réalisé
à partir de la condition If Variable 1 >= 1 (avec un résultat True ou False).
Le critère utilisé par le bloc Decide 2 est de type probabilité (2 sorties, ayant chacune une
probabilité égale à 0.5, sont possibles).
42
Le RdP suivant permet de décrire un bloc Decide.
Notons que toutes les sorties d’un bloc Decide doivent être connectées à un bloc
(éventuellement un bloc Dispose si la sortie n’est pas « utile »).
Match 1.Queue1
Le bloc Queue (issu du template Basic Process) décrit ci-dessous indique la définition des
files d’attente Match 1.Queue1 et Match 1.Queue2.
43
Voir une description du bloc Match 1 à l'aide du RdP suivant.
synchronisation
Entrées du Match 1.Queue1 Sorties du
bloc Match bloc Match
Match 1.Queue2
Notons que toutes les sorties d’un bloc Match doivent être connectées à un bloc
(éventuellement un bloc Dispose si la sortie n’est pas « utile »).
i) Batch (issu du template Basic Process) : Un bloc Batch permet de regrouper des entités
entre-elles. Les entités une fois regroupées génèrent la sortie d’une entité (notons que cette
entité peut avoir un nouveau Type d’entité, ce qui peut être indiqué dans le champ
Representative Entity Type). Le groupement peut être réversible (ou non) selon que le champ
Type = Temporary (ou Permanent) : un regroupement réversible (Temporary) permet – en
utilisant un bloc Separate - de dégrouper par la suite les entités. Le nombre nécessaire
d’entités pour former un groupe est indiqué dans le champ Batch Size. Une entité arrivant
dans un bloc Batch est placée dans la file d’attente associée au bloc, ceci tant que le nombre
d’entités accumulées dans la file d’attente n’est pas suffisant pour effectuer un regroupement.
Le champ Rule assigné à la valeur By Attribute permet d’effectuer le regroupement d’entités
en fonction d’un attribut, dans le cas contraire (cas par défaut) le champ Rule est assigné à la
valeur Any Entity.
Un exemple est décrit dans la figure suivante :
44
Le RdP suivant décrit le comportement du bloc Batch 1.
Entrée du Sortie du
bloc Batch bloc Batch
Batch Size
(2)
j) Separate (issu du template Basic Process) : Un bloc Separate permet de dupliquer des
entités lorsque le champ Type = Duplicate Original. Le nombre de duplication créée est
spécifié dans le champ # of Duplicates. Lorsqu’une entité entre dans ce bloc et comporte des
attributs, les attributs de toutes les entités dupliquées sont identiques aux valeurs courantes
des attributs de l’entité à dupliquer. L'entité originale sort par la sortie Original, les # of
Duplicates entités (celles dupliquées) sortent par la sortie Duplicate. Un bloc Separate,
intitulé Separate 1 (champ Name = Separate 1), est décrit dans la figure suivante. Un
exemple est donné dans \Exemples\Separate\Separate.doe.
45
Le RdP qui suit permet de décrire un bloc Separate.
Entrée de
Sortie de l’entité
l‘entité
originale
# of
Duplicates Sortie de
(# of Duplicates)
entités dupliquées
46
plusieurs ressources (voir le cadre Resources pour assigner le type, ainsi que le nombre,
de ressources concernées) durant un temps (relatif au temps de traitement) minimum
indiqué dans le cadre Delay (le relâchement de la/les ressource(s) est supposé réalisé en
aval).
3i) Seize Delay Release, le bloc Process se ramène à la mise en série des blocs Seize, Delay
et Release. Il permet de simuler un process (machine, guichet de banque) nécessitant une,
voire plusieurs ressources (voir le cadre Resources pour assigner le type, ainsi que le
nombre, de ressources concernées) durant un temps (relatif au temps de traitement)
minimum indiqué dans le cadre Delay, temps au-delà duquel la, voire les ressources
« saisies » sont relâchées (opération réalisée dans le bloc Release).
4i) Delay Release, le bloc Process se ramène à la mise en série des blocs Delay et Release.
Son comportement correspond au cas 3i) sans la gestion de l’allocation de la/les
ressource(s) nécessaire(s) au traitement (cette gestion est supposée réalisée en amont du
bloc).
Le RdP correspondant au cas i) est décrit au VIII.2.c. Les RdP correspondant au cas 2i, 3i, 4i
sont issus de concaténation des RdP décrits au VIII.2.c,d,e.
Les blocs décrits au VIII.2 permettent de modéliser un système physique, sans pour autant
fournir d’informations (exceptées celles données par défaut dans le rapport final). La collecte
d’informations spécifiques se fait en utilisant des blocs supplémentaires. Quelques-uns de ces
blocs sont décrits ci-dessous. Un exemple est donné dans le fichier
\Exemples\Record_Statistic\Stat_File.doe.
1) Le bloc Record (issu du template Basic Process) permet, selon le contenu du champ Type,
de :
- compter le nombre d'entités traversant le bloc (Type = Count) (voir 1.a)) ;
- recueillir les temps de passage successif de 2 entités (Type = Time Between) (voir 1.b)) ;
- recueillir les temps mis par les entités traversant une partie (ou l'ensemble) d'un modèle
(Type = Time Interval) (voir 1.c)).
1.a) Lorsque le champ Type = Count, le bloc Record permet de compter le nombre d'entités
qui transitent par ce bloc. Le compteur s'incrémente d'une valeur (Value, par défaut égale à 1)
à chaque passage d'une entité. Le nom du compteur est spécifié dans le champ Counter Name.
Voir le bloc Statistic (voir 2.b) pour effectuer un enregistrement des données.
47
transition
compteur = + 1
1.b) Lorsque le champ Type = Time Between, le bloc Record permet de recueillir les temps de
passage entre 2 entités successives. Le nom du tally8 est spécifié dans le champ Tally Name.
Voir le bloc Statistic (voir 2.b) pour effectuer un enregistrement des données.
transition
X
X(k + 1) - X(k)
X(k) : tps de
franchissement
de l’entité n° k
1.c) Lorsque le champ Type = Time Interval, le bloc Record permet de recueillir les temps
mis par les entités traversant une partie (ou l'ensemble) d'un modèle. Le nom du tally est
spécifié dans le champ Tally Name.
Par exemple, on souhaite pour chaque entité recueillir la différence entre le temps de sortie du
bloc M et le temps de sortie du bloc N. Soient t N (i), t M (i) les temps de sortie de l'entité n° i des
blocs N et M respectivement (cf. schéma suivant).
Bloc N Bloc M
tN (i) tM (i)
8
"To keep a tally of …" signifie "tenir le compte de …".
48
- Un bloc Record 1 (avec Type = Time Interval) placé juste après le bloc M afin de
disposer des temps de parcours de la sortie du bloc N au bloc M. Le lien avec l'attribut
Attribute 1 se fait via le champ Attribute Name.
Voir le schéma suivant pour avoir une vue schématique des blocs N, Assign, M, Record et la
figure suivante où est décrit un bloc Record de Type Time Interval.
Assign Record 1
Bloc N (Attribute 1 Bloc M (Attribute
= TNOW) Name =
Attribute 1)
tN (1),
tN (2), tM (1),
. tM (2),
. .
tM (1) - tN (1), .
tM (2) - tN (2),
.
.
49
a) On accède à différents types de données statistiques selon la configuration du bloc
Statistic :
i) A travers une statistique, notée Statistic 1, on peut disposer de la moyenne, du minimum, du
maximum du nombre d’entités présentes dans la file d’attente, par exemple,
Process 1.Queue. Pour cela, prendre la configuration suivante :
champ Name = Statistic 1, champ Type = Time-Persistent, champ Expression =
NQ(Process 1.Queue) (voir figure ci-dessous).
2i) A travers une statistique, notée Statistic 2, on peut disposer de la moyenne, du minimum,
du maximum du nombre de ressources, par exemple, Resource 1, occupées. Pour cela,
prendre la configuration suivante :
champ Name = Statistic 2, champ Type = Time-Persistent, champ Expression =
NR(Resource 1) (voir figure ci-dessous).
3i) A travers une statistique, notée Statistic 3, on peut disposer de données statistiques de la
file d'attente, par exemple, Process 1.Queue, classées par catégorie, avec pour chacune des
catégories, son nombre d'occurrences, le temps moyen de chaque occurrence et le pourcentage
des temps d'occurrences par catégorie. Considérons, par exemple, les 3 catégories suivantes :
- Vide lorsque la file d'attente ne contient pas d'entité ;
- Moitie chargee lorsque la file d'attente contient entre 1 et 10 entités ;
- Chargee au-delà de 10 entités.
Pour cela, prendre la configuration suivante :
champ Name = Statistic 3, champ Type = Frequency, champ Frequency Type =
Value, champ Expression = NQ(Process 1.Queue), 3 lignes à définir dans le
champ Categories, à savoir :
4i) A travers une statistique, notée Statistic 4, on peut disposer de données statistiques de la
ressource, par exemple Resource 1, classées par catégorie, avec pour chacune des catégories,
son nombre d'occurrences, le temps moyen de chaque occurrence, et le pourcentage des temps
d'occurrences par catégorie. Considérons, par exemple, les 4 catégories suivantes :
- Zero lorsque la ressource est libre ;
- Une lorsqu'une (seule) ressource est occupée ;
- Deux lorsque 2 ressources sont occupées ;
- Trois lorsque toutes les ressources (c'est-à-dire, 3) sont occupées.
Pour cela, prendre la configuration suivante :
50
champ Name = Statistic 4, champ Type = Frequency, champ Frequency Type =
Value, champ Expression = NR(Resource 1), 4 lignes à definer dans le champ
Categories, à savoir :
51
de l'évolution des variables, des attributs (par exemple, le contenu d'une variable
indiquant le temps de traitement d'une machine, l'état d'un stock).
L'animation est un moyen très efficace de communication. D'un abord facile, notamment pour
les décideurs non nécessairement initiés aux aspects techniques, elle permet - sous réserve
bien sûr que les conditions de simulation soient crédibles - de mettre en avant les phénomènes
étudiés. Elle permet également lors de la conception du modèle de simulation de vérifier son
bon fonctionnement à travers une visualisation étape par étape (voir commande Step ►| ) du
cheminement des entités dans le modèle de simulation.
Une animation, rattachée aux connecteurs, est proposée par défaut (voir option Animate
Connectors dans le menu Object). Elle permet de visualiser le flux des entités le long des
connecteurs, i.e., les liens reliant les modules entre eux :
connecteur
Create
0 Process
0
Notons que le mouvement des entités le long des connecteurs n'a pas d'impact sur le temps de
simulation (TNOW).
La simulation de temps de transport nécessite l'utilisation du bloc STATION du template
Advanced Transfer.
L'image initiale utilisée pour représenter un type d'entité donné est définie dans le bloc Entity
(issu du template Basic Process, appartenant au cadre expérimental et donc non traversé par
une entité). L'image est par défaut celle notée Picture.Report et est indiquée dans le champ
Initial Picture du module Entity. Le changement de l'image associée à une entité se fait via
son passage dans un bloc Assign en assignant une nouvelle image à l'attribut Entity Picture
(par exemple, Type : Entity Picture, Entity Picture : Picture.Truck).
Le menu Edit/Entity Picture permet d'accéder à d'autres images (contenues dans des fichiers
.plb). Le bouton Open permet d’ouvrir un fichier .plb particulier, lequel contient des images.
Par exemple, le fichier machine.plb met à disposition des images relatives à des machines.
Il est également possible de créer ses propres images, lesquelles seront sauvegardées dans un
fichier .plb. Pour créer une image, cliquez sur le bouton Add de droite, ce qui fait apparaître
une case grise. Le fait de double cliquer dans cette case permet d’ouvrir une fenêtre (Picture
Editor) où il est possible de concevoir une image. Fermer la fenêtre une fois l’image conçue ;
elle apparaîtra alors à la place de la case grise. Le bouton Save permet de sauvegarder dans un
fichier .plb de votre choix la, voire les images créées.
Cette barre d'outils fournit une interface avec les objets de base de l'animation (cocher la case
Animate de la fenêtre issue du menu View/Toolbars… pour faire apparaître – si nécessaire –
cette barre d'outils).
52
Affichage d'état : Clock Date Variable Level Histogram Plot
- Zone d'attente :
- Queue permet d'afficher les entités en attente d'un événement spécifié (par exemple, la
disponibilité d'une ressource).
- Image :
- Resource permet de disposer d'un objet (par exemple, une machine) à capacité limitée
pouvant être alloué à des entités. Une ressource peut être dans l'état idle, busy ou
inactive. Durant la simulation, l'image d'une ressource change en fonction de son état.
- Global permet d'associer des images à une expression (variable, attribut). Durant la
simulation, l'image de l'expression change en fonction sa valeur par rapport à une
valeur spécifiée.
Les objets de cette barre d'outils permettent l'ajout de dessins statiques, ou de texte :
Line Polyline Arc Bezier curve Box Polygon Ellipse Text Couleur
53
VIII.5 DONNÉES D'ENTRÉES
Le module Input Analyser d'ARENA permet l'exploitation de données d'entrées en
déterminant automatiquement la loi de probabilité la plus adaptée de la distribution empirique
obtenue à partir des données d'entrée (regroupées dans un fichier).
Les données d’entrées sont contenues dans un fichier au format .dst où une ligne contient un
nombre (réel). En fait, ce fichier est de type texte et donc lisible, par exemple, via le
WordPad. Voir, à titre d’exemple, le fichier test1.dst, ou test2.dst, dans le répertoire
\Exemples\Distribution. Pour analyser un fichier de données (.dst), faire : Rockwell
Software/Arena/Input Analyzer afin d’ouvrir l’application Input Analyzer. Une fois dans cette
application, faire : File/New afin d’ouvrir une fenêtre Input1. Après avoir cliqué dans la
fenêtre grisée, faire File/Data File/Use Existing…9, ce qui permet de récupérer le fichier (.dst)
contenant les données à convertir en une loi de distribution : il en résulte l’affichage d’un
histogramme des données.
Dans la fenêtre grisée, sont décrites des informations relatives aux données (le nombre de
données, les valeurs minimale et maximale, la moyenne, l’écart type) et à l’histogramme (la
portée (la plus petite valeur et la plus grande valeur considérées dans l’histogramme), le
nombre d’intervalles (en O( nbre de pts ) et compris entre 5 et 40)).
9
A ce niveau, vous pourriez créer un fichier de données (.dst) correspondant à une certaine
distribution en sélectionnant Generate New….
54
Pour modifier les paramètres de l’histogramme des données, à savoir le nombre d’intervalles,
la borne inférieure (les données ayant des valeurs inférieures étant ignorées) et la borne
supérieure (les données ayant des valeurs supérieures étant ignorées), faire :
Options/Parameters/Histogram….
Pour trouver la meilleure distribution correspondant à cet histogramme, faire : Fit/Fit All10.
10
« To fit » signifie « ajuster ».
55