UNIVERSITE DE BATNA
Faculté des Sciences de l’Ingénieur
Département d’Informatique
Modélisation & Simulation
sur Ordinateur
Docteur Brahim BELATTAR
Doctorat Nouvelle thèse en informatique
Diplômé de l'Université Claude BERNARD de Lyon I-France
Maître de Conférence au Département d’Informatique
Faculté des Sciences de l’Ingénieur
Université de Batna
Année universitaire 2003/2004
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
SIMULATION DES SYSTEMES : UNE INTRODUCTION
1. INTRODUCTION
La simulation est aujourd’hui largement reconnue comme une technique
puissante pour l’analyse et la conception des systèmes. Elle peut être appliquée dans
divers domaines tels que l’analyse des systèmes de services (Banques, téléphonie,
...), les systèmes de production (ou de fabrication), les systèmes naturels
(biologiques, écologiques,...), les systèmes informatiques (d’exploitation, de
communications, etc.).
L'étude scientifique d'un système nous amène dans la plupart des cas a faire un ensemble
de suppositions sur le fonctionnement du système.
Ces suppositions, prennent
habituellement la forme de relations mathématiques ou logiques, constituent un modèle qui
est utilisé pour essayer de comprendre comment le comportement du système étudié.
Si les relations qui composent le modèle sont assez simples il peut être possible d'utiliser
des méthodes mathématiques (telle que l'algèbre, la theorie des probabilité) pour obtenir
des responses exactes aux questions qui nous intéreseent. Une telle solution s'appelle une
solution analytique. Cependant, les systèmes qu'on trouve dans la réalité sont le plus
souent trop complexes pour pourvoir se preter a une évaluation analytique, et leurs
modèles doivent être étudiés au moyen de la simulation. Dans une simulation on utilise
l'ordinateur pour évaluer numériquement un modèle et des données sont colloectées dans
le but d'estimer les caractéristiques souhaitées du modèle.
A titre d'exemple, si une entreprise industrielle prevoit faire une extension de son
usine mais n'est pas sûr si le gain potentiel dans la productivité justifierait le coût de la
construction peut recourrir a une étude par la simulation. En effet, il ne serait surement pas
rentable en terme d'argent que l'entreprise procède a l'extension puis l'enlèver plus tard s'il
elle est jugée non satisfante. Cependant une étude par la simulation pourrait éclairer sur la
question en simulant le fonctionnement de l'usine dans son état avant l'extension et puis
avec l'extension. Ceci pourra etre fait sans que cela necessiterait des changements
physiques dans l'usine.
Les domaines d'application de la simulation sont nombreux et variés. Une liste non
exhaustive de problemes pour lesquels la simulation s'est averée un outil utile et puissant
sont :
•
•
•
•
Concevoir et analyser des systèmes industriels
Evaluer du hardware et du logiciel pour un système d'exploitation d'ordinateur
Evaluer un nouveau système d'armes militaire ou tactique
Déterminer des politiques d'ordonnancement pour un système de production
• Concevoir des systèmes de communications et leurs protocoles
• Concevoir et améliorer des installations de transport tel qu'autoroutes,
aéroports, métros, ou ports, etc.
• Evaluer des politiques de gestion pour les organisations de service tel
qu'hôpitaux, bureaux de poste, etc.
• Analyser des systèmes financiers ou économiques
Beaucoup d'etudes ont montré que la simulation figurait parmi les techniques les plus
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
utilisées a travers le monde. Cependant, plusieurs obstacles n'ont pas favorisé une plus
large utilisation de la simulation. En premier lieu, les modèles utilisés pour étudier les
systèmes à grande échelle ont tendance a être très complexe, et leur traduction sous forme
de programme pour les exécuter peut être une tâche ardue. Cette tâche a été beaucoup
simplifié durant ces derniéres années grace au développement d'excellents logiciels qui
offrent en standad beaucoup de possibilités necessaires pour coder un modèle de la
simulation. Un deuxième problème avec simulation des systèmes complexes est qu'ils
exigent souvent beaucoup de temps sur ordinateur mais cet obstacle est devenu moins
sévère aujourd'hui a cause de la diminution des prix (materiel) et l'augmentation de la
puissance de calcul.
De la on peut souligner que la simulation en tant que méthode ne doit en aucun cas etre
vue comme un simple travail de programmation sur ordinateur quelque soit la complexité du
système a analyser. Elle doit obéir a une approche méthodologique qui est en grande partie
indépendante du logiciel et du matériel qu'on utilise.
2. NOTIONS DE SYSTEME , MODELE et SIMULATION
Les trois notions de système, Modèle et Simulation sont intrinsèquement liées.
Nous allons définir de manière plus ou moins précise chacune d’elles avant de
présenter les concepts de base des techniques de simulation.
2.1 NOTION DE SYSTEME
Le mot ‘‘système’’ couvre un champ d’application immense et de nombreuses
définitions lui ont été attribuées dans la littérature. En voici une liste non exhaustive :
• Ensemble de composants reliés entre eux
• Ensemble organisé d’éléments fonctionnels
• Combinaison de parties qui se coordonnent, pour concourir à un résultat
de manière à former un ensemble (Larousse)
• Combinaison d’hommes, de machines, de matériaux et d’informations
destinée à satisfaire un objectif donné
Le plus important pour nous n’est pas d’énoncer une définition précise du terme
mais d’essayer de faire ressortir les mots clefs qui nous semblent bien caractériser
cette notion de système. De là, on peut dire qu’un système est caractérisé par :
c’est un tout composé de parties ordonnées
chaque partie a ses lois et une certaine indépendance
les parties ont des liens ou relations entre elles
cet ensemble change au cours du temps
il est influencé par le milieu dans lequel il existe et qui réagit sur lui
l’ensemble est le plus souvent soumis à des contraintes
l’ensemble a ses lois propres et n’existe que pour atteindre un but
Ces caractéristiques font ressortir qu’un système est défini par :
• la connaissance de ses parties ou composants
• la connaissance des lois propres de chaque composant
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
• la connaissance des lois d’interaction qui déterminent son but
2.1.1 Définition d'un système
Comme définition d'un système nous retenons celle donnée par l'AFCET et qui
s'énonce comme suit :
"Un système est une entité complexe traitée (eu égard à certaines finalités)
comme une totalité organisée, formée d'éléments et de relations entre ceux-ci, les uns et
les autres étant définis en fonction de la place qu'ils occupent dans cette totalité et cela
de telle sorte que son identité soit maintenue face à certaines évolutions."
La complexité d'un système provient du fait qu'il peut comporter beaucoup de
sous-systèmes interconnectés et pouvant avoir des objectifs en conflit. L'analyste doit
disposer de méthodes et d'outils capables de représenter ces systèmes, sans recourir à
une simplification grossière, origine d'une perte d'information ; ni à la construction de
modèles complexes, inexplicables par la suite à cause d'un manque de documentation,
de problèmes de validation des modèles, ou de portabilité de programme.
Exemple :
Une usine de production constitue un très bon exemple de système dont les parties
pourraient être :
• main d’oeuvre
• service achats
• service approvisionnement
• service de gestion de stocks
• service Fabrication
• service Ventes
• service Ordonnancement de la production
• service Administratif
Chacune de ses parties a ses lois (règles de fonctionnement) et est partiellement
indépendante des autres mais aussi fonction des autres et réagit sur elles. La
connaissance des lois d’interaction et leur application à l’ensemble va influer
directement sur le but à atteindre (rentabilité, investissement, bénéfice,...) par le
système.
L’identification des frontières du système avec son environnement (milieu)
permettent de délimiter la portée du système.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Fig1 : le systéme et son environnement
Les frontières d'un système peuvent être physiques; cependant il serait plus juste
de parler des relations de cause à effet entre un système et son environnement.
Certains facteurs externes peuvent influencer le système. Si ces facteurs contrôlent
entièrement la dynamique du système , il n’ y a pas d’intérêt à conduire des
expérimentation avec ce système et il faudra redéfinir le système. Si par contre ces
facteurs contrôle partiellement la dynamique du système, On peut alors soit :
- élargir le système de façon à les inclure
- les ignorer (si on juge que leurs effets sont négligeables)
- les considérer comme des entrées du système
2.2 MODELE ET MODELISATION
La modélisation consiste à construire une représentation simplifiée d'un système appelée
généralement : modèle.
2.2.1 Définition
Une définition d'un modèle énoncée par l'AFCET , est la suivante :
"Un modèle est un schéma, i.e. une description mentale (intériorisée),ou figurée
(diagrammes, formules mathématiques, etc ... qui, pour un champ de questions est pris
comme représentation abstraite d'une classe de phénomènes, plus ou moins habilement
dégagés de leur contexte par un observateur pour servir de support à l'investigation,
et/ou la communication".
Un modèle est donc une représentation d’un système (réel ou imaginé) dont le
but est d’expliquer et de prédire certains aspects du comportement de ce système.
Cette représentation est plus ou moins fidèle car d’une part le modèle devra être
assez complet afin de pouvoir répondre aux diverses questions qu’on peut se poser
sur le système qu’il représente et d’autre part il ne doit pas être trop complexe pour
pouvoir être facilement manipulé. Ceci implique immédiatement qu’il y a intérêt à bien
définir les limites ou frontières du modèle qui est censé représenter le système.
Exemple : Un projet de construction d’un avion comprend les étapes suivantes
1) Dessine un avion prototype puis on construit un modèle grandeur nature mais
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
en utilisant du bois et du contre-plaqué
Ce modèle va servir pour étudier (expliquer) certains aspects de l’avion (disposition
des sièges, encombrement des cabines, ...)
Dans ce modèle, certains facteurs sont négligés : poids de l’avion, types des
matériaux de construction, ... Ils n’ont pas d’importance pour les questions auxquelles
ont veut répondre.
2) On construit des modèles réduits de l’avion en utilisant les vrais matériaux.
Ces modèles vont servir à expliquer certains aspects (test résistances des matériaux,
vitesses en vol , à l’atterrissage, ....)
3) On construit un premier ''vrai'' avion grandeur nature pour essai. Des résultats
issus des essais en vol sont recueillis, puis comparés à ceux obtenus à l’aide des
modèles réduits. Une mise à jour de nouveaux paramètres est faite et les tests avec
les modèles réduits sont refaits.
De la on peut dire qu’un modèle n’est pas identique en tout point au système qu’il
modélise. En effet, si tel était le cas, le modèle serait sans intérêt car il serait aussi
simple de travailler directement sur le système.
Les principaux avantages de manipuler un modèle plutôt que le système qu’il
modélise sont :
Un modèle évite la construction d’un système qui n’existe pas
Un modèle évite de faire des expérimentation directes sur un
système existant (problèmes de sécurité , ou économiques)
2.2.2 Processus de modélisation
Le processus de construction d’un modèle de simulation peut être schématisé comme
suit :
Fig2(a) : Processus de Modélisation
(Voir les explications dans le § étapes d’une simulation)
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Un autre schéma distinguant entre modele conceptuel et modele programmé sur
ordinateur est le suivant :
Fig2(b) : Processus simplifié de Modélisation
Le modèle conceptuel est une représentation (mathématiques logique, verbale, etc
... du système réel (ou retenu pour une étude particulière). Il est obtenu dans une phase
d'analyse et de modélisation. Le modèle programmé est la mise en oeuvre du modèle
conceptuel sur un calculateur. Il est obtenu dans une phase de programmation et de
mise en oeuvre. Les enseignements sur le système réel sont obtenus à la suite
d'expérimentations sur le modèle programmé dans une phase d'expérimentation.
2.2.3 Construction d'un modèle
La construction d'un modèle consiste, à partir d'une représentation mentale du
système liée à une certaine connaissance qu'en a acquis le modélisateur, à développer un
modèle sous forme de programme d'ordinateur ou sous forme plus communicable,
aisément translatable en programme d'ordinateur. Ainsi, c'est au modélisateur que revient,
guidé par les méthodes d'analyse et les outils conceptuels, un certain nombre de choix dont
dépend le succès de l'étude:
• Définition des frontières du modèle et donc des variables internes,
d'entrées et de sorties nécessaires ;
• Appréciation du niveau de détails à incorporer dans le modèle
• Choix des techniques de modélisation.
Deux méthodes complémentaires sont couramment employées pour la construction
d'un modèle :
- l'affinage progressif (descendante): Appelée aussi méthode de
modélisation par accumulation de degrés de complexité. Elle procède par itérations vers
des niveaux de complexité croissante. Ce processus évolutif permet de prendre en compte
les insuffisances du modèle à une étape donnée, de les améliorer à l'étape suivante, tout
en évitant d'entrer dans un niveau de détails superflu.
- l'accumulation de sous-modèles (ascendante): Utilisée lorsque le
système à étudier est de taille importante. Les sous-modèles sont issus d'un découpage du
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
système en sous-systèmes distincts. La complexité du système est alors mieux maîtrisée
mais l'étape d'intégration conduit à des problèmes d'interfaces souvent délicats. De plus, la
démarche étant ascendante, il faut veiller à ne pas sur-ou-sous-évaluer certains facteurs.
Il faut noter ici que quelque soit la méthode utilisée, le modèle doit être finalisé selon
le point de vue adopté et le but recherché. Il ne saurait donc exister de modèle
universel d'un phénomène, transposable au gré d'une utilisation souhaitée (voire les
modeles de l’avion)
2.2.4 Classification des modèles
De nombreux critères peuvent être employés pour classifier les modèles.
simulation, on s’attache généralement a distinguer les types de modèles suivants :
En
Les modèles physiques : sont ceux dans lesquels le système réel est représenté
par une réplique ou maquette, à une échelle différente et éventuellement à l’aide de
matériaux différents (exemple : maquette de véhicules pour les essais aérodynamiques
en soufflerie).
Les modèles symboliques : ou abstraits sont une abstraction mathématisée de la
réalité. Ils sont en général exécutés sur un calculateur, qu’il soit analogique ou digital.
Une autre distinction concerne la prise en compte des aléas dans le modèle. Dans
certains cas, qualifiés de déterministes, leur influence est considérée comme
négligeable. Le plus souvent, ils doivent être représentés car ils jouent un rôle significatif
(exemple typique : les pannes de machines dans un atelier). On a alors affaire à des
modèles stochastiques.
Une troisième dichotomie sépare les modèles statiques et les modèles
dynamiques. Dans les modèles statiques, le temps n’intervient pas (exemple : modèle
comptable permettant de calculer un profit en fin d’exercice à l’aide d’un tableur). Dans
les modèles dynamiques, le temps est un facteur essentiel du comportement et de
l’état du système (exemple : réacteur chimique régi par des équations différentielles).
Enfin, à l’intérieur des modèles dynamiques, on distingue les modèles discrets,
dans lesquels l’état du système ne change qu’à certaines dates (exemple : une file
d’attente devant un guichet), et les modèles continus ou ce changement est permanent
(cas du réacteur déjà cité). Un modèle qui contient à la fois des composantes discrètes
et continues est dit modèle mixte.
Nous nous intéresserons par la suite aux modèles de simulation (modèles abstraits
dynamiques) et plus particulièrement aux modèles de simulation a événements discrets.
2.3 NOTION DE SIMULATION
Etymologiquement, le terme ‘‘simulation’’ est dérivé du mot latin ‘‘SIMULARE’’ qui
veut dire : copier , feindre , faire paraître comme réelle une chose qui ne l’est point.
On peut donc tres bien dire que simuler le fonctionnement d’un système c’est imiter
son fonctionnement au cours du temps en manipulant un modèle. Ceci équivaudrait à la
génération d’un historique artificiel des changements d’état du système et l’observation
de cet historique pour faire des déductions sur ses caractéristiques de fonctionnement.
C’est donc une méthodologie essentiellement pratique qui permet de modéliser aussi
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
bien des systèmes conceptuels (qu’on veut concevoir) que des systèmes existants déjà.
Elle peut être utilisée pour :
• Décrire et analyser la dynamique d’un système
• Répondre aux questions de type «What If ? » sur le système réel
• Aider à la conception d’un système réel
2.3.1 Définition
Beaucoup de définitions ont été attribuées au terme ‘‘Simulation’’ dans la
littérature technique. En voici quelques-unes :
• Expérience conduite sur un calculateur à l’aide d’un modèle
• Méthode numérique pour résoudre un problème en imitant la réalité
• Représentation dynamique de la réalité obtenue en construisant un
modèle et en le manipulant pendant un temps donné
Parmi toutes ces définitions nous retenons celle donnée par A.A.B. Pritsker
auteur du langage SLAM II, et qui s'énonce comme suit :
" La simulation est l'étude du comportement dynamique d'un système, grâce à un
modèle que l'on fait évoluer dans le temps en fonction de règles bien définies, à des fins
de prédiction".
De là on peut dire que le terme de simulation pourrait être caractérisé par les
mots clefs suivants :
Un élément fondamental qui est le modèle
Le modèle est manipulé (sur ordinateur), cette manipulation fournissant
des solutions
Les solutions trouvées sont celles du modèle et non du système
modélisé
Son but est de choisir parmi les solutions celle qui semble être la
meilleure
La simulation peut aussi être vue comme la conduite d’une expérimentation
indirecte (sur le modèle et non sur le système) dans le but de comparer plusieurs
façons de procéder. Elle ne résout pas le problème posé en trouvant la bonne solution.
Elle aide seulement à prendre parmi plusieurs solutions la meilleure possible.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
2.3.2 Expérimentation directe et indirecte
Fig 3(a) Expérimentation directe et indirecte
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Fig3 (b): Expérimentation directe et indirecte
2.3.3 Quand simuler
La simulation est souvent caracrtérisée dans la litterature comme la methode de dernier
ressort. Ceci veut dire que si on a la possibilité de resoudre le probleme posé avec des
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
methodes analytiques, il serait preferable de les utiliser car elles conduisent a des solutions
optimales. En effet, pour un probleme donné et des objectifs fixés, on peut avoir le choix
entre differentes approches pour le resoudre parmi lesquelles il y a la simulation comme le
montre la figure suivante :
6\VWqPH
Fig4(a) : approches pour étudier un système
l’exemple suivant va nous aider a cerner la démarche typique pour le choix d’une
méthode de résolution d’un problème
On dispose d'un reservoir contenant 100 litres d'eau. Le reservoir est muni d'un
robinet qui debite a une vitesse de 1 litre par minute.
Objectifs : On souhaite connaitre le temps que mettera le reservoir pour se vider.
On peut envisager résoudre ce problème par différentes méthodes. Les plus
significatives sont :
a. Par un calcul
Si 1 litre sort du reservoir par minute et qu'il y a 100 litres dans le reservoir , un simple
calcul nous indiquerais que le reservoir se videra au bout de 100 minutes ( i.e. 100
litre / 1 litre/minute )
b. En effectuant des mesures
Supposons que nous ne savons pas calculer et que nous pouvons disposer d'un
chronomètre. On peut se mettre a coté du reservoir , mettre le chronometre en
marche et attendre jusqu'à ce que le reservoir soit vide. Si nous appuyons alors
immédiatement sur le bouton, nous lirons les 100 minutes
c. En simulant le phénomène
Si nous n'avons pas de reservoir du tout , nous pourrions décider de mettre 100
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
grammes de sable dans une petite boîte en carton, faire un trou dans la boîte et
s'arranger de telle sorte que 1 gramme de sable puisse s'ecouler de la boite en 1
minute. Nous mesurons alors le temps que mettera la boîte pour se vider et conclure
que le même résultat serait probablement valide pour le reservoir aussi.
Ces trois méthodes induisent les quatre questions suivantes :
1. Est-ce qu'on simule seulement quand on ne peut pas calculer?
2. Est-ce que l'expérience avec la boîte n'est pas beaucoup faire pour une question si
simple?
3. Peut-on supposer que la boîte est une bonne représentation du rservoir ?
4. Est-ce que Simuler c'est aussi mesurer?
T
1 quand est-ce que nous devons simuler?
Cette question a trait au probleme lui-meme et au choix d'une methode pour le
resoudre. En général, il y a deux voies pour résoudre un problème: analytiquement et
expérimentalement. Pour l'exemple du reservoir la première solution est obtenue par
une methode analytique (un calcul selon une formule), la seconde et la troisième sont
des solutions obtenue par des methodes expérimentales. Il faut remarquer a ce niveau
que les méthodes analytiques donnent souvent une solution optimale, alors que les
méthodes expérimentales mènent souvent à une bonne solution , mais pas
nécessairement a la solution optimale.
2
T
L'expérimentation avec la boîte n'est pas beaucoup faire pour une question si
simple?
Cette question a trait aux objectifs visés. Si nous savons que la simulation est la
seule méthode pour résoudre un problème, nous devons nous demander aussi si les
coûts de l'expérimentation sont justifiables.
3
T
La boîte est-elle une bonne représentation du reservoir ?
cette question a trait a un aspect tres important en simulation , à savoir celui de la
vérification et de la validation d'un modele. Elle vise a etablir si le comportement du
modèle correspond avec celui de la réalité (i.e. le reservoir). modélisée compte tenu
des objectifs visés (temps de vidange du reservoir).
4
T
Est-ce que Simuler c'est aussi mesurer?
On peut dire que oui : simuler c'est aussi mesurer (enregistrer), mais on ne mesure
pas la réalité, mais un modèle de cette réalité. Donc, la simulation n'est pas une
méthode mathématique. La simulation utilise des techniques mathématiques
(particulièrement statistique), mais simplement comme un outil pour mesurer.
Il faut noter aussi que la résolution d'un problème expérimentalement et sans faire de
simulation, exige que le système a étudier existe ce qui n'est pas toujours le cas. Or, il
arrive souvent dans la pratique, qu'on soit amené a se poser des questions sur un système
qui n'existe pas encore en vue de comprendre certains aspects de ce systeme(voire
exemple de l’usine en page 1). De meme qu'il est possible que l'on soit amené a
comprendre les conséquences d'un changement dans un système existant sans pour
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
autant devoir en premier construire le nouveau système. Les deux possibilités pour
resoudre le probleme dans les deux cas sont alors : trouver la solution par simulation ou
analytiquement.
La résolution analytique d'un problème exige que l'on soit capable de décrire le système
entier, y compris la relation entre les sous-systèmes qui le composent, mathématiquement.
Ceci n'est pas toujours possible a cause de la complexité et de l'incertitude relatives au
système a étudier.
/D FRPSOH[LWp
Un système peut être si complexe, avec tellement d'interactions mutuelles entre ses soussystèmes ou composants, qu'il devient impossible (ou extrêmement difficile) de le décrire
en termes de relations mathématiques.
exemple : si dans le problème du reservoir présenté plus haut on stipule que le debit
de l'eau est dépendant du volume d'eau restant dans le reservoir et de la dimension
du robinet, et qu'en plus de tout cela, le robinet se dilate de 10% toutes les 4 minutes,
il est clair que la solution mathématique (analytique) devient plus difficile. On sera
dans ce cas plus porté a opter pour la methode b consistant a mesurer le temps avec
un chronometre car elle est plus simple. Maintenant imaginez un lot de reservoirs en
interaction les uns avec les autres. Ceci complique encore plus le probleme et il
devient evident qu'une approche non-analytique est preferable, parce qu'elle est
moins couteuse(mesurer est plus simple et moins couteux que calculer), ou parce que
l'approche analytique est impossible.
/ LQFHUWLWXGH
La description d'un système en termes mathématiques peut aussi être difficile. Ceci est le
cas meme si le systeme est simple (pas complexe) et que nous sommes confrontés a des
incertitudes sur le systeme.
exemple : Supposons que le reservoir a comme caractéristique spéciale, le fait que le
robinet se bloque quelquefois. On ignore a quel instant le robinet se bloque, ce que
l'on sait c'est qu'il se bloque c'est tout. Ainsi il devient impossible de résoudre le
problème initial (analytiquement ou non-analytiquement). Il est bien sur possible de
mesurer, mais qui nous dit que le prochain résultat sera le même?.
Ce problème peut être résolu seulement si nous savons un peu plus au sujet du
blocage du robinet. Par exemple, si nous avons une information statistique, telle
qu'une distribution de la probabilité de bloquage du robinet, alors nous avons un
problème solvable. La question sera alors de choisir entre une méthode de resolution
analytique ou non-analytique.
En résumé, la résolution d'un problème conduit en premier au choix d'une méthode qui peut
etre analytique ou non-analytiques. Elle peut s'agir aussi du choix d'une méthode
expérimentale celle-ci pouvant etre directe (expérimentation sur le systeme réel) ou
indirecte (expérimentation avec un modèle). Le choix de la simulation comme méthode
(faire une expérimentation avec un modèle) sera a faire si :
- l'expérimentation sur le systeme réel n'est pas possible (systeme n'existe pas)
- l'expérimentation sur le systeme réel n'est pas sans danger (accidents, catastrophes
..ex du simulateur du vol)
- l'expérimentation sur le systeme réel est trop chère (construire une nouvelle usine et
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
découvrir que la conception n'est pas bonne)
Ainsi, le processus du choix de la simulation comme une méthode de résolution peut etre
schématisé comme suit :
Fig4(b) : Démarche de choix d’une méthode de simulation
3. CONCEPTS LIES A LA METHODE DE SIMULATION
Nous allons nous intéresser uniquement à la simulation dite ‘‘à événements
discrets’’ en vue de préciser une terminologie que pas mal d’auteurs présentent
chacun à sa manière, ce qui prête des fois à confusion. Ceci fait, nous nous
intéresserons aux approches de modélisation des systèmes à événements discrets.
3. 1 VARIABLES D’ETAT D’UN SYSTEME
Les variables d’état d’un système sont toutes les informations nécessaires pour
définir ou caractériser ce qui est en train de se passer dans le système à un niveau de
détail suffisant et ce à un instant donné.
La détermination de ces variables est fonction des investigations qu’on veut faire.
Ainsi des variables identifiées comme variable d’états du système dans un cas
peuvent ne pas être les mêmes dans un autre cas ou situation et ce bien que le
système physique soit le même :
Exemple:
Dans une banque, le temps d’inoccupation des guichets n’a pas d’intérêt ou
ne constitue pas une variable d’état du système analysé si on décide
d’affecter un client au premier guichet libre et ce de manière cyclique.
Par contre si on décide d’affecter un client en priorité au guichet qui est resté
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
le plus longtemps inoccupé, alors le temps d’inoccupation des guichets
devient une variable d’état du système.
La détermination des variables d’état d’un système n’est pas une chose facile.
Elles doivent être identifiées au niveau du processus de modélisation et normalement
à ce niveau tout oubli ou omission de variable sera facilement détecté.
Une fois les variable d’état identifiées, on peut souligner une différence
essentielle entre les modèles à événements discrets et les modèles continus en se
basant sur les variables nécessaires pour suivre l’état du système. Dans un modèle à
événements discrets, les variables d’état restent constantes sur des intervalles de
temps et changent de valeurs uniquement à certains points bien définis appelés :
Temps ou instants d’événements. Par contre les modèles continus ont des variable
d’état définies par des équations différentielles ou aux différences qui permettent aux
variables de changer de façon continue au cours du temps.
Il faut noter que dans la pratique, il existe aussi des modèles dits mixtes
événements discrets- continus
3.2 ENTITES, RESSOURCES, ATTRIBUTS
Les entités désignent des objets du système modélisé. Le terme en lui-même
peut désigner aussi bien des objets passifs qui subissent des opérations que des
objets actifs qui réalisent des opérations.
Il est possible aussi de distinguer les entités non pas en fonction de leur capacité
à exécuter des opérations mais de leur capacité de déplacement dans le système.
Les entités qui se déplacent dans le système (ex: clients) au cours de la simulation
sont qualifiées de dynamiques alors que les entités qui ne se déplacent pas et
servent simplement d’autres entités sont qualifiées de statiques (ex : serveur dans
une banque).
Une autre distinction pourrait être faite en fonction du caractère permanent ou
temporaire d’une entité dans le système. Une entité permanente est une entité qui
reste dans le système même lorsque la simulation est terminée (ex: machine ,
serveur). Une entité temporaire est une entité qui subit des opérations et quitte le
système dès qu’elle termine ses opérations.
La distinction qui nous paraît moins ambiguë et facilement compréhensible est
celle désignant des termes spécifiques les entités passives ou temporaire et les
entités actives ou permanentes.
On distingue dans un modèle à événements discrets deux types d’objets :
Les entités : ce sont des objets qui subissent des opérations et se déplacent en
général dans le système (pièces , client dans une banque, message dans un réseau,
....)
Les ressources : ce sont des objets qui exécutent des opérations et en général ne
se déplacent pas dans le système (Machine, Opérateur, Unité centrale, ...).
Cependant, il faut noter qu'il est tout a fait possible de rencontrer en pratique des
objets de type ressource qui se deplacent a l'interieur du systeme tout en exécutant
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
l'opération (chariot transportant une piece dans un atelier).
Une ressource peut être composée d’une ou de plusieurs unités (machine en
plusieurs exemplaires, plusieurs serveurs réalisant en // la même opération, ...). Les
ressources peuvent servir une ou plusieurs entités dynamiques au même moment.
Une entité peut réquisitionner une ou plusieurs unités d’une ressource. Dans le cas
ou le nombre d’unités n’est pas disponibles, l’entité se met en attente ou entreprend
d’autres actions (se diriger vers une autre ressource, éjectée du système, ....). Si par
contre l’entité est autorisée à disposer de la ressource, elle le fait pendant un certain
temps puis libère la ressource.
Il existe plusieurs états possibles pour une ressource. Les deux états minimum
sont : libre ou occupée mais d’autres possibilités existent telles que : en panne ,
bloquée, en famine , ....
Remarque : Il est important de remarquer qu’un objet peut changer de type au
cours de la simulation (i.e. il peut être une ressource et devenir entité s’il avait à
subir une opération sur une autre ressource.
Exemple : un bus transportant des voyageurs. Pour les voyageurs le bus est
un objet de type ressource. Si on a plusieurs bus qui doivent desservir la
meme gare un a la fois, le bus devient une entité pour la ressource ''gare'.
Un objet (entité ou ressource) est caractérisé par un ou plusieurs attributs
auxquels on peut affecter des valeurs. Ainsi les attributs peuvent être considérés
comme des variable locales à l’objet. On distingue cependant, deux types d’attributs :
contiennent les caractéristiques constantes de l’objet (durée de service,
date d’arrivée dans le système, couleur d’une pièce, ...)
Variables : contiennent les caractéristiques changeantes de l’objet (état d’une
ressource, longueur de la file associée à une ressource, temps d’usinage
restant pour une entité...)
Fixes :
Les attributs qui sont intéressant dans une investigation peuvent ne pas l’être
dans une autre. Par exemple si on a des pièces rouges et des pièces bleues à usiner,
l’attribut couleur sera certainement un attribut intéressant. Par contre si on s’intéresse
uniquement au temps de séjour dans le système par toutes les pièces, la couleur
d’une pièce peut ne pas être un attribut important.
3.3 Evénement , Activité , Processus
Au cours d’une simulation, le système passe d’un état à un autre, les entités
subissent des opérations et se déplacent dans le système, les ressources exécutent
des opérations et changent d’état, le temps progresse selon une logique. Nous allons
préciser les notions qui concourent à la réalisation de tous ces changements
dynamiques.
3.3.1 Evénement
Un événement est caractérisé par une date (date d’événement) à laquelle le système
change d’état. On distingue les événements internes au système et externes appelés
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
aussi événements endogènes et événements exogènes.
Exemple :
• Le début de service d’un client est un événement endogène du fait qu’il est
interne au système qu’on est en train de simuler.
• L’arrivée d’un client pour le service est un événement exogène du fait que ce
phénomène est en dehors de la simulation. Cependant l’arrivée d’un client au
service empiète sur le système et doit être pris en considération.
Il est important de souligner que l’identification d’un événement comme étant
significatif ou non dans le contexte des objectifs visés par le modèle est strictement
du ressort de l’analyste.
3.3.2 Activité
A chaque événement les objets concernés s’engagent dans des opérations. Ces
opérations qui sont initiées (ou terminées) à chaque événement sont appelées des
activités. Toute activité est limité à son début et à sa fin par un événement.
Exemple :
• Le début de service d’un client va initier les opérations : extraire client
de la file, servir le client
3.3.3 Processus
Un processus est le regroupement d’une séquence d’événements dans l’ordre
chronologique dans lequel ces événements se produiront. Comme les événements
peuvent initier des activités, un processus peut inclure aussi des activités.
Exemple :
• L’arrivée d’un client , sa mise en file d’attente, son début de service ,
peuvent constituer un processus associé au client.
3.3.4 Relation entre Evénement, Activité, Processus
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Fig5 : Relation entre Evenement, Activité et Processus
Un événement a lieu a un point isolé (instant précis) sur l’axe du temps au
moment duquel des décisions sont prises pour débuter ou finir une activité.
Une activité a lieu à un instant donné et se termine à un autre instant fonction de
sa durée.
Un processus est une séquence d’événements ordonnés dans le temps et peut
comporter plusieurs activités.
3.4 Contrôle du temps dans une simulation
Le contrôle du temps dans une simulation se fait principalement selon l’une des
deux méthodes suivantes : Méthode à pas constant ou Méthode à pas variable
0pWKRGH j SDV FRQVWDQW
appelée aussi : Time slicing , par horloge, orientée temps, Synchrone
C’est une méthode simple et facile à programmer qui consiste à se fixer au début de
la simulation une unité de temps ∆t avec laquelle on incrémentera l’horloge. A chaque
incrémentation on cherche les événements qui peuvent se produire (Date d’occurrence =
[Horloge]) ou les activités qui peuvent démarrer et on les traite. Cette méthode
s’applique surtout pour les modèles décrits par des équations différentielles (continus).
Cependant, elle peut poser des problèmes pour le cas des modèles à événements discrets.
Si le pas ∆t est trop grand, on risque de sauter (ne pas prendre en compte) certains
événements. Inversement, si le pas ∆t est trop petit on risque d’effectuer un très grand
nombre de tests inutiles (car pas de changements d’état à faire) à chaque incrémentation
ce qui augmenterait les temps d’exécution.
0pWKRGH j SDV YDULDEOH
appelée aussi : orientée événements, pilotée par les événements, par échéancier, sans
horloge, asynchrone, Next event
Cette méthode est beaucoup plus économique en terme de temps de calcul. On
répertorie dans un échéancier (calendrier , agenda) par ordre chronologique, la liste des
événements avec leurs dates d’occurrence. L’incrémentation du temps de la simulation
se fait d’une date d’événement à une autre.
Cette méthode est de loin la plus fréquemment utilisée vue son efficacité relativement
à la méthode à pas constant.
$3352&+(6 '( 02'(/,6$7,21 '(6 6<67(0(6 $ (9(1(0(176 ',6&5(76
4.1 Composants d'un modele a evenements discrets
Un modèle est caractérisé par un aspect statique lié à la structure du système
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
modélisé, et par un aspect dynamique lié à l'évolution du système au cours du temps.
4-1-1 Partie statique
Un modèle à événements discrets est composé d'objets ou entités (pièces,
machines, etc ... ) avec lesquelles s'effectuent au cours du temps, des services qui peuvent
être actifs (activités ou opérations) ou passifs (attente), et de relations entre ces objets
(possibilité pour une pièce de passer sur une machine ... ). On distingue en général deux
types d'objets :
- les clients ou usagers : Sur lesquels sont effectués les services (pièces dans
un atelier, clients dans un magasin, informations dans un réseau de transmission, etc ... ) ;
souvent, les clients sont des objets circulants (en particulier dans les systèmes de
production).
- les ressources : Sont nécessaires pour effectuer les services ; ces ressources
peuvent être composées d'une ou plusieurs unités (nombre de machines identiques, de
personnel ayant la même compétence, de chariots, de places dans une file d'attente, etc ...
).
Remarquons que des objets peuvent être, soit des clients, soit des ressources,
selon le problème auquel on s'intéresse. Par exemple, dans un atelier de production un
chariot transportant des pieces sera en général, une ressource mais il deviendra client si on
s'intéresse au fonctionnement détaillé du réseau de transport, les ressources pour les
chariots étant alors les différents cantons du réseau qu'empruntera le chariot dans ses
parcours.
Un objet est caractérisé par un ou plusieurs attributs auxquels des valeurs peuvent
être affectées. On peut distinguer deux types : les attributs fixes qui contiennent les
caractéristiques constante de l'objet (type de machine, taux de panne, type de pièce, durée
d'usinage d'une pièce sur une machine); les attributs variables qui correspondent aux
caractéristiques évolutives dans le temps de l'objet (occupation de la machine, état de
marche, position d'une pièce, nombre de pièces en attente, etc...
De ces définitions standards découle la notion d'état. L'etat d'un objet à un instant
donné est l'ensemble des valeurs de tous les attributs variables de cet objet à cet instant.
L'etat instantané du système sera donc défini par l'ensemble des états de tous les objets à
cet instant.
4-1-2 Partie dynamique
L'aspect dynamique d'un modèle réfère aux mécanismes de changements d'état.
Lorsque le temps évolue, des interactions se produisent entre les objets qui composent le
modèle et ceux-ci changent alors d'état. Ces changements d'état peuvent se faire de façon
continue, discrète, ou une combinaison des deux. C'est ainsi qu'on parle de modèles
"continus", modèles à "événements discrets", et modèles "combinés événements discretscontinus".
4-2 Construction d'un modele a evenements discrets
Pour construire un modèle de simulation à événements discrets, le concepteur doit
choisir une approche de modélisation. Dans la pratique, il existe trois grandes approches
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
(World View) pour modéliser un système.
Si le concepteur a à sa disposition un langage de simulation, dans ce cas l’approche
à utiliser est implicite puisque chaque langage offre normalement une (ou plusieurs
approches). Si par contre, le concepteur utilise un langage de programmation général
(Fortran, ...), alors le choix d’une approche est sous son entière responsabilité. Dans
tous les cas, l’approche utilisée fournit un mécanisme conceptuel pour bien articuler la
description sous forme d’un modèle.
Les trois approches les plus connues sont :
1)
2)
3)
: Event scheduling, Next Event
: Activity Scanning
: Process interaction
Ainsi, un modèle à événements discrets peut être décrit soit :
• en définissant les changements d’état qui ont lieu à chaque événement
• en décrivant les activités dans lesquelles s’engagent les entités
• en décrivant les processus à travers lesquels passent les entités
Ces trois approches de modélisation sont caractérisées par le fait qu’elles conduisent
à des modèles ayant une structure hiérarchique à 3 niveaux qui sont :
S
S
S
niveau 1 :
niveau 2 :
niveau 3 :
Correspond au programme de contrôle de la simulation appelé aussi
exécutif ou noyau
Correspond aux opérations décrivant la dynamique du système
simulé. Du point de vue de l’utilisateur, ce niveau constitue le
modèle de simulation proprement dit
Comprend un ensemble de routines utilitaires
a) Le niveau 1 :
Le noyau est responsable du séquencement des opérations (événements,
activités, processus) qui ont lieu au fur et à mesure que la simulation progresse. Ainsi,
le noyau contrôle le niveau 2 et comprend des routines chargées de :
- Identifier quand aura lieu le prochain événement
- S’assurer que les bonnes opérations aient lieu à cet instant
Dans le cas ou on dispose d’un langage de simulation, le noyau est une partie qui
n’est pas directement accessible au programmeur qui n’a vraiment pas à savoir tous les
détails sur le noyau. Il suffit simplement de savoir que son principe général est de
contrôler le niveau 2 de façon quasi-automatique (appel ou déclenchement des
opérations du niveau 2).
Par contre avec un langage de programmation général(Fortran, Pascal, C,...), il
faudra écrire soit même le noyau et il faudra dans ce cas maîtriser tous les détails de
fonctionnement du noyau.
b) Le niveau 2 :
Ce niveau est à la charge du programmeur est constitue le modèle de simulation du
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
point de vue du programmeur. C’est donc un ensemble d’instructions dont la
structuration dépend de l’approche de modélisation adoptée. Il s’agira de routines
décrivant des événements dans le cas d’une approche par événements, de routines
décrivant des activités dans le cas d’une approche par activités ou de routines décrivant
des processus dans le cas d’une approche par processus.
c) Le niveau 3 :
Comprend un ensemble de routines utilitaires appelées par le niveau 2. Il s’agit de
routines pour générer des nombres aléatoires, collecter des statistiques, produire des
résultats sous forme de rapport, etc... Le programmeur fait appel à ces routines au
moment de l’écriture du niveau 2.
4.2-1 APPROCHE PAR EVENEMENTS
Dans cette approche, un système est modélisé en définissant les changements qui
ont lieu aux instants d’occurrence des événements. Le concepteur doit donc déterminer
les événement qui peuvent changer l’état du système et de développer ensuite la
logique associée avec chaque type d’événement.
La simulation est alors effectuée en exécutant la logique associée à chaque
événement selon une séquence ordonnée en fonction des dates d’occurrence de ces
événements. C'est pour cela que cette approche est qualifiée d'approche par
‘’planification d'événement’’ car les temps des événements futurs sont codés
explicitement dans le modèle et sont planifiés pour se produire au fur et a mesure que la
simulation progresse.
Exemple:
Considérons comme système à modéliser une banque dans laquelle arrivent des
clients qui sont servis par un seul serveur (employé). Les clients arrivent à la
banque, se mettent en attente devant un guichet, sont servis puis quittent la
banque.
Fig6 : Exemple avec file d’attente
L’état du système est défini par l’état du serveur et par le nombre de clients en
attente. Ainsi, l’état reste constant sauf lorsqu’un client arrive ou lorsqu’un client quitte la
banque.
L’approche par événements consiste à décrire ce qui se passe lorsqu’un client arrive
et lorsqu’un client termine le service. Du fait que le système change d’état uniquement
aux instants de ces deux événements (Arrivée d’un client ou départ d’un client) , ces
derniers suffisent pour décrire complètement la dynamique de ce système.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
La logique associée à chacun de ces deux événements peut être décrite en spécifiant
pour chacun les actions élémentaires à réaliser.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Evénement :
Arrivée_Client
Planifier ou prévoir la prochaine Arrivée ;
le SERVEUR est Occupé
Si
Alors
/* on incrémente le nombre de clients en attente */
z Clients_En_Attente ← Clients_En_Attente + 1
Sinon
/*le serveur est libre, Changer son état à Occupé */
z ETAT_SERVEUR ← Occupé
z Planifier un Evénement Fin_De_Service pour
TNOW + Durée de service du client
Fin
Fin événement Arrivée_Client
La planification du prochain événement Arrivée_Client permet d’avoir une succession
d’arrivées de clients. Ainsi, une fois le premier événement Arrivée_Client initié, on aura
une suite d’événements de ce type qui auront lieu. Le traitement du client courant (qui
vient d’arriver) dépend de l’état du système à l’instant où le client est arrivée. Si le
serveur est occupé, les clients qui arrivent doivent attendre, dans ce cas l’état du
système est changé en incrémentant le nombre de clients en attente. Dans le cas ou le
serveur est libre, le client peut immédiatement se faire servir. Dans ce cas, l’état du
système est changé en mettant l’état du serveur à Occupé. En plus, on doit planifier
l’événement correspondant à la fin du service pour ce client (Fin_De_Service) dont la
date d’occurrence sera déterminée en fonction de la durée de service de ce client
(TNOW + Durée_de_Service , ou Durée_de_Service correspond au temps que mettra le
serveur pour servir le client ou TNOW est le temps courant de la simulation).
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Evénement :
Fin_De_Service
Ejecter le client du système ;
Si
Clients_En_Attente > 0
Alors
/* on décrémente le nombre de clients en attente */
/* on engage un nouveau client dans le service */
z Clients_En_Attente ← Clients_En_Attente - 1
z Planifier un Evénement Fin_De_Service pour ce client
à la date : TNOW + Durée de service du client
Sinon
/* le serveur vient de finir de servir un client et */
/* il n’ y a plus de clients en attente
*/
Fin
Fin événement
z ETAT_SERVEUR ← Libre
Fin_De_Service
Il faut remarquer que ce type d’événement (Fin_De_Service) est planifié chaque fois
qu’un client s’est engagé dans le service. Lorsqu’un événement de type a lieu, ceci veut
dire que le serveur était en train de servir un client et qu’il peut s’occuper d’un nouveau
client. Pour cela, on regarde si d’autres clients attendent le serveur (Clients_En_Attente
> 0). Si tel était le cas, on décrémente le compteur Clients_En_Attente ce qui
implicitement correspond à une opération d’engagement d’un nouveau client dans le
service, et on planifie un événement de type Fin_De_Service pour ce client (en fonction
de la durée de service pour ce client). Dans le cas ou il n’ y a plus de clients en attente,
on sait que lorsque un événement Fin_De_Service se produit le serveur a terminé de
servir un client. Il faut donc libérer le serveur en initialisant mettant son état à Libre
(ETAT_SERVEUR ← Libre).
La logique des deux événements Arrivée_Client et Fin_De_Service va nécessiter
deux routines dans le niveau 2. Si on suppose que l’ordre de traitement des clients en
attente n’est pas important, on peut schématiser à l’aide des organigrammes suivants la
logique associée à chacun des deux événements afin de montrer ou se situe la
communication entre les 3 niveaux.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Fig7 : Organigramme de la routine Arrivée_Client
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Fig8 : Organigramme de la routine Fin_De_Service
Dans l’approche par événements, les tâches principales du noyau seront :
1) Contrôler le temps : déterminer la date du prochain événement et initialiser
l’horloge avec cette date
2) Identifier les événements : déterminer quels sont les événements qui doivent avoir
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
lieu au temps courant (horloge)
3) Exécuter les événements : déclencher les événements identifiés comme devant
avoir lieu
Pour pouvoir réaliser ces tâches, le noyau devra utiliser une liste d’événements qui
constituera une sorte d’agenda dans lequel sont répertoriés les événements qui ont été
planifiés. Ces événements sont ajoutés et détruits au fur et à mesure que la simulation
progresse.
Exemple :
L’arrivée d’un client provoquera l’ajout d’un événement Fin_De_Service à
l’agenda (appelé aussi calendrier ou échéancier). Elle provoque aussi l’ajout d’un
événement Arrivée_Client correspondant au prochain client
La fin d’un service peut provoquer l’ajout d’un événement Fin_De_Service à l’agenda
dans le cas ou la file d’attente n’est pas vide et qui concerne dans ce cas le nouvel client
pris dans la file.
Ainsi, chaque événement de la liste doit comprendre au moins les deux informations
suivantes :
• la date d’occurrence de l’événement
• l’identification de l’événement (en général un numéro)
Des informations sur les entités impliquées par cet événement peuvent être aussi
utiles (ex : choix d’un client dans la file).
Au fur et à mesure que la simulation progresse, le noyau va exécuter un cycle à 2
phases:
1) contrôle du temps : cette phase comprend
a) la détermination de la date du prochain événement en examinant le
calendrier (liste des événements)
b) l’initialisation de l’horloge avec la date du prochain événement
c) la construction d’une liste des événements courants comprenant tous les
événements dont la date d’occurrence est égale à l’horloge
2) Exécution des événements courants
Les événements courants sont exécutés sous le contrôle du noyau. Aucun
événement ne peut être déclenché sans le noyau. Ceci garantit que l’enchaînement
logique des événements est entièrement contrôlé par le noyau. Une fois un événement
exécuté, il est détruit (du calendrier et de la liste des événements courants)
Ce cycle est répété jusqu’à la fin de la simulation. Un organigramme simplifié du
noyau pourrait être :
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Fig9 : Organigramme général du noyau
Remarques importantes
Dans le cas d’un modèle complexe (comportant plusieurs événements), la liste des
événements à gérer peut atteindre une taille énorme ce qui aura un effet direct sur le
temps d’exécution de la simulation. Pour cela, si on a à écrire le noyau, il sera important
de tenir compte du choix des structures de données et des algorithmes à utiliser pour
implémenter et exploiter le calendrier ainsi que la liste des événements courants.
4-2-2 Simulation manuelle de l’exemple
client
On va supposer les dates d’arrivée des clients et la durée de service de chaque
connues
et
sont
:
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Numéro Client Date Arrivée
1
3.2
2
10.9
3
13.2
4
14.8
5
17.7
6
19.8
7
21.5
8
26.3
9
32.1
10
36.6
Numéro
Client
(1)
1
2
3
4
5
6
7
8
9
10
Date
Arrivée
(2)
3.2
10.9
13.2
14.8
17.7
19.8
21.5
26.3
32.1
36.6
Date Début
Service
(3)
3.2
10.9
14.4
18.6
21.7
24.1
28.4
31.1
33.2
36.6
Durée de Service
3.8
3.5
4.2
3.1
2.4
4.3
2.7
2.1
2.5
3.4
Date Fin Service
(4) = (3) +
Durée service
7.0
14.4
18.6
21.7
24.1
28.4
31.1
33.2
35.7
40.0
Temps
d’attente
(5) = (3) - (2)
0.0
0.0
1.2
3.8
4.0
4.3
6.9
4.8
1.1
0.0
Total : 26.1
Temps passé
Dans le système
(6) = (4) - (2)
3.8
3.5
5.4
6.9
6.4
8.6
9.6
6.9
3.6
3.4
Total : 58.1
Les colonnes (1) et (2) sont celles de la table 1. la colonne (3) contenant les dates de
début de service dépend de l’état du serveur. Elle est égale à Max( Date d’Arrivée du
client , Date de fin de service du client précédent). La colonne (4) correspondant aux
dates de fin de service et est égale à (3) + Durée de service de chaque client.
D’après les totaux des colonnes (5) et (6) on peut calculer les deux mesures de
performances :
Temps d’attente moyen par client : 26.1 /10 = 2.61
Temps moyen passé par un client dans le système : 58.1 /10 = 5.81
Cette table résume bien les informations concernant le passage d’un client dans le
système mais ne donne pas des informations sur le serveur et la file d’attente. Pour
disposer de ces informations il va falloir examiner les types d’événements qui décrivent
les changements d’état du système : (Arrivée d’un client et Départ d’un client), l’état du
serveur, l’état de la file d’attente, etc.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Date
Evénement
0.0
3.2
7.0
10.9
13.2
14.4
14.8
17.7
18.6
19.8
21.5
21.7
24.1
26.3
28.4
31.1
32.1
33.2
35.7
36.6
40.0
Numéro
Client
1
1
2
3
2
4
5
3
6
7
4
5
8
6
7
9
8
9
10
10
Type
Evénement
début
Arrivée
Départ
Arrivée
Arrivée
Départ
Arrivée
Arrivée
Départ
Arrivée
Arrivée
Départ
Départ
Arrivée
Départ
Départ
Arrivée
Départ
Départ
Arrivée
Départ
Nombre
dans la file
0
0
0
0
1
0
1
2
1
2
3
2
1
2
1
0
1
0
0
0
0
Tot : 17
Nombre
dans
le système
0
1
0
1
2
1
2
3
2
3
4
3
2
3
2
1
2
1
0
1
0
Tot : 33
Etat du
Serveur
libre
occupé
libre
occupé
occupé
occupé
occupé
occupé
occupé
occupé
occupé
occupé
occupé
occupé
occupé
occupé
occupé
occupé
libre
occupé
libre
Temps
Libre du
Serveur
3.2
0
3.9
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.9
0
Tot : 8.0
D’après les totaux des colonnes (4) , (5) et 7 on peut calculer :
% de Temps libre du serveur : [ 8.0/40.0] * 100 = 0.2 * 100= 20%
:3
Taille Max de la file
Nbre de clients Max en même temps dans le système : 4
Une représentation graphique de ces résultats donnerait :
Fig10 : Representation graphique des résultats
Cet exemple nous montre que pour réaliser une simulation selon une approche par
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
événements, nous devons tenir à jour une liste d’événements qu’on exécutera aux dates
d’occurrence de ces événements. Au cours de la simulation, des événements viendront
s’ajouter à la liste, des événements supprimés de la liste (Arrivée_Client,
Fin_De_Service). Tous les événements de la liste seront exécutés selon une séquence
ordonnée sur la base des dates d’occurrence de ces événements. Le temps de la
simulation quant à lui progresse d’une date d’événement vers celle du prochain
événement.
Si le modélisateur emploie un langage de programmation général (Fortran) pour coder
le modèle, beaucoup d’efforts de programmation lui seront nécessités pour gérer la liste
des événements et traiter les événements dans un ordre chronologique.
Ces fonctionnalités étant communes à tous les modèles adoptant cette approche, les
langages de simulation qui supportent cette approche facilitent la tâche de modélisation
du fait que la gestion de la liste, son implémentation sont transparentes (SIMSCRIPT,
GASP, ).
4-2-3 Composantes d'un modéle de simulation a événements
discrets
Les modèles de simulation a événements discrets ont tous plusieurs composantes en
communs et l’organisation logique de ces composantes permet d’aider le codage, la mise au
point, et la mise a jour du programme traduisant le modèle de la simulation. En particulier, les
composantes suivantes se rerouvent dans la plupart des modéles de simulation a
événements discrets adoptant l'approche par ‘‘événement’’:
L'état du système:
L'horloge de la simulation:
La liste des événements:
Des
compteurs
statistiques:
La routine d'initialisation.
Routine de Gestion du
temps (controle du temps):
Routines associées
événements:
bibliothèque
utilitaires:
de
aux
routines
Générateur des résultats:
Le programme principal:
défini par une collection de variables d'état décrivant l'état du
système à a un temps particulier.
variable indiquant la valeur courante du temps de la
simulation.
Une liste qui contient les dates d'occurrence des événement
devant avoir lieu dans le futur.
Variables utilisées pour collecter des informations
statistiques sur les performances du système.
Sous programme servant a initialiser le modèle de simulation
au temps zéro.
sous programme qui détermine le prochain événement a
partir de la liste des événements et intialise l'horloge de
simulation avec le date d’occurrence de cet événement
courant.
sous programme qui met à jour l'état du système quand un
type particulier d'événement se produit (il y a une routine
d'événement pour chaque type d'événement).
ensemble de sous programmes utilisés pour générer des
variables aléatoires identifées comme faisant partie du
modèle de simulation.
sous programme qui calcule des éstimations (a partir des
compteurs statistiques) des mesures de performance
désirées et génère en fin de simulation un rapport.
chargé d’intialiser l’état du systeme au début de la
simulation, toute les variables utilisées au cours de la
simulation. Il invoque la routine de gestion du temps pour
déterminer le prochain événement devant avoir lieu et passe
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
le contrôle à la routine associée a cet événement. Il controle
aussi si la fin de la simulation est atteinte et invoque dans ce
cas le générateur de resultats
L’enchainement logique des différentes composantes est illustré dans la Figure
suivante :
PLVH D MRXU (WDW V\VWHPH
PLVH D MRXU VWDWLVWLTXHV
JpQpUDWLRQ SURFKDLQV HYHQHPHQWV
HW DMRXWHU D OD OLVWH
# ! "
" pQpUDWLRQ GH YDULDEOHV
DOpDWRLUH V
Fin
Simulation
?
$
FDOFXOHU PHVXUHV GH SHUIRUPDQFHV VRXKDLWpHV
(GLWLRQ GHV UpVXOWDWV
%
Fig : Mise en oeuvre d’une simulation selon l’approche orientée événement
La simulation commence au temps T=0. A cet instant le programme principal invoque
la routine d'initialisation où l'horloge de simulation est mise à zéro, l'état du système, les
compteurs statistiques, et la liste des événements sont initialisés.
La routine
d’intialisation redonne le contrôle au programme principal, qui invoque la routine de
gestion du temps pour déterminer quel type d'événement est imminent. Si un
événement de type i est le prochain devant avoir lieu, l'horloge de la simulation est
avancée au temps d’occurrence de l'événement i et le contrôle est rendu au programme
principal. Le programme principal invoque la routine associée a l'événement i dans
laquelle on a typiquement trois choses a faire : (1) l'état du système est mis à jour
pour prendre en compte les effets fait qu'un événement de type i s'est produit; (2)
des informations sur les mesures de performance du système sont collectées en
mettant à jour les compteurs statistiques; et (3) les dates d’occurrences des
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
événements futurs sont générés et ces informations sont ajoutées à la liste des
événements. Souvent il sera nécessaire de générer des variables aléatoires a partir de
distributions statistiques en vue de detertniner ces dates d’occurrences.
Lorsque tout les opérations aient été complétées, aussi bien dans la routine associée a
l’événement i ou dans le programme principal, un test est fait pour déterminer
(relativement à certaines conditions d’arret) si la simulation doit être terminée. Dans un
tel cas, le générateur des résultats de la simulation est invoqué par le programme
principal pour calculer des éstimations (des compteurs statistiques) relatives aux
mesures de performances désirées et editer un rapport contenant ces resultats. Si la fin
de la simulation n'est pas atteinte, le contrôle est repassé au programme principal et le
cycle programme-principal- Gestion du temps-Routine Evenement -Controle de Fin est
répété jusqu’a ce que les conditions d'arrêt sont satisfaites.
Enfin comme il a été mentionné dans les sections précédentes, un système est une
collection bien définie d’entités. Les entités sont caractérisées par des données
appelées attributs et ces attributs font partie de l'état du système. De plus, les entités
ayant des propriétés communes sont souvent groupées, dans des listes. Pour chaque
entité il y a un elément dans la liste qui contient les attributs de l'entité, et l'ordre dans
lequel les eléments de la liste sont maintenus dépend de certaines règles qu’on peut
spécifier. Pour l’exemple de la banque les entités sont le serveur et les clients dans la
banque. Le serveur a comme attribut ‘Etat du serveur’ qui peut etre : libre ou occupé, et
les clients qui attendent dans la file ont comme attribut le ' temps d'arrivée'. Le nombre
de clients dans la file peut aussi être considéré un attribut du serveur. Les clients dans
la file peuvent etre groupés dans une liste.
L'organigramme de la mise en oeuvre d'une simulation a événements discrets basée
sur une approche par evénements 'Event scheduling' est assez simple surtout lorsque
le codage du modèle est fait dans un langage tel que FORTRAN, Pascal, ou C.
4.3 APPROCHE PAR ACTIVITES
Cette approche est très populaire en G.B. et est aussi connue comme l’approche à 2
phases. Elle est moins efficace et moins naturelle que l’approche par événements et n’a
pas par conséquent été très adoptée. Un seul langage de simulation (CSL : Control &
Simulation Language) adopte cette approche.
Elle est très similaire à la programmation logique par règles de production : Si
condition(s) Alors Action(s). Le concepteur décrit les activités dans lesquelles les objets
du système s’engagent et prescrit les conditions qui causent le début ou la fin d’une
activité. Les événements de début ou de fin d’une activité ne sont pas planifiés par le
concepteur mais sont initiés à partir des conditions spécifiés pour l’activité.
Au fur et à mesure que le temps de la simulation progresse, les conditions de début
ou de fin d’une activité sont examinées (scrutées). Si ces conditions sont satisfaites alors
les actions appropriées sont exécutées.
Afin de s’assurer que toutes les activités sont prises en compte, il est nécessaire de
scruter toutes les conditions à chaque progression du temps. Ainsi, avec cette approche,
on ne répertorie plus les différents types d’événements mais les différents types
d’activités possibles avec leurs conditions de début et de fin.
C’est une approche gourmande en temps de calcul puisque à chaque progression du
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
temps, des tests sont faits même pour les activités qui ne peuvent pas débuter ou finir.
Elle est en général réservée aux cas ou les activités ont une durée non connue à priori.
Avec cette approche, un modèle peut être représenté graphiquement à l’aide d’un
diagramme de cycles d’activités utilisant deux symboles: le rectangle représentant un
état actif (activité en cours) et le cercle représentant un état passif (attente activité
suspendue).
Exemple :
L’exemple de la banque pourrait être représenté par le diagramme :
Fig 11 : Representation par un diagramme de cycles d’activités
4.4 APPROCHE PAR PROCESSUS
Cette approche est la plus intuitive. Elle est utilisée par beaucoup de langages de
simulation (Simula , GPSS, SIMAN, ...) et consiste en une combinaison des avantages
des deux autres approches.
Un processus est une séquence d’opérations (événements ou activités) à travers
lequel passe une entité durant son séjour dans le système.
5. MODELES DE SIMULATION CONTINUS - MODELES COMBINES
Un modèle de simulation continu permet de décrire l’état du système par un ensemble
de variables dites variables d’état qui changent de valeurs de manière continue au cours
du temps.
Un tel modèle est exprimé grâce à des équations mettant en relation ces variable
d’état et dont les changements au cours du temps permettent de simuler la dynamique
du système modélisé.
En général, un modèle continu est formulé sous forme d’équations différentielles
permettant d’exprimer pour une variable d’état S son taux de changement en fonction du
temps.
Exemple:
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
La première équation spécifie la taux de changement ( dS(t) /dt)
de S comme
une fonction de S et de t. La seconde équation spécifie les conditions initiales pour la
valeur de S ( pour t=0).
L’objectif d’un modèle de ce type est donc de déterminer les changements de S au
cours du temps.
Lorsqu’on connaît une équation pour dS /dt, il est possible de déterminer une
expression analytique pour S en passant par le calcul d’une intégrale. La valeur de S à
l’instant t2 peut d’exprimer en fonction de celle de S à l’instant t1 comme suit :
Le problème qui va se poser est comment calculer l’intégrale sur ordinateur. On
utilise en général des méthodes d’intégration numériques ( Range-Kutta) qui
consistent à subdiviser le temps (variable indépendante) en pas (Slice , time slicing)
et calculer par approximation la valeur de la variable d’état. Plus le pas est petit et
l’ordre d’approximation grand , plus le résultat sera précis. Lorsqu’on connaît une
équation pour dS /dt, il est possible de déterminer
Une autre approche consiste à formuler le modèle sous forme d’équations aux
différences (et non différentielles). Le temps dans ce cas est décomposé en pas ( ∆t)
et le changement dynamique des variables d’état est exprimé par une équation
calculant la valeur d’une variable à l’étape k comme suit :
Dans ce cas on n’aura pas à calculer d’intégrale. Néanmoins dans la pratique, la
dynamique de la plupart des systèmes non discrets (fonderie, métallurgie, chimie, ....) se
modélise selon la première approche (équations différentielles).
Les langages de simulation qui offrent la possibilité de modéliser des systèmes
continus, mettent à la disposition du programmeur (modélisateur) un support (structures
de données) pour coder directement ces équations.
Dans la réalité, beaucoup de systèmes possèdent un aspect discret et un aspect
continu, ces deux aspects interagissant entre eux. Ces systèmes peuvent être modélisés
par des modèles dits ‘‘combinés’’. Les langages offrant cette possibilité mettent à la
disposition du concepteur des outils pour programmer ou modéliser les interactions.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Fig12 : changements d’état dans une simulation
Ces trois figures représentent les changements d’état possible qu’on peut rencontrer
dans une simulation (discret , continu , combiné)
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
6 LES ETAPES D’UN PROJET DE SIMULATION
Les étapes qui constituent tout projet de simulation peuvent être schématisées par
l’organigramme suivant :
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
6.1. Formulation du problème
Toute projet de simulation commence d’abord par l’énoncé du problème à résoudre.
Si cet énoncé est fait par les personnes qui ont rencontré le problème, l’analyste doit
faire très attention de façon à comprendre clairement le problème. Si par contre,
l’énoncé est fait par l’analyste, il est très important aussi que les personnes pour
lesquelles il doit résoudre le problème (clients de l’étude) comprennent et se mettent
d’accord sur la formulation qui a été faite.
Durant cette étape, il est suggéré qu’un ensemble d’hypothèses soit proposées,
discutées et acceptées par l’analyste et le client de l’étude. Il faut souligner qu’à ce
niveau, on n’est pas sûr d’avance que la formulation soit très juste et il est tout à fait
possible que le problème aura besoin d’être reformulé au fur et à mesure de la conduite
du projet.
6.2. Fixation des objectifs
Une fois le problème formulé, il faudra définir les objectifs visés par le projet de
simulation. Ceci comprend :
z
z
z
z
z
z
Les questions auxquelles devra apporter une réponse l’étude par simulation
qu’on veut mener
Le personnel qui sera requis
Le matériel et logiciel informatique
Les divers scénarios qu’on veut investiguer, les sorties attendues,
Les coûts de l’étude ainsi que les temps requis
etc...
6.3. Construction du modèle
Il s’agit de construire un modèle conceptuel qui est une abstraction du système réel.
Ce modèle peut être vu comme un ensemble de relations mathématiques et logiques
concernant les composants et la structure du système.
On doit en principe commencer par un modèle de base simple et l’affiner au fur et à
mesure de façon à obtenir le modèle répondant aux objectif visés. On doit souligner
l’importance d’impliquer le client dans cette étape.
Par exemple, on commence par construire un modèle de base incluant les serveurs,
les files d’attente et les phénomènes d’arrivée. Par la suite, on peut rajouter les
phénomènes de pannes puis les possibilité de manutention ou transports à l’intérieur du
système. Enfin le modèle est enrichi par tous les capacités spécifiques.
Il n’est pas nécessaire de construire du premier coup un modèle excessivement
complexe qui augmentera les coûts et les délais de réalisation sans pour autant accroître
la qualité des résultats.
Le client doit être impliqué tout au long du processus de construction du modèle. Ceci
augmentera la qualité du modèle obtenu et accroît la confiance du client quant à
l’utilisation du modèle.
Enfin, on doit souligner que la construction du modèle n’est pas une théorie en soi
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
mais plutôt une experience qui s’acquière et se consolide sur des problèmes réels.
6.4 Collecte des données
Une fois le problème formulé et les objectifs visés identifiés, il faudra établir un
inventaire des besoins en données sur le système réel et le soumettre au client. Dans le
meilleur des cas, le client dispose déjà des données nécessaires qu’il conserve dans le
format adéquat et que l’analyste n’aura qu’à utliser.
Cependant dans la pratique, ce cas est vraiment très rare. En effet, très souvent le
client pense disposer de toutes les données requises mais en réalité lorsque l’analyste
prendra compte de celles-ci, elles s’avéreront très différentes de celles dont il a besoin.
Exemple :
Dans un système de reservation automatique de billets, le client dit à l’analyste : ‘‘
Ne vous inquiétez pas, nous avons toutes les données que vous désirez et sur une
période de 5 ans’’. Lorsque les données furent recueillies auprès du client, il s’avère que
ces données n’étaient que des moyennes du temps mis par les clients de l’agence aux
guichets de réservation chaque année. Or l’analyste avait besoin de mesures
individuelles et non de moyennes pour mener le projet (pour déterminer les paramètres
du modèles).
Il faut remarquer que sur l’organigramme, les étapes de construction du modèle et de
collecte des données sont placées au même niveau. Ceci signifie en fait que ces deux
étapes peuvent progresser en parallèle.
6.5 Codage
Il s’agit de traduire le modèle conceptuel obtenu à l’étape 3 dans une forme
acceptable par l’ordinateur (i.e. programme appelé aussi modèle opérationnel). Pour
cela, il va falloir utiliser un langage de simulation parmi ceux disponibles. Certains
langages de simulation offrent l’avantage de séparer entre le cadre d’expérimentation
(Experimental Frame) qui contient toutes les données et les informations pour exécuter
la simulation. Il devient alors possible de faire différentes expérimentations sur le même
modèle en changeant uniquement le cadre d’expérimentation (données
d’expérimentation). C’est le cas avec SIMAN.
6.6 Vérification
L’étape de vérification est extrêmement importante dans tout projet de simulation. Elle
concerne le modèle opérationnel (programme). Il s’agit de s’assurer que le modèle
s’exécute sans erreurs. La vérification est primordial même pour des modèles de taille
réduite car ces derniers peuvent aussi comporter des erreurs bien qu’ils soient très petits
comparés à des modèles de systèmes réels par essence complexes.
Il est vivement recommandé d’attendre jusqu’à ce que le modèle entier soit terminé
pour commencer la vérification et que celle-ci se fasse de façon continuelle.
Les recommandations pour résussir cette étape sont :
1) Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Le modèle doit être construit de façon modulaire et selon une approche descendante.
Il est recommandé d’établir d’abord un organigramme (dans le cas où le langage
n’offre pas le symbolisme pour construire un modèle) traduisant en termes logiques
les opérations qui doivent être réalisées par le modèle avant de passer au codage.
) C’est à dire commenter toutes les lignes du programme, expliquer le sens et l’utilité de
toutes les données utilisées dans le programme. Normalement, une personne n’ayant
pas participé au codage devrait être en mesure de comprendre ce que fait le
programme.
Le fait de contrôler le modèle par plusieurs personnes vise à augmenter les chances
de déceler toutes les erreurs. En général, on utilise des techniques inspirées de celles
utilisées dans le test de logiciel (Inspection de code) fondées sur un travail de groupe
dont les membres sont :
T
T
T
T
Le modérateur
Le concepteur
Le programmeur
Le testeur
: ou chef de groupe
: qui a développé le modèle conceptuel
: qui a traduit le M.C. en programme
: responsable de la vérification
Ces personnes organisent des réunions de travail au cours desquelles le M.C. est
discuté, le programme aussi. Les erreurs detectées sont documentées corrigées, et le
processu reprend jusqu’à eradication de toutes les erreurs.
) Si par exemple le temps est exprimé en minutes, toutes les variables de type temps
(temps d’arrivée, durée de service, temps d’attente, etc...) doivent être exprimées
dans la même unité (et non en secondes, heures, etc..).
) ! Si par exemple on s’aperçoit que le nombre d’entités dans une file d’attente est de
100 alors qu’on devait avoir au plus 10, il y a sûrement un problème. Ceci peut par
exemple provenir du fait que la file d’attente est associée normalement à une
ressource ou serveur ayant une capacité de deux unités (2 serveurs en parallèle)
alors que dans le modèle, cette ressource a été modélisée comme ayant une capacité
d’une seule unité.
") # !$$ $$
Certains langages de simulation offre des outils de mise au point (ex: SIMAN) qui
facilitent beaucoup la vérification du modèle. Ils permettent de scruter la valeur de
n’importe quelle variable, de poser des points d’interruption, etc.
%) # $ & $$
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Certains langages de simulation permettent de visualiser sous forme d’animation
graphique tous les changements d’états qui se produisent au fur et à mesure que la
simulation progresse. Il devient alors plus facile de detecter les anomalies ou erreurs
dans le modèle. Par exemple, une ressource qui ne change jamais d’état est signe
d’anomalie. Elle peut être la conséquence d’une erreur de programmation ou de
modélisation. Le plus important est que l’erreur devient visible à l’écran et donc plus
facile à l’écran.
6.7 Validation
La validation consiste à s’assurer que le modèle conceptuel est une
représentation fidèle du système réel. Il s’agit en fait de savoir si le modèle peut être
substitué au système réel pour le but de l’expérimentation.
Dans le cas ou le système existe, la façon idéale de valider le modèle conceptuel
est de comparer ses sorties avec celles du système. Malheureusement, on n’a pas
toujours cette possibilité surtout dans les projets de conception de nouveaux
systèmes.
Les techniques de validation utilisées en simulation peuvent être calssées en
deux catégories : les techniques subjectives et les techniques objectives.
6.7.1 Techniques de validation subjectives
Les techniques les plus importantes sont :
6.7.1.1 Validation d’apparence (face validation)
C’est la première validation à faire et qui consiste à soumettre le modèle
conceptuel à des personnes familières du système réel modélisé. Ces personnes
seront chargées de porter des critiques sur le modèle concpetuel, le but étant de
s’assurer que toutes les suppositins ou hypothèses faites dans le modèle sont
correctes. La crédibilité du modèle augmente au fur et à mesure que les anomalies
détectées dans le modèle sont corrigées.
6.7.1.2 Analyse de sensibilité (Sensitivity analysis)
Il s’agit de tester si un changement dans les données d’entrée du modèle,
entraîne un changement prévisible dans les sorties. Par exemple, si le taux d’arrivée
des clients croit, le temps d’attente dans la file devrait croitre aussi. Il s’agira en fait de
determiner si le modèle réagit correctement aux changements de valeurs de certaines
données d’entrées et que cette réaction est bien celle à laquelle on s’attendait.
6.7.1.3 Test des conditions extrêmes
Il s’agit de tester si le modèle se comporte normalement lorsque les données
d’entrée sont à leurs valeurs maximales. Par exemple, si le taux d’arrivée des clients
est fixé à sa valeur maximale, cette valeur aura -t-elle comme effet en sortie un
accroissement du temps d’attente dans les files, du temps de séjour des clients dans
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
le système, du nombre de clients dans les files, etc...
6.7.1.4 Validation des hypothèses
Il y a deux types d’hypothèses (suppositions) qu’on peut faire concernant le
modèle concpetuel : des hypothèses structurelles liées au fonctionnement du système
modélisé et des hypothèses sur les données du modèle.
z
z
Les hypothèses structurelles peuvent être validées en observant le système,
en les discutant avec le personnel qualifié. Il faut préciser qu’une personne
seule ne peut en aucun cas connaître à elle seule tout sur le système réel et
on sera amené impérativement à consulter plusieurs personnes de
différentes spécialités (opérateur sur machine, ingénieur, chef d’atelier,
administrateur, etc...)
Les hypothèses ou suppositions concernant les données du modèle doivent
aussi être validées. Ceci dépend évidemment de la nature de la donnée. Si
on a supposé par exemple que le temps séparant les arrivées des clients est
une varaible indépendante qui suit une distribution exponentielle, la validation
d’une telle hypothèse consistera à :
T
T
T
T
Faire une Collecte des données sur les temps séparant les arrivées de
clients.
Effectuer un test statistique pour s’assurer
d’indépendance de cette variable est acceptable.
que
l’hypothèse
Estimer le paramètre de la distribution supposée (exponentielle dont le
paramètre est une moyenne).
Effectuer un test d’adéquation (goodness-of-fit) pour s’assurer que
l’hypothèse d’une distribution exponentielle est aussi acceptable.
6.7.1.5 Tests de Turing
Il s’agit de comparer les sorties du modèle à celles du systèmes réel. Cette
technique consiste à préparer un nombre N de résultats en faisant des
expérimentations avec le modèle. On prépare aussi N résultats à partir
d’observations du système réel. Ces résultats sont présentés sous le même format et
contiennent les mêmes types de mesures. On les soumet à une personne familière du
système (donc habituée à ces types de mesures). Si cette personne arrive à
distinguer les résultats issus de la simulation de ceux issus des observations du
systèmes réel, alors le modèle est consédré comme inadéquat. Dans le cas contraire,
on considère que le modèle de conceptuel est une représentation fidèle du système
réel et peut le remplacer en vue de réaliser des expérimenations.
6.7.2 Techniques de validation Objectives
Ces techniques sont basées sur l’utilisations de méthodes statistiques en vue
de valider les résultats produits par une simulation.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
6.7.2.1 Validation des sorties (test d’hypothèses)
Cette technique consiste à comparer les sorties du modèle avec celles du
système. Ceci suppose donc que le système existe déjà. Une méthode de
comparaison très utilisée est celle basée sur le t-test dont le principe est le suivant :
Exemple :
Si la mesure de performance à valider est : le temps d’attente moyen d’un client
devant un guichet de service. Après observation du système durant 5 jours, on
s’aperçoit que le temps moyen mesuré est égal à 3 mn. On effectue 5 simulations
avec le modèle (une simulation pour une journée) qui donnent comme résultats pour
le temps d’attente moyen : 1.63 , 2.22 , 3.12 , 1.09 , 2.11 mns.
Il s’agit alors de tester si l’hypothèse : H0 : E[Xi] = 3 mns est acceptable
ou non (H1: E[Xi] ≠ 3 mns)
ou Xi est la variable aléatoire correspondant au temps d’attente moyen durant la
ième simulation.
La méthode statistique à utiliser est celle utilisant la distribution de Student qui
s’applique au cas des petits échantillons (comme ici). Il s’agira de calculer le
paramètre t de la distribution et de se fixer le niveau de confiance à accorder au
résultat (95% ou 99%, ...), de regarder dans la table donnant t si la moyenne espérée
2
(3mn) est à retenir ou à rejeter. (Voir aussi le test du χ )
6.7.2.2 Validation par les données historiques
Il s’agit de conduire des simulations en utilisant les données historiques du
système au lieu d’utiliser des données artificielles. On devrait s’attendre alors à ce
que les sorties du modèle et celles du système soient en parfaite concordance. Pour
valider cette hypothèse puisque les sorties sont par nature aléatoire, on aura besoin
de conduire des test d’hypothèse (Student, snédecor, Chi-deux, ...).
Exemple :
Les données historiques contiennent les temps séparant les arrivées de clients
(TBC) et les durées de service (TSRV) pour 5 journées. Si on désigne par Wi le
temps d’attente dans la file observé au cours de la journée i, On peut faire une
simulation en utilisant les valeurs historiques de TBCi et TSRVi (journée i) afin
d’obtenir le temps d’attente moyen dans la file Yi. La validation de ce résultat va
consister à determiner si H0 : E[Di] = 0 (ou Di = Wi - Yi) est accpetable ou non. Ceci
va demander à conduire des test d’hypothèse (Student, snédecor, Chi-deux, ...)
comme indiqué plus haut.
6.8 Conception d’un cadre d’expérimentation
Il s’agit de définir pour chaque scénario devant être simulé ou expérimenté un
certains nombre de paramètres tel que :
• Durée de la simulation
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
• nombre de simulation à faire (Réplications)
• état initial du modèle
• règles de gestion des files d’attente
• etc.
6.9 Exécution de la simulation et Analyse des résultats
Le modèle opérationnel ou programmé est le support principal pour réaliser une
simulation sur ordinateur. Il sera analysé et interprété par le simulateur qui délivre en
sortie des résultats purement statistiques (moyenne, variance, écart type , minimum,
maximum,...). L’analyse de ces résultats aura pour objectifs d’estimer les mesures de
performances des scénarios qu’on a expérimenté.
6.10 Exécutions supplémentaires
A ce niveau, on dispose d’un ensemble de résultats provenant des différentes
simulations qu’on a réalisé ainsi que d’une analyse de ces résultats. Il s’agira de
déterminer sur la base de cette analyse si d’autres simulations doivent être faites, si
d’autres scénarios non prévus doivent être expérimentés afin de s’assurer que le
modèle répond bien aux objectifs visés dans l’étape 2.
6.11 Documentation
La documentation est nécessaire pour différentes raisons et concerne aussi
bien le modèle que les résultats de la simulation.
Si le modèle aura un jour à être réutilisé par d’autres personnes, la
documentation les aidera à comprendre le fonctionnement du modèle et leur facilite
toutes modifications ou mises à jour du modèle.
Si le projet à été réalisé pour un client, ce dernier est plus confiant s’il dispose
d’une documentation sur le projet. En effet, il aura la possibilité de revoir toutes les
alternatives prises en considération, les critères de comparaisons qui ont été utilisés,
les recommandations faites par l’analyste. Ceci va l’aider énormément dans la prise
de décision qui sera principalement basée sur les résultats fournis par la simulation et
rapportés dans la documentation.
6.12 Implémentation
L’objectif de toute simulation est de proposer pour un problème plusieurs
solutions. Le choix de la meilleure solution devra être fait par l’analyste qui la justifiera
dans la documentation et la propose (et ne l’impose pas) au client. La décision de
retenir cette solution pour une éventuelle implémentation reste donc une
responsabilité du client.
C’est ainsi que la qualité et la richesse de la documentation peut avoir une
grande influence sur cette étape. De plus, l’implication du client tout au long de la
conduite du projet augmente les chances d’une implémentation de la solution
retenue.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
7 PROBLEMES STATISTIQUES LIES A LA SIMULATION
L’analyse des résultats d’une simulation consiste en général à estimer la valeur
de la moyenne de la réponse fournie par la simulation ainsi que l’estimation de sa
variance. Ces deux estimations sont influencées par les conditions initiales avec
lesquelles on commence l’expérimentation (i.e. la simulation. Ces conditions
comprennent :
T
T
T
T
L’état initial ou de début de la simulation (file vide ou non, serveurs libres
ou occupés,...)
Le temps à partir duquel on commence la collecte des statistiques
La durée de la simulation
Le nombre de simulations à faire
7.1 Etat initial
Dans tout modèle de simulation, l’état initial avec lequel on commence la
simulation doit être spécifié. Le plus simple et probablement le plus communément
utilisé est : un état initial dit ‘‘Vide et Libre’’ , c’est à dire un état dans lequel toutes les
files d’attente sont vides et tous les serveurs (ou ressources) sont libres au début de
la simulation.
La validité d’un tel état dépend de la nature du système modélisé et du fait
qu’on s’intéresse au comportement du système dans son régime transitoire ou son
état stationnaire. L’état stationnaire ne signifie pas une absence de variabilité dans la
réponse produite par la simulation mais signifie que cette variabilité n’est plus affectée
par l’état initial ou les conditions initiales.
Fig14 : Etat transitoire et Etat stationnaire d’un systeme
Lorsque l’objectif est d’analyser le comportement d’un système lorsqu’il est à
l’état stationnaire, on peut améliorer l’estimation de la moyenne en commençant la
simulation dans un état autre que ‘‘Vide et Libre’’. Ce nouvel état doit être
représentatif du début de la stationnarité du système. On peut le déterminer en
conduisant une première simulation (essai) et en observant graphiquement le résultat
afin de savoir à quel moment le système passe dans un état stationnaire. Par contre,
si on veut analyser le comportement du système à l’état transitoire, il faut que les
conditions initiales (état initial) de début de la simulation doivent refléter l’état initial du
système.
7.2 Troncature des données
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Une méthode qui est fréquemment utilisée pour réduire tout biais (ou effet) dans
l’estimation de la moyenne à l’état stationnaire qui pourrait résulter de l’état initial ou
des conditions initiales est de retarder la collecte des statistiques jusqu’à ce que le
système se trouve dans un état de mise en train (Warm up, Mise en train, régime de
croisière)
Ceci est fait simplement en précisant le temps avant lequel les valeurs des
données ne sont pas inclues dans les estimations statistiques. L’objectif est de
réduire le biais (l’effet) des conditions initiales sur les estimations en éliminant les
valeurs collectées durant la période transitoire.
Cependant en éliminant une partie des données, on pourrait accroître
l’estimation de la variance de la moyenne observée. Ainsi, la troncature permet
d’améliorer la qualité de l’estimation de la moyenne au prix d’une possible
augmentation de la variabilité des résultats de la simulation(Variance).
La méthode la plus utilisée pour déterminer le point ou l’instant à partir duquel
on fait une troncature est de réaliser une simulation d’essai (pilot simulation) et
d’examiner la réponse graphiquement. L’instant sera alors choisi comme celui à partir
duquel la réponse du système semble avoir atteint un état stationnaire. Il existe aussi
d’autres méthodes qui tentent de formaliser la procédure de troncature sous forme de
règles qui peuvent être incorporées dans le programme de simulation lui-même et
dont le but et de déterminer automatiquement le point de troncature.
7.3 Durée de la simulation - nombre de réplications
Il s’agit de trouver un compromis entre faire une simulation sur une longue
période de temps ou faire plusieurs simulations de courtes durées.
Dans le premier cas, on obtient généralement une meilleure estimation de la
moyenne à l’état stationnaire du fait que le biais induit par les conditions initiales n’est
introduit que peu de fois et moins de données seront tronquées. Cependant, on
disposera d’un nombre réduit d’échantillons ce qui augmente en général la variance
de la moyenne.
L’exécution de plusieurs simulations de courtes durées (réplications) a comme
inconvénient d’augmenter le biais du au conditions initiales car il est introduit à
chaque exécution. Plus le biais est grand, plus il est important de faire des simulations
de longue durée afin de réduire son effet sur les résultats.
Différentes méthodes existent pour spécifier la durée d’une simulation. La plus
générale est de spécifier le temps au bout duquel la simulation doit s’arrêter.
l’inconvénient de cette méthode est que le nombre d’échantillons qui sera collecté est
aléatoire et peut varier d’une exécution à une autre. Une méthode qui permet de
contrôler la taille de l’échantillon est de spécifier le nombre d’entités à injecter dans le
système (100 pièces, 50 clients,...).Dans ce cas, la simulation s’exécute jusqu’à ce
que le nombre spécifié soit complètement traité. Ainsi, la simulation s’arrête avec un
système se trouvant dans un état ‘‘Vide et Libre’’.
Une méthode similaire est de spécifier non pas le nombre d’entités à injecter
dans le système mais le nombre d’entités à traiter (quittent le système). Dans ce cas,
la simulation s’exécute jusqu’à ce que le nombre spécifié soit complètement traité.
Lorsque la simulation s’arrête, le système n’est pas nécessairement dans un état
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
‘‘Vide et Libre’’. Lorsqu’on utilise cette méthode, on doit s’assurer que les entités qui
restent dans le système sont représentatives d’un phénomène (ex: durée de service
longue par rapport à celles traitées). Cette méthode n’est généralement pas
appropriée pour certaines politiques de gestion. Si par exemple la politique est de
traiter en priorité les entités nécessitant le moins de temps, on aura en fin de
simulation uniquement des entités ayant des temps opératoires grands qui restent
dans les files d’attente.
Une autre méthode pour contrôler la durée d’une simulation est d’utiliser des
règles de terminaison automatiques. Il s’agit de contrôler dynamiquement les résultats
de la simulation à des instants précis durant l’exécution. La simulation sera arrêtée
dès que l’estimation de la variance est dans un intervalle admissible (détermine un
intervalle de confiance).
7.4 Données du modèle
Les données d’un modèle de simulation sont pour la plupart des variables
aléatoires dont les distributions de probabilités devront être déterminées. Ceci
dépendra de trois facteurs :
T
T
T
Le volume de données disponibles
Les données disponibles sont réelles ou de simples estimations
Les variables sont indépendantes ou non
Dans le cas d’une variable indépendante des autres, on a le choix entre:
T Supposer la variable deterministe (non aléatoire)
T Ajuster une distribution de probabilité à la variable
T Utiliser la distribution empirique
7.4.1 Ne pas tenir compte de l’aléatoire
Une variable peut être supposée deterministe (ou constante). Sa valeur sera
obtenue par exemple en faisant une moyenne des données historiques Elle peut
aussi une simple estimation suite à des observations du système.
Ceci peut poser des problèmes si le modèle comporte des variables aléatoires
(stochastique) car le fait de na pas tenir compte du caractère aléatoire d’une variable
risque d’invalider les résultats de la simulation.
Ex : Si on dispose d’une machine qui usine les pièces en un temps égal
exactement à 1,5 mn. Si on suppose que la machine nécessite un changement
d’outils dont la fréquence suit une distribution exponentielle de moyenne 12 mn. Si on
suppose aussi que le temps nécessaire pour changer d’outils est une variable
aléatoire qui suit une distribution exponentielle de moyenne 3 mn.
Une simplification de cette situation serait de considérer que la machine opère en un
temps constant T = 1,5 + approximation (fréquence de changement) + approximation
(temps de changement), et ignorer l’aspect aléatoire.
Cette simplification aura de lourdes conséquences sur d’autres mesures de
performances du système tel que : le temps d’attente moyen devant la machine ou le
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
nombre moyen de pièces en attente devant la machine.
7.4.3 Ajuster une distribution de probabilité à la variable
Lorqu’on dispose d’un volume de données suffisant (100 ou plus), il sera
possible d’ajuster une distribution de probabilité théorique à ces données en utilisant
une méthode statistique convenable. Le choix d’une distribution parmi d’autres devra
être justifié en effectuant un test d’adéquation (goodness-of-fit) dont les principes
pourraient être trouvés dans les ouvrages de statistiques. Il faut remarquer qu'il existe
aussi des logiciels conçus pour réaliser automatiquement un ajustement (ex:
ExpertFit).
Lorsque le volume des données n’est pas suffisant (réduit), les méthodes
d’ajustement bien qu’applicables posent des problèmes à cause les tests
d’adéquation ne sont malheureusement pas adaptés aux cas où le nombre de
données est réduit.
La connaissance des caractéristiques de certains phénomènes peut aussi aider
(ou guider) dans le choix d’une distribution. Ceci est vrai par exemple pour les
phénomènes d’arrivées (arrivées de clients, de pièces, d’appels téléphoniques, ..),
dans lesquels lorsqu’on est sûr que les arrivées se produisent l’une après l’autre (pas
en même temps) et sont complètement aléatoires et indépendantes les unes des
autres, alors le processus suit une loi de Poisson. C’est un résultat connu
théoriquement et on peut montrer dans un tel processus que le nombre d’arrivées
pendant une période t suit une distribution de Poisson et que le temps séparant les
arrivées suit une distribution exponentielle.
L’ajustement d’une distribution de probabilité aux données se fait en trois étapes
qui sont :
&KRL[ G·XQH GLVWULEXWLRQ
La première chose à faire c’est d’identifier si le phénomène est discret ou
continu. Les données discrètes résultent d’un processus de comptage (nombre de
clients qui arrivent dans une banque toutes les heures, nombre de pièces qui arrivent
sur une machine pendant un certain temps, nombre de changements d’outils
effectués sur une machine en une journée,etc.). Les données continues résultents
d’un processus de mesure (temps mis par un client pour être servi, temps mis par une
pièce pour quitter le système, poids d’une pièce brute, etc.).
Du fait que les distribution de probabilités se répartissent en distributions
discrètes (Poisson, Binomiale, Géométrique,..) et distributions continues (Uniforme,
Exponentielle, Normale, Triangulaire, etc.), cette première étape permettra donc de
choisir le bon type de distribution (on ne peut pas choisir une distribution continue si
les données sont de type discrèt).
(VWLPHU OHV SDUDPqWUHV GH OD GLVWULEXWLRQ FKRLVLH
Chaque distribution possède des paramètres propres. Par exemple , une
distribution de Poisson est caractérisée par un seul paramètre qui est la moyenne,
une distribution Normale est caractérisée par deux paramètres : une Moyenne et un
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Ecart type, etc.
Il s’agira donc de trouver pour la distribution choisie les paramètres qui la
caractérisent.
(IIHFWXHU XQ WHVW G·DGpTXDWLRQ JRRGQHVVRI)LW
Une méthode de test d’adéquation parmi les plus utilisées est celle du ChiDeux qui consistent à comparer les valeurs observées et espérées. Si selon une
formule précise et à comparer le résultat à une valeur de référence (table du Chideux). Si le test échoue, ceci signifie que la distribution n’est probablement pas la
bonne et dans ce cas, il faudra reprendre à partir de la première étape.
8WLOLVHU OD GLVWULEXWLRQ HPSLULTXH
Lorsqu'on dispose d'un volume de données très réduit, une tentative
d'ajustement d'une distribution de probabilité à ces données n'est pas appropriée. De
même si après avoir essayé toutes les possibilités d'ajustement d'une distribution
aux données disponibles en utilisant les techniques conventionnelles, on n'aboutit a
aucun résultat satisfaisant, alors il est toujours possible d'utiliser la distribution dite
'empirique' car utilisant les données telles qu'elles se présentent.
Exemple: si le temps de réparation d'une machine après une panne (qu'on notera
X), pour les 100 occurrences de panne qui se sont produites est
donnée par la table suivante :
Temps réparation
0.0 < x ≤ 1.0
1.0 < x ≤ 2.0
2.0 < x ≤ 3.0
3.0 < x ≤ 4.0
4.0 < x ≤ 8.0
Total
fréquences de panne observées
27
13
31
18
11
100
/* Par exemple, pour la première ligne, cela signifie que 27 occurrences de pannes ont
nécessité un temps de réparation x compris entre 0 et 1 heure */
L’allure graphique de cette distribution de frequences serait :
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
En comparant visuellement cette courbe à celles des distributions de
probabilités théoriques connues, on s'apercevra que sa forme n'est semblable a aucune
des courbes de ces distributions. Ainis aucune distribution ne peut etre ajustée a ces
données en utilisant les techniques conventielles. On peut alors decider d'utiliser les
données telles qu'elles se présentent. Ceci veut dire qu'au cours de la simulation si nous
aurons besoin d'un valeur pour x (un temps de réparation) il faudra faire un tirage a partir
de la distribution continue représentée par le tableau précedent. Ceci requière de definir
une fonction d'interpolation qui permet de retourner des valeurs toujours comprise entre
0 et 8 et qui tiennent compte de l'allure de la dispersion des valeurs observées dans la
réalité.
3DV GH GRQQpHV GLVSRQLEOHV
Il existe plusieurs situations où on peut être amené à conduire une simulation
mais on ne dispose pas de données. Ceci est vrai dans les projets de conception (le
système n’existe pas donc les données d’observation n’existent pas), ou dans des
projets où la collecte des données revient cher.
Dans ce cas, une possibilité pour surpasser dans un premier temps ce handicap
est de faire des estimations subjectives concernant les données du système.
Ex : Si on estime qu’une machine met entre 3 et 8mn pour usiner une pièce,
on peut supposer grossièrement que le temps d’usinage suit une loi uniforme ayant
pour valeur minimale 3mn et pour valeur maximale 8mn. Cette loi appelée aussi ‘‘loi
du maximum d’ignorance’’ suppose que toutes les valeurs entre 3 et 8 mn sont
équiprobables.
Si on pouvait determiner parmi l’ensemble des valeurs équiprobables celle qui est
la plus équiprobable, alors on peut améliorer l’estimation. Par exemple, la machine
met entre 3 et 8mn pour usiner une pièce, mais ce temps est souvent de 5mn. Cette
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
affirmation permet d’utiliser non pas une loi uniforme mais une loi triangulaire ayant
un paramètre en plus qui est le mode (la valeur la plus probable) égal à 5mn.
Les estimations subjectives ne constitutent pas une fin en soi. Lorsque les
données deviennent disponibles, ou assez suffisantes, il faudra obligatoirement
procéder à une mise à jour des distributions et de leurs paramètres.
7.5 Expérimentation et analyse des résultats
L’analyse des résultats d’une simulation commence d’abord par la selection des
mesures de performance qu’on veut analyser. Ces mesures peuvent représenter un
temps : Time persistent (temps passé dans une file, temps de séjour dans le
système), obtenues par un comptage d’occurrences (nombre d’entités dans une file,
etc.), ou obtenues suite à une représenation tabulaire de valeurs statistiques
(moyennes, variances, etc...).
La simulation d’un modèle stochastique (contenant de l’aléatoire) produits en
sortie des résultats aléatoires. Una analyse statistique de ces résultats s’impose donc.
Les questions auxquelles il faudra apporter une réponse sont :
Determiner la durée de la simulation.
savoir interpréter les résultats
savoir analyser les différences entre les résultats issus de plusieurs
simulations différentes (replications)
La réponse a toutes ces questions dépend de la nature du système modélisé.
L’analyse des résultats dépend de la nature du système. Dans la pratique, on
distingue les systèmes qui se terminent (leur fin est connue terminating systems) et
les systèmes sans fin (qui ne se terminent pas ; Non terminating systems).
.1
Dans une système qui se termine, la durée de la simulation est fixe. Elle peut être
spécifiée en indiquant le temps pendant on conduit la simulation, ou en spécifiant le
nombre d’entités à taiter par le système ou à injecter dans le système et qui définit
alors la condition d’arrêt de la simulation.
Exemple :
- Une banque ouvre de 8h à 17h
- Un guichet de vente de billets de stade ferme dès que les tickets sont tous
vendus.
Par définition, un système de ce type a des conditions initiales fixes et un
mécanisme marquant la fin de la simulation. Le système revient dans son les
conditions initiales avant de se remettre en route (en général ‘libre et vide’). L’objectif
de la simulation dans ce cas est d’analyser le comportement du système pour une
certaine durée qu’on se fixe. Du fait que les conditions initiales ne changenet pas, et
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
la durée de la simulation est fixe, le seul paramètre à contrôler est le nombre de
simulations à faire (réplications).
Ainsi, la procédure d’analyse des résultats va consister à conduire un certain
nombre de simulations, choisir la mesure de performance à analyser, calculer la
variance de cette mesure et determiner si l’intervalle de confiance est dans des limites
acceptables.
Exemple :
Si on veut estimer le nombre moyen de clients dans la file d’attente, on doit :
- Condure n simulations
- Calculer un intervalle de confiance pour ce nombre moyen en utilisant les
résultats des n simulations
- Si l’intervalle est trop large, on determine le nombre de simulation
supplémentaires à faire et on recommence les étapes précédentes en tenant
compte de toutes les observations et ce jusqu’à ce que l’intervalle devienne
accpetable.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
.2 &DV G·XQ V\VWqPH TXL QH VH WHUPLQH SDV
Dans une système qui ne se termine pas, la durée de la simulation n’est pas
finie puisque le système est en perpetuelle activité. Un bon exemple de ce type
système est celui d’une unité de production qui est exploité 24h sur 24 (régime 3x 8
heures) et 7 jours sur 7. Certains systèmes ne peuvent pas être arrétés à cause de la
matière traitée qui coute cher et risque de devenir inutilisable (fonderie). Tout arrêt
peut engendrer de la perte d’argent et ungrand retard pour remettre le système en
route.
L’objectif d’une simulation de ce type de système est d’analyser le
comportement du système lorsqu’il atteint un état stationnaire sur le quel les
conditions intiales n’ont plus d’effet. Pour cela, une bonne analyse du système à l’état
stationnaire nécessite l’élimination des effets des conditions initiales sur les résultats.
Il existe pour cela trois méthodes :
1T )DLUH XQH VLPXODWLRQ WUqV ORQJXH (Swanping)
Cette méthode vise à faire une simulation de très longue durée de sorte
que les conditions initiales n’aient q’un effet miniscule sur les résultats. Le problème
qui se pose est que cela peut demander un temps d’exécution énorme alors que
l’effet (le biais) des conditions initiales existera toujours même s’il est minime.
2T &RPPHQFHU OD VLPXODWLRQ j SDUWLU GH O·HWDW VWDWLRQQDLUH (Preloading)
Il s’agit de faire en sorte que les conditions initiales soient celles de l’état
stationnaire. Elle consiste à charger les files d’attentes et les ressources avec des
entités. Ceci necessite de savoir comment se présente le système lorsqu’il atteint
l’état stationnaire. On peut soit faire des observations sur le système soit conduire des
simulations d’essais et voir graphiquement l’allure du système lorsqu’il atteint un
stationnaire. Cette méthode se complique pour les systèmes complexes ou en phase
de conception.
3T 6XSSUHVVLRQ GH OD SKDVH WUDQVLWRLUH (Deletion)
C’est la phase qui est influencé par les conditions initiales. Il s’agit donc
de determiner la durée de cette phase de telle sorte à ne commencer la collectes des
observations qu’après écoulment de cette phase. Il existe des méthodes statistiques
pour determiner la période transitoire mais la plus pratique est de représenter
graphiquement la mesure de performance qui nous inetresse au cours de la
simulation et de voir à quel moment un état stationnaire est atteint.
La procedure à suivre pour l’analyse des résultats de la simulation pour le cas
d’un système qui ne se termine pas serait donc :
D) Conduire quelques simulations d’essais pour determiner la durée de la phase
transitoire
E) Faire n simulations en éliminant la phase transitoire
F) calculer un intervalle de confiance pour la mesure de performance qui nous
interesse en utilisant les observations issues des n replications. Si l’intervalle
est trop grand, on doit determiner le nombre de simulations supplémentaires
à faire en vue de réduire l’intervalle de confiance. On réalise les simulations
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
supplémentaires et on reprend en C avec toutes les observations.
8 CONCLUSION
D’un point de vue externe, on a souvent tendance à voire en l’ingénieur ou l’analyste
le seul acteur d’un projet de simulation surtout si celui-ci maîtrise bien le logiciel de
simulation qui lui sert de support pour la programmation du modèle. D’un autre coté, Il est
communément reconnu que pour pouvoir utiliser correctement et intelligemment des
méthodes de simulation, il faut disposer de connaissances plus ou moins solides dans des
domaines variés (Probabilités et Statistiques , Modélisation, Programmation, etc.).
Malheureusement, il est souvent rare pour ne pas dire impossible qu’un individu seul puisse
à lui seul disposer de toutes les connaissances requises pour pouvoir mener seul un projet
de simulation. Tout projet de simulation implique donc de près ou de loin un groupe de
personnes (structuré ou non en équipe) chacune jouant un ou plusieurs rôles dans le projet.
Par conséquent, un projet de simulation quelle que soit son envergure, ne peut et ne pourra
jamais être considéré comme l’oeuvre d’une personne isolée et ce même si les attributions
de rôle dans le projet ne sont pas faites de manière explicite.
D’autre part, la simulation en tant que méthode nécessite la constrution d’un modèle
du systeme qu’on veut analyser. Pour pouvoir faire des expérimentations sur ordinateur
avec ce modèle, il va falloir le programmer en utilisant un langage. On trouve aujourd’hui
sur le marché une multitude de langages (ou logiciels ) de simulation plus sophistiqués les
uns que les autres notamment les versions sur P.C. ou station de travail. Certaines sociétés
de développement vont même jusqu’à proposer toute une gamme de produits dont chacun
est orienté vers un domaine d’application précis (FMS, AGV, etc.). C’est le cas par exemple
de la société Pritsker & Associates qui commercialise SLAM II, TESS, MAP/1,
FACTOR/AIM, SLAMSYSTEM, pour ne citer que ceux là.
Le prochain chapitre sera donc dédié a une présentation des outils de simulation.
Nous nous limiterons aux seuls langages que nous estimons intéressants a connaitre dans
le cadre de ce cours.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
1(&(66,7(
Quelle que soit la signification donnée au mot simulation, quelle que soit la conception
qu'on a de la simulation, quel que soit l'usage qu'on en fait, il est toujours nécessaire de
construire un modèle de la réalité qu'on pourra ainsi simuler. II va donc se poser le
problème de la programmation du modèle pour un calculateur donné.
La complexité des modèles rend souvent impossible une programmation en langage
machine ou en langage assembleur, car elle est trop longue et trop couteuse ; la
programmation en un langage très general comme FORTRAN ou PASCAL est souvent
possible et represente un progres certain mais n'est malheureusement pas adaptée, car
d’une part 1'ecriture d'un modèle de simulation reste souvent longue et fastidieuse, d'autre
part le modèle resultant est souvent loin d'etre performant et il est difficile de separer
l'elaboration du modèle de son ecriture en vue de l'exploitation.
Enfin l'analyse d'un grand nombre de modèles de simulation a permis de remarquer que,
sous leur apparente diversité, on retrouvait les memes concepts et qu'il etait donc possible
de degager une methode generale, une philosophie des modèles de simulation. Il devenait
donc nécessaire de créer des langages permettant de decrire et d’utiliser commodement
les quantités et les relations caracterisant les modèles de simulation de telle sorte que cette
description terminée, il soit possible de la traduire aisement pour obtenir un modèle
entierement programmé sur un type d'ordinateur. C'est pour repondre a cette double
question qu'ont été crées les langages de simulation.
'(),1,7,21
On entend par outils de simulation les constituants d'un système, appelé généralement
système de simulation, qui foumit les moyens de mettre en oeuvre, d’animer et d'observer
les modèles, de la meme façon que le système d’exploitation d'un ordinateur foumit les
moyens de mettre en oeuvre et d’executer les programmes.
D'un point de vue exteme, le principal constituant d’un système de simulation est le
langage de simulation, qui permet de decrire le modèle et les stimuli a lui appliquer au
cours du déroulement de la simulation. Typiquement, un tel langage est obtenu en
ajoutant à un langage évolué à usage général (FORTRAN, PASCAL, ALGOL, etc ... ) les
structures de données et les primitives qui facilitent la description des modèles
dynamiques. L'aspect dynamique qui caractérise les modèles de simulation est traduit par
la description des conditions de synchronisation entre processus, la quantification de la
durée des traitements et la datation des occurrences d’événements externes. Bien
entendu, les dates et les durées font référence à une horloge simulée, qui est gérée par le
système de simulation.
Un système de simulation est aussi connu dans la littérature sous diverses appellations
telles que, logiciel de simulation, langage de simulation, simulateur, outil de simulation, etc..
. Afin de lever toute ambiguïté dans la suite, nous utiliserons indifféremment l'une
quelconque de ces appellations pour désigner un système de simulation tel qu'il a été
défini plus haut.
3DQRUDPD GHV ODQJDJHV GH VLPXODWLRQ
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Dans le domaine des outils de simulation, les efforts de développement ont porté sur deux
points :
- réduction des difficultés de conception des modèles par adaptation plus fine
des concepts aux applications;
- diminution des coûts de programmation et d’exploitation par l'emploi d’outils
plus "évolués".
Ils se traduisent par l'évolution chronologique suivante dans l'utilisation des outils de
programmation des modèles de simulation :
- langages informatiques généraux (FORTRAN, PASCAL, etc...)
- langages adaptés (SIMULA et bibliothèques de sous-programme :GASP IV,
FORTSIM , etc.)
- langages de simulation.
En ce qui concerne les langages de simulation, il existe actuellement, en complément des
simulateurs généraux (ou a usage général), des simulateurs dits ‘‘spécialisés’’ et ‘‘dédiés’’
car s'adaptant très bien a des domaines d'application précis (systèmes de production,
réseaux de communication, systèmes de manutention, etc.)
+LVWRULTXH
Décennie 1960-1970
C'est pendant cette période qu'apparaissent les premiers outils de simulation. Les deux
outils les plus répandus sont alors SIMSCRIPT et GPSS qui peut être considéré comme le
premier véritable langage de simulation. En parallèle se développe SIMULA, écrit à partir
du langage ALGOL, dont l'intérêt principal fût d'introduire de façon générale l'approche par
processus grâce à des notions, nouvelles à l'époque, de structuration de données et de
processus associés. Tous les principes de base de la simulation sont ainsi établis dès la
fin de cette période.
Décennie 1970-1980
Il n'y a pas eu de bouleversement considérable; SIMSCRIPT et GPSS offrent de
nouvelles versions qui n'apportent pas de possibilités particulières. Il convient également
de noter les premiers travaux de Alain B. Pritsker avec la lignée des langages GASP,
langage par évènements, et QGERT qui associe des primitives graphiques à des
processus.
On peut signaler aussi , en Angleterre, l'apparition du langage ECSL basé sur
l'approche par activités.
Début Décennie 1980-1990
L'émergence des problèmes d'automatisation de la production manufacturière
provoquent un très net regain d'intérêt pour la simulation et fait évoluer de façon
considérable l'offre dons le domaine.
Ainsi apparaissent SLAM (issu de GASP et QGERT), puis SIMAN, orienté vers les
systèmes de production et, en France, QNAP2, plus orienté, à son origine, vers les
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
systèmes informatiques.
GPSS et SIMSCRIPT retrouvent une deuxième jeunesse ; GPSS par une refonte
complète (nécessitée par les ajouts successifs depuis sa création) et l'adjonction de
nouvelles primitives, et SIMSCRIPT par l'introduction de la notion de processus (depuis la
version II.5).
Presque tous les langages prennent alors le virage de la micro-informatique et
proposent des versions sur compatibles PC.
Evolution actuelle
On constate actuellement une évolution très nette vers une plus grande convivialité des
outils de simulation par l'amélioration de l'environnement de travail offert (versions micro,
peu onéreuses, avec aides graphiques, environnements de haut de gamme comme TESS
et CINEMA) et la multiplication des simulateurs spécialisés, qui combinent un
environnement très convivial avec une paramétrisation des systèmes à simuler qui les
rendent directement utilisables après un minimum d'apprentissage.
On peut signaler aussi une nouvelle classe d'outils de simulation, utilisant les langages
orientés objet , et donc l'approche objet, prolongement direct des notions qui ont été
introduites par SIMULA.
Cette approche permet de concilier les avantages des différents outils, grâce à une
base de modèles directement utilisables, des objets directement paramétrables
(instanciation) ou enrichissables, et la possibilité de créer de nouveaux objets quand la
base de modèles est insuffisante.
Cette approche est particulièrement intéressante dans le domaine de l'ingénierie, où des
personnes de compétences et fonctions très diverses peuvent utiliser une même base de
modèles ou l'enrichir moyennant une connaissance du langage objet sous-jacent; elle
permet
également de développer rapidement des simulateurs spécialisés et des
modélisations plus flexibles que celles qui sont développées actuellement.
/HV ODQJDJHV GH VLPXODWLRQ JéQéUDX[
Les premiers langages de simulation ont vu le jour vers 1960, et étaient plus orientés
vers la représentation et la simulation des systèmes discontinus (à événements discrets).
Ils permettent de programmer des modèles sous-tendus par des concepts indépendants
des domaines d'application. Cette universalité ne peut se faire qu'à travers des fonctions
abstraites de type ressources, files d'attente, entités, etc. Parmi les langages constituant
les références et les racines des langages actuels et ayant profondément marqué le
domaine de la simulation on peut citer : GPSS, SIMSCRIPT, SIMULA, GASP, Q-GERT.
Le tableau suivant permet de regrouper les simulateurs généraux les plus connus :
6LPXODWHXU
6,06&5,37
3D\V
USA
'DWH
1963
6,08/$
Norvège
1966
*366
USA
1968
*$63
USA
1974
4*(57
USA
1977
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
6/$0
USA
1979
41$3
France
1980
&$36(&6/
Grande Bretagne
1980
6,0$1
USA
1982
Fig. 2-1 : Liste des langages de simulation les plus connus
Nous donnons ci-après un bref aperçu sur les langages qui nous paraissent les plus
importants compte tenu de leur usage.
é é é
GPSS(General Purpose Simulation System) est un langage offrant une approche orientée
processus. Il a été developpé intialement chez IBM en 1961, puis plusieurs versions ont vu
le jour dont la plus récente disponible chez IBM est GPSS/V. La notoriété de la société
IBM dans le domaine de l'industrie informatique a fait que GPSS soit un langage très
populaire (surtout entre 1960 et 1970) et enseigné dans beaucoup d'universités.
GPSS est un des précurseur de l'approche de modélisation par "processus " et possède un
support graphique de représentation comme la plupart des langages actuels. Un modèle
est construit à l'aide de blocs élémentaires représentant des fonctions spécifiques
(génération d'entités, entrée ou sortie dans une file d'attente, allocation ou libération de
ressource, marquage du temps quand une entité passe, etc ... ). La première version
comprenait environ 25 blocs de base alors qu'on trouve nettement plus dans les versions
actuelles. Dans GPSS, les clients ou entités qui necessitent un service a l'interieure du
système modelisé sont appelées des transactions et leurs attributs sont appelés des
paramètrès. Les serveurs ou ressources qui fournissent le service exigées par les
transactions sont appelées des Facility (ou installations) correspondant à un serveur
unique ou Storages (Stockages), correspondant a un groupe de serveurs en parallele.
De multiples améliorations ont été apportées à GPSS qui est aujourd'hui disponible sur une
variété importante de calculateurs
- GPSS/V est le produit standard d'IBM
- GPSS/H est une version développée par Wolverine Software Corporation
dont les efforts ont porté sur les points suivants : rapidité d’exécution,
enrichissement des instructions, interface d’E/S, aides de mise au point et de
recherche d'erreurs, etc...
- GPSS/PC C'est une version compatible PC développé en 1984 et
connercialisé par la societé Minuteman Software (Rangez, Massachusetts).
Elle comporte un intéressant environnement interactif de simulation avec
possibilité d’animation.
GPSS/H a été développé en 1977 et commecialisé par la société Wolverine
Software(Annandale, Virginia). C'est un langage compilé offrant beaucoup d'avantages
par rapport a la version GPSS/V d'IBM (temps d'execution plus rapide, possibilités de lire et
écrire des fichiers
externes, la production de rapports détaillés et pesonnalisés,
instructions de contrôle plus évoluées telles que la boucle Do, le IF-THEN-ELSE, une
panoplie de fonctions mathématiques,etc.). A cause de toutes ces capacités, la plupart
des modèles GPSS/H n'exigent pas l'ecriture de routines externes (dans FORTRAN ou
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
autrès langues). En plus de GPSS/H, la meme société commercialise un progiciel
d'animation appelé PROOF permettant de faire des animations graphiques en temps
différé des modèles de simulation a evenements discrets a partir d'un fichier de trace
d'execution.
GPSS/H comporte plus de 60 instructions standards dont la plupart ont une
représentation graphique sous forme de bloc dont la forme est revelatrice de l'opération
exécuté par la l'instruction correspondante. La construction d'un modèle GPSS consistera
generalement a combiner un ensemble de blocs ou symboles obtenant ainsi un
diagramme a blocs qui représente le cheminement des entités à travers le système. Ce
diagramme sera ensuite traduit par l'utilisateur sous forme de programme composé d'un
ensemble d'instruction GPSS en vue de son exécution sur ordinateur. Le diagramme a
blocs en lui-même peut être utilisé comme support de communication lors de discussions
sur le modèle.
H[HPSOH
La modélisiation de l'exemple de la banque (voire chapitre 1) avec GPSS est representé
par le diagramme a blocs suivant :
*(1(5$7(
59(;32 48(8(
6(59(54
6(,=(
6(59(5
'(3$57
/9(4
1/9(4
/
7(67
6(59(54
6723
$'9$1&(
59(;32 6723
7(50,1$7(
6(59(5
5(/($6(
La traduction de ce diagramme sous forme de programme GPSS (modèle de simulation
operationnel) conduit au programme listé ci-dessous :
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Exemple de Modèle en GPSS
" #
$%&'()&*+$%
creation -Injection des entités dans le
système
entrée dans la file d’attente
demande d’allocation du serveur
sortie de la la file d’attente
Test si l’execution est arrivée a sa fin
occuper le serveur pendant t = durée de
service
libérer le serveur
entité quitte le système
,- #+$&'+.-
faire 1 seule simulation qui dure 1000 unités
L'instruction (ligne 4 du programme ) est une instruction de contrôle nécessaire
pour l'exécution du programme. L'instruction (ligne 5) a pour role de générer des
transactions représentant des clients selon une loi exponentielle (RVEXPO) avec un temps
séparant les arrivées de moyenne 1.0 et utilisant le germe 1 pour le générateur de nombre
aléatoires. L'instruction (ligne 7) et L'instruction (ligne 11), définissent une
facility appelé SERVER, correspondent au schéma d'allocation et de libération d'une
ressource nommée SERVER par une transaction. Les transactions qui arrivent quand le
serveur est occupé rejoignent une file qui est définie par GPSS automatiquement. La durée
du service d'une transaction est dans ce cas
obtenu a partir d'une distribution
exponentielle avec une moyenne de 0.5 en utilisant le germe 2 pour le generateur de
nombres aleatoires. Cette durée est reellement consommée a l'instruction # (ligne
10). La transaction est détruite (ou ejectée du système) au bloc (ligne 12).
L'instruction ( ligne 6) et le (ligne 8) sont utilisées pour collecter des statistiques
sur les transactions qui attendent dans la file (appelée SERVERQ) devant la ressource
SERVER. L'instruction (ligne 9) est utilisé pour déterminer quand l'execution de la
simulation doit se terminer. Si le nombre de transactions, N$LVEQ qui ont traversé le bloc
étiqueté LVEQ (ou ont quitté la file d'attente) est inferieur a 1000, la transaction
sortant de ce bloc poursuit son chemin vers le bloc # autrement elle est dirigée au
bloc (instruction) etiqueté STOP dans lequel le serveur est libéré. Chacune des
1000 transactions qui entrent le bloc decremente un compteur de 1. Du fait que
le compteur pour la terminaison de la simulation a été initialisé à 1000 par l'instruction de
contrôle (ligne 16), son passage a la valeur 0 entraine la fin de la simulation.
Les résultats standard produits par GPSS / H pour cet exemple auront l'allure suivante .
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
"
SERVER
0.516
"
"
! "
"#$ $
$
1000
0.523
AVAIL
48(8(
0$;,080
&217(176
$9(5$*(
&217(176
727$/
(175,(6
=(52
(175,(6
3(5&(17
=(526
$9(5$*( $9(5$*(
7,0(81,7 7,0(81,7
SERVERQ
8
0.605
1000
454
45.4
0.614
1.124
" "
"
%
"
% "
1
2
OFF
OFF
100000
200000
101001
200999
1001
999
0.71
0.69
47$%/(
180%(5
&855(17
&217(176
0
FIGURE 3.5 Résultats de la simulation avec GPSS/H
On peut noter que le délai d'attente moyen est 0.614 (voire " "# " pour la file
SERVERQ). De meme, le nombre moyen dans la file (voire " " pour la file
SERVERQ) est de 0.605 et l'utilisation du serveur (voire " "" pour la ressource
SERVER ) est de 0.516. Les statistiques sur l'utilisation du serveur sont fournies
automatiquement quand une ressource de type facility (comme ici SERVER) est definie
par les blocs SEIZE et RELEASE. Les autrès statistiques résultent de l'usage des blocs
QUEUE et DEPART.
GPSS/PC est une version PC de GPSS . Il a été développé en 1984 et est connercialisé
par la societé Minuteman Software (Rangez, Massachusetts). Il offre plusieurs possibilités
pour la mise au point, la detection en ligne des erreurs dans le modèle, et la capacité de
voir les transactions se déplacer à travers le diagramme a bloc a l'ecran. GPSS/PC n'est
pas un compilateur, tout changement fait au modèle est directement pris en compte sans
attendre de recornpilation. Il offre aussi differentes representations graphiques pour les
facility (installation), les storages(stockages), et des histogrammes qui seront mis à jour
dynamiquement durant l'exécution de la simulation. Il offre en standard une animation a
base de caracteres (la plus simple) et offre en option une animation graphique en trois
dimensions Cependant GPSS/PC n'est pas aussi riche que GPSS/H et il sera souvent
nécessaire de recourir a l’ecriture de routines soi-meme dans un langage hote comme
Fortran pour modeliser tout ce qui ne peut pas ou est difficilement modelisable avec
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
GPSS/PC. Ses possibilités de generation de variables aléatoires sont limitées. GPSS/PC
n'est pas complètement compatible avec les versions mini-ordinateur et mainframe de
GPSS mais offre les mêmes éléments de modelisation de base (i.e., transactions et facility
ou installations) que GPSS/H.
Enfin, signalons que GPSS est un langage encore largement utilisé et son évolution le rend
incontestablement très proche des langages tels que SLAM ou SIMAN.
/H ODQJDJH 6,06&5,37
SIMSCRIPT est un langage général de programmation, orienté vers la simulation. Comme
langage de simulation, il offre l'approche par "événements" , et ne possède pas de support
graphique de représentation. Un modèle n'est alors qu'un programme, c'est à dire une
suite d'instructions. Dans ce programme on structure les données (entités et leurs
attributs) dans un entête (appelé PREAMBLE dans la terminologie du langage) ; une fois la
structure de données établie, on utilise des modules standards (CREATE, DESTROY,
REMOVE, SCHEDULE, etc ... ) pour décrire et manipuler les événements gérés par un
échéancier. L'occurrence d'un événement provoque l'appel d'un sous-programmme
décrivant le changement d'état correspondant. Les événements peuvent être déclenchés
par le monde extérieur (ex : arrivée d'une pièce), ils sont dits exogènes, ou déclenchés par
un autre événement interne (ex : entrée d'une pièce sur une machine déclenchée par
l'événement de sortie de la pièce précédente) et dans ce cas ils sont dits endogènes. Un
programme principal ou maître (appelé MAIN) permet d'établir les conditions initiales et de
lancer la simulation.
SIMSCRIPT possède une grande puissance de calcul scientifique et des possibilités de
traitement de listes, et peut être plus efficace que FORTRAN s'il est utilisé comme simple
langage de programmation (le langage permet d'écrire des programmes qui n'ont rien à
voir avec la simulation ). La version la plus récente du langage est SIMSCRIPT Il.5.
distribuée par la société CACI-Los Angeles. Celle-ci offre l'approche par "processus" ou
l'approche par "événements" ou une combinaison des deux.
/H ODQJDJH 6/$0
*éQéUDOLWéV VXU OH ODQJDJH
SLAM II (Simulation Language for Alternative Modeling) est une langage de simulaion
qui a été développé par Dennis Pegden et Alan Pritsker en 1979 et est distribué par la
société Pritsker Corporation(Indianapolis, Indiana).
Avec SLAM, un système à événements discrets peut être modélisé en utilisant
l’approche par "processus", l'approche par "événements" ou une combinaison des deux.
SLAM permet aussi de modéliser des systèmes continus grâce a des équations
différentielles ou aux différences. Pour les systèmes dits combinés, SLAM offre la
possibilité de combiner les deux approches de modélisation: à événements discrets et
continue.
SLAM offre un support graphique de modélisation dont les symboles sont des noeuds
et des arcs. Les principaux éléments de modélisation sont les Entités (munies d'attributs),
les files d'attente (ou queue), et les ressources. Un modèle à événements discrets peut
être structuré sous forme d'un réseau dans lequel circulent les entités (pièces, clients,
informations, etc ... ). Les noeuds sont utilisés pour modéliser des processus (ex - files
d'attente, serveurs, etc ... ) ou des points de décision (aiguillage, choix entre plusieurs
ressources, etc ... ). Les arcs définissent sur le réseau les chemins possibles pour les
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
entités et permettent de fixer des temps de transit. Le réseau sera traduit sous forme d'une
suite d'instructions du langage SLAM (à chaque symbole graphique est associée une
instruction ou "primitive" du langage)
SLAM II est disponible dans plusieurs versions, dépendant de la plate-forme
matérielle et des fonctionnalités offertes. Le langage de base est disponible pour toutes
les catégorie d'ordinateur, mais ne permet pas de disposer d'une animation graphique.
Cependant, il existe une version micro-ordinateur de SLAM II appelée SLAMSYSTEM
offrant un environnement de travail très convivial et qui s'intègre parfaitement a
l'environnement WINDOWS de Microsoft. SLAMSYSTEM permet entre autrès d'animer
graphiquement le modèle de simulation et d'avoir une présentation graphiques des
résultats de la simulation (courbes, histogrammes, camemberts,..).
L'envrionnement le plus complet proposé par la société est le couple SLAMII/TESS
disponible pour des stations de travail, mini-ordinateurs, et mainframes. En plus des
capacités graphiques semblable à celles de SLAMSYSTEM (animation, présentation
graphique des résultats), cet environnement s'articule autour d'une base de données
permettant de gérer les entrées/sorties du modèle et de réaliser un ceratin nombre de
fonctions statistiques sur les résultats d'une simulation comme le calcul d'intervalles de
confiance.
Avec SLAMSYSTEM ou SLAMII/TESS, l'utilisateur peut construire interactivement le
modéle sous forme de réseau directment a l'écran qui sera automatiquement traduit en un
programme source directement exécutable par SLAMII. Ceci permet d'augmenter la
vitesse et la précision de la contruction d'un modèle.
Enfin, il existe aussi une extension de SLAMII permettant de simuler des systèmes de
Manutention (convoyeur, AGV,...)
([HPSOH GH 0RGéOLVDWLRQ DYHF 6/$0
La modélisation de l'exemple de la banque peut etre représentée par le réseaux SLAM
suivant :
La traduction de ce réseau sous forme de programme informatique exprimé dans les
instructions et la syntaxe de SLAM est le suivant (les numéros de ligne ne font pas partie
du programme et sont introduits pour faciliter les explications).
L'instruction *(1 (général) de la ligne 1 spécifie lauteur du programme, le nom du projet,
la date, le nombre d'exécutions ou replication a faire (ici 1), et la longueur en caractères
d'une ligne du rapport qui contiendra les résultats (ici 72). Les virgules consécutives dans
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
une instruction stipule que l'auteur accepte les valeurs par défauts des paramètrès
respectifs. La directive spécifie que le modèle contiendra 1 file d'attente, un
maximum de 1 attribut par entité, et qu'on peut avoir au maximum 100 entités présentes
dans le modèle simultanèment . Les instructions et dans les lignes 4 et 17
indiquent le début et la fin du modèle (réseau).
!
"
# $ % & ' Definition de la ressource
Creation des clients
Attente du serveur
Collecter statistique Attente file
Occuper le serveur
Entité fictive vers comptage CNTR
Libérer le serveur
départ du client
Fin simulation si 1000 clients Servis
(
$ )*& + ' & ' % $ $& ' , -##
$%,)*&+!' $%, $ !
"
$
(
. % La directive # $ dans la ligne 6 permet de définir une ressource appelé SERVER
ayant une capacité de 1 unité (spécifié entre parenthèses). Le second "1" indique que
lorsque le SERVEUR est libre, il servira le premier client de la file d'attente 1. Les lignes qui
commencent avec les point-virgules sont des lignes de commentaire. Le noeud $ (ligne 8) permet de créer de nouveaux clients dans le système avec un temps séparant les
arrivées suivant une distribution exponentielle (EXPON) de moyenne 1.0 et dont les valeurs
seront générées aléatoirement en utilisant le germe 1 pour le générateur de nombres
aléatoires. Le premier 1 après la parenthèse de droite précise que le premier temps
séparant les arrivées sera de 1 exactement. ( CREATE impose que le premier temps
séparant les arrivées soit fixe et non une variable aléatoire) Le 1 suivant permet de
mémoriser le temps d'arrivée de chaque entité dans l'attribut 1 de l'entité. Le noeud (ligne 9) correspond a une mise en attente pour le SERVEUR. Si un client arrive et que le
SERVEUR est disponible, le client occupe le serveur immédiatement et le cheminement
dans le réseau se poursuit (passage à la prochaine ligne du programme). Dans le cas
contraire, le client est placé en dernier dans la file d'attente (FIFO par défaut). Le noeud
$ $ (ligne 10) calcule et enregistre le temps d'attente dans la file pour chaque client ; ce
temps étant égal au temps courant moins le temps d'arrivée du client se trouvant dans
l'attribut 1 de ce client. Le 2 à la fin de la ligne 10 permet de créer une copie de l'entité,
avec un exemplaire de l'entité qui sera dirigé vers la ligne 11 et l'autre vers la ligne 12.
L'entité arrivant a la ligne 11 correspond au client réel qui se déplace dans le système. La
branche $%, (ligne 11) permet de spécifer la consommation du temps correspondant a
la durée de service du client. Ce temps suit une distribution exponentielle avec une
moyenne de 0.5 et qui est générée aléatoirment en utilisant le germe numéro 2. Quand le
client termine son service, il est dirigé vers l'instruction ayant l'étiquette DONE (ligne 13). A
ce niveau, le noeud . permet au client de libérer le serveur et de passer a la ligne 14
pour sortir du système (terminaison). S'il y a des clients dans la file d'attente, le premier est
extrait de la file et occupe le serveur a la ligne 9, etc.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
L'entité fictive (copie) qui a été acheminé vers la ligne 12 est utilisé pour terminer la
simulation de manière appropriée. Elle est envoyé immédiatement au noeud TERMINATE
de la ligne 16 (étiqueté CNTR) qui incrémente de 1 le compteur. Quand ce compteur
atteint 1000, la simulation se termine.
6/$0 ,, 6800$5< 5(357
%< ..................
581 180%(5
6,08/$7,21 352-(&7 EXEMPLE
'$7( 01/01/1999
.9171E+03
&855(17 7,0(
67$7,67,&$/ $55$<6 &/($5(' $7 7,0(
1 2)
1
OOOOE+00
67$7,67,&6 )25 9$5,$%/(6 %$6(' 21 2%6(59$7,21
'(/$< ,1 48(8(
0($1
9$/8(
67$1'$5'
'(9,$7,21
&2()) 2)
9$5,$7,21
0,1,080
9$/8(
0$;,080
9$/8(
12 2)
2%6
.608E+00
.100E+01
.165E+01
.000E+00
.589E+01
),/( 67$7,67,&6
),/(
180%(5
/$%(/7<3(
$9(5$*(
/(1*7+
67$1'$5'
'(9,$7,21
0$;,080
/(1*7+
&855(17
/(1*7+
$9(5$*(
:$,7 7,0(
1
2
AWAIT
CALENDAR
.662
1.555
1.354
.497
9
3
0
2
.608
.285
5(6285&( 67$7,67,&6
5(6285&(
180%(5
5(6285&(
/$%(/
&855(17
&$3$&,7<
$9(5$*(
87,/
67$1'$5'
'(9,$7,21
0$;,080
87,/
&855(17
87,/
1
SERVER
1
.55
.497
1
1
5(6285&(
180%(5
5(6285&(
/$%(/
&855(17
$9$,/$%/(
$9(5$*(
$9$,/$%/(
0,1,080
$9$,/$%/(
0$;,080
$9$,/$%/(
1
SERVER
0
.4452
0
1
FIGURE 3.. Résultats de la simulation du modèle SLAM II
Les résultats de la simulation sont donnés dans la Fig. 3.18. On note que le délai
d'attente moyen dans la file est de 0.608 (voire "67$7,67,&6 )25 9$5,$%/(6 %$6(' 21
2%6(59$7,21"), et qui est calculé par le noeud COLCT. (Voire aussi "$9(5$*( :$,7,1* 7,0(" pour
la file d'attente 1) La longueur moyenne de la file (voire "$9(5$*( /(1*7+" pour la file 1) est
de 0.662 alors que le temps moyen d'utilisation du serveur (voire "$9(5$*( 87,/" pour la
ressource numéro 1) est de 0.55. Ces mesures statistiques sont calculés automatiquement
et fournis dans le rapport quand on utilise le noeud AWAIT.
/H ODQJDJH 6,0$1
*pQpUDOLWpV VXU OH ODQJDJH
SIMAN (SIMulation ANalysis) a été développé par Dennis Pegden en 1982 et est
distribué par la société Systems Modeling Corporation (Sewickley, Pennsylvania) . Il peut
être considéré comme un descendant de SLAM, puisque non seulement son auteur a
participé au développement de la première version de SLAM, mais encore il adopte la
même philosophie que SLAM pour la modélisation d'un système (mêmes approches,
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
mêmes principes d'interaction entre elles...). C'est un langage de simulation offrant les
deux approches de modélisation : 'orientée processus', et 'orientée événement', ou une
combinaison des deux. Dans la plupart des applications, le modèle de simulation est
développé en utilisant l'approche orientée processus. Dans le cas ou cette approche ne
suffit pas ou ne permet pas de modéliser toute la logique du système a modéliser, on peut
la combiner avec les possibilités offertes par l'approche par événement.
SIMAN a été dès son appartition largement adopté comme langage de simulation car il
fut le premier langage a être disponible en version micro-ordinateur mais aussi à cause de
primitives plus spécialement orientées systèmes de production qu’il offre. Ces primitives
permettent de définir des stations ou postes de travail, des réseaux de manutention par
convoyeur ou chariot, des gammes de fabrication, des horaires d'occupation des
ressources, etc... . Il permet aussi de définir des "sous-modèles" et de les réutiliser ce qui
permet d'éviter de dupliquer des instructions lorsque plusieurs processus de structures
identiques sont présents dans le système. Le système CINEMA développé autour de
SIMAN et dédié a la production d'animation graphique de modèle SIMAN a donné encore
plus d'atouts a SIMAN. La version la plus récente du langage est SIMAN V. Actuellement
c'est un environnement appelé ARENA intégrant les possibilité de SIMAN et de CINEMA
qui est le plus diffusé par la société.
Avec SIMAN un modèle de simulation construit selon l'approche par processus est
composé de deux parties distinctes : le modèle lui-meme (suite de macro-instuctions
SIMAN) et le cadre d'expérimentation (experimantal frame , contenant les paramètres du
modèle) qui sont stockés dans deux fichiers distincts.
Pour la modélisation selon l'approche "processus", un modèle est structuré sous forme
d'un d'un "diagramme à blocs" inspiré en grande partie de GPSS. Un diagramme est une
séquence linéaire de blocs, disposés de haut en bas à travers lequel passent les entités ;
chaque bloc représentant une fonction (création d'entités, suspension d'une activité, choix
entre plusieurs ressources...), certains pouvant représenter plusieurs. Chaque bloc est
représenté par un symbole graphique, donnant ainsi un diagramme ayant l'allure d'un
organigramme. Ce diagramme sera ensuite traduit en un programme ou a chaque symbole
du diagramme correspondra une instruction de SIMAN.
Dans le cadre d'expérimentation, on utilise des sortes de directives appelées dans la
terminologie SIMAN des éléments (ELEMENTS en SIMAN) pour spécifier la valeur d'un
paramètre particulier (par exemple, durée moyenne de service) pour la simulation en cours,
définir le type et la capacité d'une ressource , et spécifier le type de statistique qu'on veut
collecter au cours de la simulation. La séparation qui est faite entre la partie modèle, qui
définit les caractéristiques de fonctionnement du système, et la partie expérimentale qui
définit tous les paramètrès du modèle ainsi que les conditions de simulation (horizon,
conditions de prélèvement de statistiques, etc ... ) offre l’avantage de tester l'influence de
différents paramètrès sans avoir à modifier le modèle de simulation.
SIMAN offre aussi un module appelé OUTPUT Processor permettant de réaliser un
certains nombre de fonctions statistiques sur les résultats d’une simulation tels que : calcul
d’un intervalle de confiance, effectuer des test d'hypothèse sur les données produites par
l’exécution d’une simulation. Ce module permet aussi de produire des présentations
graphiques des résultats telles que des courbes, des histogrammes, etc. De plus, il donne
la possible de choisir les traitements a appliquer aux données après avoir déroulé la
simulation.
SIMAN existe en différentes versions tournant chacune sur une classe de matériel
précise (micro, station de travail, grosse machine). Cependant, avec la version PC, il est
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
possible d'utiliser un preprocessor (module) interactif appelé BLOCKS pour construire
graphiquement a l’écran le modèle de simulation sous forme de diagramme a blocs. Le
diagramme est traduit automatiquement en un programme (i.e. une suite de
macroinstructions SIMAN). Un autre module semblable appelé ELEMENTS sert pour
construire interactivement le cadre d’expérimentation. Toutes ces possibilités ne font
qu’améliorer la vitesse et la précision du processus de développement d’un modèle de
simulation. Les principaux blocs pour la modélisation dans SIMAN se rapportent aux entités
(avec leurs attributs), files d’attente (ou Queues), et aux ressources.
([HPSOH GH PRGqOH DYHF 6,0$1
La modélisation de l’exemple de la banque selon l’approche orientée processus de
SIMAN peut etre représentée par le diagramme a blocs de la figure 3.
Figure 3.9 (a) Le modèle sous forme de diagramme a blocs
La traduction de ce diagramme sous forme de programme SIMAN est donnée sur la
figure 3.
%(*,1
&5($7(
(; (; 0$5. 48(8(
6(,=(
6(59(5
7$//<
,17 &2817
'(/$<
(; 5(/($6(
6(59(5 ',6326(
(1'
générer des arrivées de clients
attente du serveur
demande d’allocation du serveur
enregistrer le temps d’attente dans la file
comptabiliser le nombre d’attentes
occuper le serveur pendant une durée
libérer le serveur et quitter le système
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Figure 3.9 (b) Le modèle sous forme de programme
(les numéros de lignes ont été introduits pour faciliter l’explication du programme et ne
font donc pas partie du programme) Le bloc (ligne 2) permet de générer de
nouveaux clients dans le système avec un temps séparant les arrivées qui suit une loi
exponentiel EX(1,1) ou le le premier "1" indique que le temps moyen séparant les arrivées
(paramètre de la loi exponentielle : moyenne) est donné par le groupe de paramètrès
numéro 1 dans le cadre d’expérimenation (sa valeur est de "1.0" et se trouve a la ligne 5 du
cadre d’expérimenation dans Fig. 3.8). Le second "1" de EX(1,1) indique le germe
(Stream) a utiliser par le générateur de nombres aléatoires. Le modificateur a pour
role de stocker le temps d'arrivée d'un client dans l’attribut numéro 1 de ce client pour un
usage ultérieur.
Quand un client arrive dans le système, il traverse temporairement le bloc (ligne 3)
et entreprend d’allouer la ressource appelée SERVER (ligne 4) qui est défini a la ligne 4 du
cadre d’expérimentation. Par défaut, la ressource SERVER est composée d’une seule
unité (un seul serveur). Si le serveur est disponible, le délai d’attente du client dans la file
(égal a zéro) est calculé et enregistré par le bloc a la ligne 5 (il est égal au temps
courant moins le temps d'arrivée du client mémorisé dans l’attribut 1 du client). Le bloc
(ligne 6) incrémente de 1 le compteur 1 pour indiquer qu’une nouvelle attente a été
observée. Quand ce compteur atteint la valeur 1000, tel que spécifié par l'élément dans la ligne 8 du cadre d’expérimenation, la simulation s’arrete. Le client consomme
réellement sa durée de service au bloc (ligne 7) auquel cas, les durées de service
sont générés aléatoirement a partir d’une distribution exponentielle EX(2,2) de moyenne
0.5 telle que indiquée par le groupe de paramètrès 2 dans le cadre d’expérimentation(ligne
6 ) et ou Le second "2" de EX(2,2) indique le germe (Stream) a utiliser par le générateur
de nombres aléatoires. Si le serveur est occupé quand le client arrive, ce client est placé
dans la file d’attente ( dans la ligne 3). Lorsque le client termine son service, il libère le
SERVEUR (ligne 8) et est ejecté du système grace au modificateur du programme
(ligne 8). S'il y a encore des clients dans la file, le premier est extrait de la file, et
entreprend les memes opérations que celles expliquées ci-dessus.
"
$
%
&
'
!
# #"
! #
Figure 3.9 (c) Le cadre d’expérimentation
L'élément (ligne 2) du cadre d’expérimentation indique le nom du projet, le nom
de l'auteur, et la date. L'élément (ligne 3) spécifie les besoins en espaces mémoire
pour le modèle, qui est ici de 100 entités (clients) pouvant séjourner simultanément dans le
système, un maximum de 1 attribut par entité, et 1 file d’attente. Les éléments dans les
lignes 4 à 6 ont été expliqués ci-dessus. L'élément (ligne 7) définit le label ou
étiquette " " a associer au compteur statistique introduit dans le modèle de
simulation a la ligne 5 grace au bloc . L'élément (ligne 9 et 10) sert a calculer
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
des statistiques telle que le nombre moyen et maximum dans la file d’attente 1 : et
pour le temps moyen d'occupation de la ressource 1 : ces fonctions sont designées
comme la variable 1 et la variable 2, respectivement. Donc, par exemple, la
variable 2 correspondra a l'utilisation du serveur ( ). L'élément (ligne 11)
spécifie qu’il y aura une seule exécution de la simulation a faire. Une forme plus générale
de cette instruction peut être utilisée pour spécifier plusieurs exécutions, une durée de la
simulation, et une période pour la mise en train du système (warmup période).
1 of 1
EXEMPLE
!"#
$# *******
# 7/12/1999
%% & .9783E+03
$$ & $
---------------------
%&'&
() %%
&
*&
(&&
$
$
' + ----------------------------------------------------------------------------------------------------------------------1 DELA Y IN QUEUE
.49558 .80138
.00000
4.04199
1000
&" ,) & $
------------------------------ %&'&
()
%%
&
*&
&
(&&
$
$
&%
----------------------------------------------------------------------------------------------------------------------1 NUMBER IN QUEUE
2 SERVER UTIL.
.50658
.51872
1.14931
.49965
%&'&
&&
---------------------------------------------1 CUSTOMER DELAYS 1000
Figure 3.9
.00000
.00000
10.0000
1.00000
978.28
978.28
-------------
1000
SIMAN : Résultats de la simulation
Les résultats de la simulation sont donnés dans Fig. 3.9. On note que le délai moyen
passé dans la file d’attente est de : 0.49558 (voire " $$ & $"). De même , le nombre
moyen dans la file et le temps moyen d’utilisation du serveur (calculé par l'élément DSTAT)
sont 0.50658 et 0.51872 respectivement (voire "&" ,) & $").
On remarque que les résultats statistiques différent entre GPSS/H et SIMAN. Ceci est
dû au fait que
les deux langages utilisent des générateurs de nombres aléatoires
différents. Cette remarque permet de souligner l'importance qu’il faudra accorder a
l’analyse des résultats dans tout projet de simulation.
#02,76:08
Comme on peut le constater d'après le tableau de la figure 1, la majorité des langages
sont issus de "l'école américaine". La concurrence qui existent au sein de cette même
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
famille (notamment entre SLAM et SIMAN) conduit à une perpétuelle évolution des
langages. Aujourd'hui, tous ces langages offrent pratiquement plusieurs approches de
modélisation (processus, événement, continue) avec possibilité de les combiner dans un
même modèle.
Les efforts de recherches et de développement issus de l'école anglaise se sont surtout
distingué par une nouvelle vision des méthodes de simulation baptisée : la simulation
visuelle interactive, et dont le précurseur est R.D. HURRION. Ceci n'a pas empêché pour
autant le développement de langages de simulation dont CAPS/ECSL offrant l’approche
par activités est à l'heure actuelle le plus connu.
En FRANCE, le langage de référence reste QNAP (Queuing Network Analysis
Program) développé par l' INRIA et BULL. C'est un outil qui permet la construction, la
manipulation et l'analyse quantitative de modèles de systèmes ayant la structure générale
d'un réseau de stations de service ( architecture d'ordinateurs, réseaux de communication,
systèmes de production, etc ... ). Dans sa dernière version QNAP2, le langage offre à
l'utilisateur un langage interactif orienté objet permettant de construire le modèle, d'en
effectuer l'analyse et éditer les résultats. Le langage QNAP2 hérite donc de toutes les
caractéristiques des langages orienté objet (définition de nouveaux objets à partir de ceux
existants, héritage de propriétés, etc.).
Enfin, nous devons souligner que bien que le langage SIMULA connaît à l'heure actuelle
un regain d'intérêt, il reste peu utilisé dans le domaine de la simulation. En effet, SIMULA
doit être vu avant tout comme un langage général de programmation permettant en plus de
traiter des problèmes de simulation. Avec SIMULA I qui est la version initiale du langage
(extension du langage ALGOL 60), un modèle de simulation est défini avec des clients et
des serveurs engagés dans des activités qui sont des procédures ALGOL avec allocation
dynamique de mémoire. L'évolution vers SIMULA-67 est caractérisée par l'apparition des
concepts de classes et d'objets, ce qui fait de ce langage le pionnier des langages orientés
objets. Il n'a pas connu à l'époque le succès qu'il aurait mérité mais a eu une influence
considérable sur la programmation objet.
/LPLWHV GHV ODQJDJHV GH VLPXODWLRQ JpQpUDX[
Les langages de simulation généraux (SLAM, SIMAN, GPSS, etc ... ) ont pour principal
avantage de pouvoir modéliser quasiment n’importe quel problème. Cependant, malgré les
améliorations perpétuelles qu'ils n'ont cessé de subir, il faut soulever quelques lacunes qui
freinent encore leur utilisation.
Les concepts qu'ils véhiculent sont très éloignés des préoccupations des utilisateurs
cibles (concepteurs de système de production, exploitants, etc ... ). Ils nécessitent une
formation particulière, un certain potentiel d'abstraction, voire dans certains cas
l'intervention de consultants spécialistes en simulation.
Le développement et la mise au point d'un programme sont assez peu conviviaux. En
effet, pour développer un programme, l'utilisateur doit créer un fichier source contenant les
instructions traduisant le modèle de simulation, le compiler, faire l'édition de liens puis
l'exécuter. Les erreurs de syntaxe sont détectées dans la phase de compilation, et les
erreurs d’exécution au cours de l'exécution du modèle de simulation. Ainsi, pour corriger
une erreur quelconque, toutes ces phases doivent être répétées, ce qui confère à ces
outils une lourdeur d'utilisation. De même que les résultats d’une simulation étaient souvent
limités (surtout sur les grosses machines) à une suite de tableaux de chiffres qu'il est
difficile et astreignant d'analyser. Il faut cependant souligner que les versions sur PC sont
généralement plus dotés en termes de fonctionnalités telle que : la présentation graphique
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
des résultats ou l’ animation graphique de la simulation.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
/HV VLPXODWHXUV VSpFLDOLVpV
Contrairement aux langages de simulation généraux, les simulateurs spécialisés
restreignent leur champ d’application à un domaine particulier (pour le cas des systèmes
de production : ateliers flexibles, réseaux de manutention, etc ... ). C'est ainsi que les
primitives qu'ils proposent pour la modélisation d'un système ont une raisonnance directe
avec le domaine plutôt que des notions abstraites telles que : ressource, file d’attente,
entité, etc...
&DUDFWpULVWLTXHV SULQFLSDOHV
Un simulateur spécialisé est un outil de simulation offrant un langage de description (ou
un système d'entrées interactif de données) dans lequel les instructions (ou primitives) sont
des objets du système a modéliser. Les primitives offertes sont, dans ce cas, des agrégats
de processus élémentaires (files d'attente, ressources, activités, etc ... ) représentant un
objet particulier du système (machine, stock, convoyeur, palette, etc ... dans le cas de
système de production) et son comportement.
Leur intérêt pratique est justifié par le fait que les utilisateurs cibles du logiciel sont pour
la plupart spécialisés dans une technique (ou un groupe de techniques), telle que la
manutention, les cellules d'assemblage, etc.... mais ne sont pas particulièrement formés
aux langages de simulation généraux. Il serait donc plus utile de travailler avec un outil qui
recouvre une famille de problèmes, plutôt que de rebâtir à chaque fois un modèle à partir
de primitives générales abstraites.
$YDQWDJHV HW LQFRQYpQLHQWV
Un des avantages des simulateurs spécialisés est la réduction des efforts de
conceptualisation à fournir dans l'étape de modélisation. La figure 2-3 permet de montrer
la simplicité de représentation d'un même problème (ici la modélisation d'un aiguillage
divergent du réseau de manutention) en utilisant un simulateur spécialisé "réseaux de
manutention", et un langage de simulation général (ici SLAM II).
Fig 2-2: Modélisation d'un aiguillage divergent avec simulateur général et simulateur
spécialisé (d’apres Cernault 88)
On remarque qu'avec SLAM, la modélisation utilise de l'ordre de 6 noeuds, alors qu'avec le
simulateur spécialisé celle-ci tient en une seule primitive facile à mémoriser.
Il faut cependant souligner que ce type de simulateur est fermé. L’utilisateur ne peut
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
utiliser que les régles d'ordonnancement et les régles de pilotage présentes dans le
simulateur. Il ne peut en créer d’autrès. De plus, aucun simulateur spécialisé ne peut
prétendre modéliser et simuler tous les types de systèmes de production dans leur grande
variété. De ce fait un bon simulateur spécialisé doit donc être le résultat d'une synthèse de
nombreux cas de systèmes réels de façon à contenir les régles principales de gestion et de
pilotage du domaine.
/ RIIUH HQ VLPXODWHXUV VSpFLDOLVpV
Il peut exister autant de simulateurs spécialisés que de familles de systèmes à
événements discrets. Actuellement il existe beaucoup de simulateurs de ce type dans le
commerce. Le tableau de la figure 2-3 regroupe quelques exemples de simulateurs
spécialisés avec leurs domaines d'application respectifs.
Simulateur
Sociétés
Domaine
Pritsker Associates - USA
systèmes de production
INRIA/SIMULOG - France
Ateliers Flexibles
SERI/RENAULT Automation
Circuits de manutention
RAMSES Automation - France
Ateliers Flexibles
CACI-Los Angeles - USA
Réseaux locaux LAN
CACI-Los Angeles - USA
Réseaux Télécom WAN
Fig 2-3 : Liste de quelques simulateurs spécialisés
Il faut aussi préciser que des langages généraux tel que SLAM ou SIMAN possèdent
des extensions orientées vers les systèmes de production, offrant en plus des primitives
d'usage général, des primitives pour représenter des réseaux de convoyage, des gammes
opératoires, etc... . Enfin certains simulateurs spécialisés sont couplables à des langages
généraux, ce qui permet de réaliser des modèles tirant à la fois des avantages des deux
types d'approches.
D'autre part, il faut noter qu'il existe plusieurs autres langages ou progiciels . On peut
mentionner par exemple MODSIM II et SIM++ qui sont deux langages basés sur une
approche orientée objet encourageant la reutilisation du logiciel et peuvent meme
s'executer sur des plateformes multi-processeurs d'ou la possibilité de paralleliser
l'execution d'un modèle de simulation . De meme qu'il existe de nombreux progiciels de
simulation qui ont été développés spécifiquement pour le domaine industriel. Des exemples
sont : AutoMod II, ProModel, SIMFACTORY ,WITNESS, et XCELL+.
NETWORK II.5 est un simulateur dédié pour les systèmes informatique en général et plus
particulièrement adapté pour la modélisation des réseaux locaux de communication (Local
Area Networks). Les blocs de bases offerts pour construire un modèle sont les unités de
traitements (par exemple, un CPU), les unités de transfert de données (par exemple, un
bus), les unités de stockage (exemple, une unité de disques), et les modules logiciel.
COMNET II.5, est aussi un simulateur dédié pour les réseaux de télécommunication
larges(Wide Area Networks). Les blocs de bases offerts pour construire un modèle sont la
topologie du réseau (noeuds avec leurs connexions), le traffic dans le réseau (source,
destination, et taille des messages), et les opérations dans le réseau (stratégies de routage
des messages). Ces deux simulateurs sont distribués par la societé CACI (los Angeles).
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
)DFWHXUV D FRQVLGpUHU GDQV OH FKRL[ G XQ ODQJDJH
Beaucoup d’auteurs ont traité les problèmes posés par le choix d'un outil lorsqu'on veut
résoudre un problème par la simulation. Le but de ce paragraphe est de montrer les
facteurs sur lesquels se basent les utilisateurs pour effectuer leur choix.
3UREOqPHV OLpV j O XWLOLVDWLRQ G XQ ODQJDJH
La programmation du modèle conceptuel nécessite un langage. Or, on a vu que le
développement du modèle conceptuel passe par une étape d'analyse à l'issue de laquelle
on doit définir pour chaque constituant du système physique, le degré de détail minimum
nécessaire, compte tenu du problème posé. Lorsqu'un sous-ensemble du système
physique a été retenu pour l'étude, il faut faire le choix de l'outil informatique le mieux
approprié pour assurer le passage d'un modèle conceptuel à un programme d'ordinateur.
En pratique, il est rare qu'un utilisateur ait à sa disposition plusieurs langages pour
pouvoir soulever ce problème de choix. De plus, un utilisateur expérimenté avec n'importe
quel langage de simulation peut, moyennant des efforts supplémentaires, simuler les
fonctionnements les plus complexes d'un système. On peut faire à ce niveau une analogie
avec le domaine de la programmation où, face à un problème donné, l'utilisateur choisit le
langage qui est le mieux adapté au domaine de son application (COBOL pour les
problèmes de gestion, FORTRAN pour le calcul scientifique, etc ... ). Cependant si le
langage adéquat n'est pas disponible, le problème peut toujours être résolu en utilisant un
autre langage moyennant, bien sûr, des efforts supplémentaires.
Nous avons déjà évoqué l'avantage des langages de simulation par rapport aux
langages classiques de programmation, et qui réside dans le fait que la modélisation et la
programmation par connexion de primitives standards sont beaucoup plus rapides et plus
sûres que l'écriture de sous-programmes (FORTRAN ou PASCAL) permettant de
représenter un fonctionnement identique. De même, qu'un simulateur spécialisé présente
l'avantage d'être plus souple d’utilisation qu'un langage de simulation général.
&KRL[ GHV XWLOLVDWHXUV
Si on se place au niveau des langages de simulation généraux, il serait intéressant de
connaître quels sont les facteurs qui guident le choix de tel ou tel langage dans la
réalisation d'une simulation. En d'autrès termes, existent-ils des langages qui sont plus
utilisés que d'autrès, et si c'est le cas quels sont les caractéristiques qui les privilégient par
rapport aux autrès. A titre indicatif, des statistiques sur les taux d’utilisation des langages
de simulation (en FRANCE et aux U.S.A. ) ont donné les résultats suivants :
Fig. :Utilisation des simulateurs en FRANCE [Ammar 87]
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Fig. 5 : Utilisation des simulateurs aux U.S.A.
(a): d'après [ Banks 85], (b) : d'après [Mittra 84]
(*) AUTRES signifie ici que les simulations sont réalisées avec un langage autre que ceux
cités (simulateur spécialisé, langage informatique général, langage de simulation non
considéré par l'enquête, développement interne, etc...).
Nous pouvons constater d'après ces résultats, que GPSS et SIMSCRIPT sont les plus
utilisés aux U.S.A., et devancent nettement SLAM qui par contre est le plus utilisé en
FRANCE (25%). On peut a priori penser que les résultats relatifs à l'utilisation des
langages aux U.S.A. ne sont pas révélateurs du fait que les enquêtes auprès des
utilisateurs ont été réalisées à des dates (1983 pour (a) et 1984 pour (b) où les langages
tel que SLAM ou SIMAN étaient peu connus (spécialement SIMAN), alors que les deux
autrès (GPSS, SIMSCRIPT) étaient les plus anciens.
De plus, ces langages n'ont cessé d'évoluer, et il n'est pas étonnant de voir aujourd'hui,
GPSS ou SIMSCRIPT rivaliser avec SLAM ou SIMAN.
De même, le fait que SLAM (25%) soit plus utilisé en FRANCE que son concurrent SIMAN
(10%), laisse sous-entendre que ce dernier est moins "puissant". Or, seul SIMAN offre par
exemple la possibilité de séparer le modèle de simulation du cadre d’expérimentation , de
définir des sous-modèles, de disposer en standard de primitives orientées systèmes de
production, d'offrir des outils d'aide à l'analyse des résultats. Ceci montre davantage que
l'utilisation d'un langage n'est pas liée a priori à sa puissance, mais plutôt à sa diffusion.
6LPLODULWpV HQWUH /DQJDJHV GH VLPXODWLRQ
Dans le domaine de la simulation à événements discrets, les langages de simulation qui
existent sur le marché, offrent presque tous une ou plusieurs approches de modélisation
pour construire un modèle de simulation à événements discrets. Certains auteurs ont
montré qu'un même problème de simulation à événements discrets peut être résolu en
utilisant différents simulateurs. Ceci est en grande partie dû au fait que ces simulateurs ont
en commun une ou plusieurs approches de modélisation. L'approche qui est généralement
la plus utilisée est l'approche dite par "processus". Cependant le problème peut aussi
être résolu en utilisant un simulateur n'offrant pas cette approche comme c'est le cas de
SIMSCRIPT (dont les premières versions n'offrait que l'approche par "événements") où il
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
faudra alors décrire la logique associée à chaque événement. Il faut remarquer aussi que
chaque simulateur permet à l'utilisateur d'avoir une vision différente du système réel à
modéliser (réseau dans SLAM, diagramme à blocs dans GPSS ou SIMAN, graphe à
événements pour les langages offrant uniquement l'approche par "événements", etc...).
Si on considère les simulateurs offrant une approche par "processus" (généralement
disposant d'un support graphique pour la modélisation de leurs primitives), on peut
remarquer qu'il existe beaucoup de similarités entre leurs primitives de modélisation. Ceci
montre que le problème du simulateur n'est pas un handicap pour le développement d'un
modèle de simulation à événements discrets.
Le tableau suivant montre quelques
similarités entre des notions utilisées dans quatre langages de simulation parmi les plus
connus à l'heure actuelle
*366
6,06&5,37
6/$0
7UDQVDFWLRQ (QWLW\
3URFHVV
(QWLW\
)DFLOLWLHV
6WRUDJHV
5HVRXUFH
5HVRXUFH
5HVRXUFH
&KDLQ
)LOH
6HW
)LOH
*(1(5$7(
&5($7(
$&7,9$7(
$Q
&5($7(
6(,=(
$'9$1&(
5($/($6(
6,0$1
6(,=(
'(/$<
5($/($6(
5(48(67
:25.
5(/,148,6+
$:$,7
$&7,9,7<
)5((
Notion utilisée pour désigner
tout objet pouvant subir des
services
Notion utilisée pour désigner
tout objet pouvant exécuter un
service
Structure utilisée pour gérer les
objets en attente d'un service
Primitive d'injection d'entités
dans le système
Séquence
de
primitives
modélisant une opération sur
une ressource :
....Demande de la ressource
....Acquisition de la ressource
.....Libération de la ressource
Fig. 4- 1: Quelques similarités entre les langages de simulation
On constate d’après ce tableau que les notions de base sont très similaires d'un
langage à l'autre. Certains simulateurs utilisent parfois la même terminologie pour désigner
des notions similaires. Sur un plan purement pratique, il existe certainement des
différences au niveau de l'implémentation de ces notions par les langages ainsi qu'au
niveau des paramètrès associés à des primitives réalisant des fonctions similaires.
Une étude en vue d’établir une liste de critères dont souhaitaient disposer les utilisateurs
au sein d’un outil de simulation avait été menée aux USA en 1994 par [Mac 94]. Les
résultats de cette étude sont à notre avis très significatifs vu la notoriété des sociétés qui
avaient participé à cette étude (IBM, Pritsker & Associates, CACI, Xerox, Aerospace, etc.)
et dont certaines ont une grande expérience dans le développement du Logiciel de
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
simulation et d’autrès comme utilisatrices de ce type de logiciel. Les dix critères qui ont
été retenus par cette étude et classés par ordre de priorité sont les suivants :
Orde
1
2
3
4
5
6
7
8
9
10
Critère
Interface H/M conviviale
Possibilité de disposer d’une B.D. pour organiser les données
Outil de mise au point (Debogueur)
Interaction Via une Souris
Section d’assistance dans la documentation du L.S.
Sauvegarde des modèles de simulation
Sauvegarde des Résultats
Entrée des données et des commandes par clavier
Librairie de modules réutilisables
Affichage graphique des données et Résultats Statistiques
Fig 6 : Liste des critères par ordre de priorité (d’après [Mac 94])
D’un autre coté, certains auteurs proposent des critères sur lesquels on peut se baser
pour évaluer un simulateur. Parmi l'ensemble des critères cités dans la littérature, ceux qui
semblent faire l’unanimité peuvent s’enumerer comme suit :
- Exploitabilité du produit : ces critères sont directement liés aux soins apportés par le
concepteur à la diffusion de son produit (documentation, souplesse d'utilisation, portabilité,
maintenance, possibilités d'enrichissement du simulateur, etc...)
- Puissance du produit : ces critères définissent l'aptitude du simulateur à décrire les
entités physiques de base du système a modeliser (ex: système de production) et les
phénomènes caractérisant leur fonctionnement et leur gestion (ressources, entités ou
clients, activités, files d'attente, blocages, choix entre plusieurs activités, etc...)
- Etablissement du modèle ces critères déterminent l'accessibilité du simulateur à des
utilisateurs non spécialistes (représentation graphique du modèle, simplicité de
représentation des entités physiques les plus courantes telles que : machines, stocks, etc...
évitant au maximum l'abstraction et les difficultés de conceptualisation, approche structurée
et évolutive du modèle, etc...) ;
- Programmation et mise au point du modèle : ces critères nécessitent une transparence
du système informatique sur lequel est implanté le simulateur, possibilité d'avoir une
approche modulaire pour construire un modèle (réutilisation de sous-modèles, création de
bibliothèques de sous-modèles, etc ... ), un dialogue de qualité avec le simulateur (TRACE,
sorties graphiques, messages d'erreurs, etc...) ;
- Exploitation des résultats : le simulateur doit disposer d'outils permettant d'aider à
l'analyse des résultats de la simulation (calcul statistiques sur les variables, éditions
graphiques des résultats, possibilités de stocker des modèles et de les expérimenter avec
des jeux de données différents, rapidité d'exécution de la simulation, etc...
Des études comparatives suivant différents points de vue des langages les plus connus
sont proposées par beaucoup d'auteurs. Ces études se limitent pour la plupart à l'aspect
qualitatif lié au facilités offertes par les langages pour le passage du modèle conceptuel au
programme, et/ou à l'aspect quantitatif lié aux performances d'implémentation du logiciel tel
que le temps d'exécution, l'espace mémoire requis, etc... On pourra, par exemple trouver
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
une comparaison entre :
• GPSS et SIMSCRIPT dans [Ehrmann 70]
•SLAM, GPSS, SIMAN, SIMSCRIPT dans [Banks 85]
•GPSS, SLAM, SIMAN, QNAP2 dans [Cernault 88]
•SLAM, GPSS, SIMSCRIPT dans [Pritsker 79].
L'utilisation des critères énoncés ci-dessus, avec éventuellement des résultats issus d'une
étude comparative, peuvent beaucoup aider dans le choix de l'outil le plus approprié.
Parmi ces critères, nous pensons que certains peuvent influer beaucoup sur le processus
de conception et de réalisation d'une simulation et en particulier les interfaces utilisateurs
qu'offre le simulateur.
,PSDFWV GHV LQWHUIDFHV JUDSKLTXHV GDQV OHV VLPXODWHXUV
Il est admis que le graphisme peut rellement aider à simplifier le processus de
développement et de mise au point d'un modèle de simulation. Cette aide se situe aussi
bien en entrée, qu'en sortie du simulateur.
,QWHUIDFH JUDSKLTXH HQ HQWUpH GX VLPXODWHXU
Dans le domaine des langages de programmation, certains auteurs ont mené des
études visant à déterminer si l'utilisation d'un organigramme avait une influence sur le
processus de conception et de mise en oeuvre d'un programme sur ordinateur., Les
résultats ont montré que les programmes développés à partir d'organigrammes établis au
préalable, étaient plus structurés, réduisaient les temps de mise au point et étaient plus
facile à communiquer. Malheureusement, des études similaires n'ont pas, à notre
connaissance, été faites dans le domaine des langages de simulation. En effet, la plupart
des langages proposent un support graphique (Blocs, Réseaux, Cycles d'activité, etc ... )
pour la modélisation de leurs primitives, mais rien ne permet a priori d'affirmer que
l'utilisation d'un tel support a une influence sur le processus général de modélisationsimulation. En l'absence de tels résultats, il serait évidement tentant de faire une analogie
avec les langages de programmation, en assimilant la représentation graphique du modèle
de simulation à un organigramme, auquel cas on aboutirait au mêmes conclusions que
celles énoncées pour les langages de programmation. Cependant il faut bien remarquer
que dans le cas d'un organigramme, les symboles utilisés sont normalisés et indépendants
du langage de programmation cible, ce qui leur confère un caractère d'universalité, alors
que le symbolisme graphique proposé par les langages de simulation n'est pas normalisé
et reste propre à chaque langage. Ainsi, dans le premier cas, l'utilisateur conçoit et
développe l'organigramme en ignorant les particularités du langage de programmation
cible. Dans le second cas, l'utilisateur est obligé de se familiariser avec le symbolisme
offert par le langage de simulation cible ( et donc avec le langage lui-même ! ) afin de
concevoir et développer un modèle de simulation. Cette différence essentielle nous
conduit à émettre des réserves quant à la généralisation des résultats énoncés pour les
langages de programmation, d'autant plus que nous avons déjà souligné le fait qu'un
utilisateur expérimenté dans n'importe quel langage de simulation pourrait, moyennant des
efforts supplémentaires simuler les fonctionnements les plus complexes d'un système, et
ceci même si le langage n'offre pas de support graphique de modélisation (cas de
SIMSCRIPT) .
En revanche sur un plan purement informatique, il est évident qu'un langage de
simulation muni d'un support graphique pour la modélisation, serait privilégié par rapport à
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
un autre n'ayant pas cette particularité. Ceci s'explique par le fait que dans le premier cas,
la phase de traduction de la représentation graphique du modèle de simulation en une
suite d'instructions du langage de simulation cible peut être entièrement automatisée (ex:
BLOCKS de SIMAN fig 6) sur un matériel offrant les ressources nécessaires (logiciel
graphique, écran graphique, souris, etc ... ). Cette façon de faire présente beaucoup
d'avantages dont :
• élimination des erreurs de programmation,
• diminution des délais de développement des projets,
• convivialité du simulateur.
Fig 6 : Interface du module BLOCKS de SIMAN
,QWHUIDFH JUDSKLTXH HQ VRUWLH GX VLPXODWHXU
L'utilisation d'un support graphique dans l'interface de sortie du simulateur constitue
aussi un aspect très important. Nous entendons par interface de sortie, la nature des
résultats fournis à l'utilisateur ainsi que la forme sous laquelle ils lui sont présentés par le
simulateur. Il s'agit rnajoritaù-ement de résultats numériques permettant de représenter de
manière agrégée ou détaillée le comportement dynamique du système modélisé et de ses
différents composants. Nous essayerons d'analyser ce problème sous deux angles
différents c'est à dire :
• L'utilisation du graphisme pour la présentation des résultats statistiques de la
simulation ;
• L'utilisation du graphisme pour la visualisation du comportement dynamique
du modèle (animation graphique).
3UpVHQWDWLRQ JUDSKLTXH GHV UpVXOWDWV VWDWLVWLTXHV
La forme de présentation de résultats statistiques qui est habituellement adoptée par les
simulateurs est la forme tabulaire, c'est à dire un ensemble de tableaux de chiffres ou
rapports (voire résultats fournis par SIMAN ou SLAMII)dont la richesse en information varie
d'un simulateur à un autre. Il est communément admis que l'analyse de résultats présentés
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
sous cette forme est une tâche difficile qui demande beaucoup de temps, et le taux
d'erreurs dûes à une mauvaise interprétation a tendance à augmenter avec le volume des
résultats à analyser.
L'utilisation du graphique comme support de présentation des résultats statistiques est
une technique qui a été adoptée depuis longue date par les simulateurs. En effet, presque
tous les simulateurs offraient des fonctions standards permettant de générer des formes
graphiques simples sans nécessiter de matériel spécial. Le dessin est généralement
obtenu à partir de caractères alphanumériques et peut être affiché sur un écran ou édité
sur une imprimante alphanumérique. Cette solution, facile à mettre en oeuvre, continue à
être largement utilisée et spécialement sur les gros ordinateurs. Cependant elle ne permet
pas d'utiliser la couleur, et par exemple, le dessin d'un histogramme circulaire reste une
opération pratiquement impossible à réaliser.
C'est ainsi que les recherches qui ont été menée dans ce domaine se sont surtout
focalisées sur l'aspect qualitatif des diagrammes présentés incluant notamment de la
couleur et du graphique haute résolution.
%0258
9LVXDOLVDWLRQ GX FRPSRUWHPHQW G\QDPLTXH GX V\VWqPH
Nous n'avons analysé jusqu'ici que le problème de l'adjonction de diagrammes aux
résultats statistiques,d'une simulation et l'intérêt que cela pouvait représenter au niveau de
l'interface de sortie du simulateur. Il faut cependant remarquer que les résultats d'une
simulation peuvent aller de valeurs moyennes de certaines variables d'état du système
jusqu'à la liste exhaustive des événements qui ont lieu dans le système. Les résultats
synthétiques sont utilisés pour le calcul des indices de performances du système par contre
on se sert généralement de la liste des événements à des fins de mise au point ou pour
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
déterminer les conséquences immédiates d'une décision de pilotage. Dans ce deuxième
cas, l'utilisateur avait à reconstituer à partir d'une liste séquentielle d'événements, une
image mentale des interactions qui ont eu lieu entre les différents composants au cours de
la simulation . Cette tâche est très difficile surtout quand on sait qu'une trace d'exécution
d'une simulation peut s'étendre sur plusieurs pages de listing. Il fallait donc recourir à une
autre forme de présentation permettant à la fois de condenser cette masse d'informations
alphanumériques et de rendre compte de chaque changement d'état au moment où il se
produit et de façon mieux perceptible par l'utilisateur.
----------------------------------------------------------
!"#
$%&'(
!"#
Entity batch size 1 created
QUEUE Entity sent to next block
INSPECTO( 1) avail is 2, 1 UNIT(S) REQD
Entity alloc 1 unit(s) at block
Delay by .7930E+01 time unit(s)
Entity batch size 1 created
QUEUE Entity sent to next block
INSPECTO( 1) avail is 1, 1 UNIT(S) REQD
Entity alloc 1 unit(s) at block
Delay by .8427E+01 time unit(s)
.............................................. A suivre ..................................
Fig .... Un exemple de Trace d'execution d'une simulation
Compte tenu de la nature des objets composants un modèle de simulation à
événements discrets (entités, pièces, machines, ressources, etc ... ), la solution la plus
naturelle serait donc d'associer au système qu'on désire simuler une représentation
imagée, quel que soit son type (iconique, symbolique, etc ... ), dont les éléments seraient
en correspondance avec les composants de ce système, et sur laquelle on appliquerait des
transformations ou des changements chaque fois que le système change d'état au cours
de la simulation. Ainsi on pourrait observer visuellement l'évolution de l'état du système au
cours de la simulation et se concentrer uniquement sur l'analyse de ce qu'on voit et réagir à
toute les situations au moment ou elles ont lieu. Cest cette technique qu'on appelle
couramment une "animation graphique de la simulation".
&RQFHSWV G XQH VLPXODWLRQ YLVXHOOH LQWHUDFWLYH 9,6
La majorité des systèmes d'animation graphique connus sont issus de l'école
américaines. Leur principale caractéristique est qu'ils sont issus d'un couplage entre un
simulateur (souvent général) et un module pour l'animation graphique. Dans cette
approche, l'intéractivité n'est pas, en général, prise en considération ou ne l'est que
partiellement.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Les concepts de simulation visuelle interactive (V.I.S.) ont eu pour précurseur R.D.
Hurrion de l'université de Warwick (G.B.). V.I.S. peut être considérée comme une
méthodologie tirant à la fois des avantages du graphique et de l'interactivité.
0RWLYDWLRQV SRXU 9,6
L'étude par simulation de plusieurs cas de systèmes réels, a montré qu'il était
pratiquement impossible d'encapsuler dans un même modèle de simulation toutes les
règles de conduite du système réel. Certaines situations non prévues à l'avance peuvent
se produire au cours de la simulation et ne peuvent être contrôlées que par le ou les
responsable(s) de production. Il fallait donc développer des outils de simulation capables
de passer le contrôle à l'utilisateur chaque fois qu'une décision devait être prise. Cette
interaction avec une simulation en cours nécessite la connaissance de l'état courant du
système afin d'envisager une quelconque décision. C'est ainsi qu'une illustration de
l'exécution de la simulation sous forme d'une animation graphique à l'écran apparût comme
la solution idéale. Grâce à cette approche, il devient même possible de tester des
algorithmes d'ordonnancement programmés à l'avance avant de les implanter sur le site.
&DUDFWpULVWLTXHV G XQ V\VWqPH 9,6
Un système V.I.S. est caractérisé essentiellement par la possibilité d'interrompre une
simulation en cours afin d'apporter des modifications au modèle de simulation et/ou au
schéma d'animation. Dans les premièrs systèmes V.I.S., l'interaction était guidée par le
système qui redonnait la main à l'utilisateur chaque fois qu'une décision devait être prise ou
que des informations complémentaires étaient nécessaire pour poursuivre la simulation. A
titre indicatif , le système VISION(VISual Interactive simulatiON) développé par R.D.
Hurrion comme une extension du langage de simulation SIMON était basé sur ce type
d'interaction.
Les systèmes V.I.S. actuels n'adoptent plus cette approche et sont essentiellement
basés sur une interaction guidée par l'utilisateur. C'est donc l'utilisateur qui décide des
instants -où il doit interrompre la simulation. Pour cela, il se base sur ce qu'il voit à l'écran
et par conséquent, plus le schéma d'animation ressemble au système réel qu'il représente,
plus les réactions de l'utilisateur seront instantanées. Les premiers systèmes V.I.S. étaient
tous basés sur des animations à base de caractères (trop abstraite) qui sont difficiles à
appréhender même pour l'utilisateur le plus expérimenté. Durant ces dernières années les
systèmes ont beaucoup évolué et les animations graphiques sont pour la plupart
comparables à celles disponibles dans les systèmes comme CINEMA.
/ RIIUH HQ V\VWqPHV 9,6
Les systèmes V.I.S. ont été commercialisés pour la première fois en 1979. Il existe à
l'heure actuelle, deux systèmes qui sont parmi les plus représentatifs de cette nouvelle
génération d'outils.
/H V\VWqPH 6((:+<
Le système SEE-WHY se présente sous forme d'une librairie de routines FORTRAN
permettant de réaliser toutes les fonctions nécessaires à la simulation (gestion de l'horloge,
de l'échéancier, génération des nombres aléatoires, etc ... ) ainsi que celles nécessaires à
l'interactivité et à l'animation. Dans sa version initiale, SEE-WHY n'offrait que des
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
animations à base de caractères très élémentaires alors que dans la dernière version
(1986) il permet en plus de prendre en compte la couleur et la possibilité de rajouter un
fond statique (décor) au schéma d'animation.
Avec SEE-WHY, un modèle de simulation est développé selon l'approche de
modélisation dite "par événements" qui consiste à décrire sous forme d'un programme
FORTRAN toute la logique de fonctionnement correspondant à chaque événement Pour
cela, le système SEE-WHY met à la disposition du programmeur la librairie de routines
(citée plus haut) qui lui permet de coder le modèle de simulation ainsi que tous les aspects
liés à l'interaction et à l'animation graphique. L'interaction avec le système au cours de la
simulation permet à l'utilisateur de changer n'importe quel paramètre du modèle de
simulation ou du schéma d'animation et de voir l'effet de ce changement instantanément à
l'écran (Consulter et changer n'importe quel attribut d'une entité, déplacer une entité d'une
file d'attente vers une autre, Changer la position d'un élément du schéma d'animation sur
l'écran , etc...
Le système offre aussi à l'utilisateur la possibilité d'écrire sa propre procédure
d'interaction qui sera activée chaque fois que ce dernier interagit avec le système. Cette
procédure aura pour rôle de demander à l'utilisateur les types de changements qu'il désire
apporter au modèle afin de faire les appels nécessaires aux routines SEE-WHY prévues à
cet effet. Cette approche est d'un grand intérêt pratique car elle permet de programmer
une interface sur mesure pour l'utilisateur final du modèle.
/H V\VWqPH :,71(66
Ce système est inspiré en grande partie de SEE-WHY et était initialement connu sous le
nom de FORSIGHT. Il a été développé en 1981 sur un micro-ordinateur IBM PC-AT.
Aujourd'hui, il est commercialisé sous le nom de WITNESS, et peut être considéré comme
le leader des systèmes V.I.S. sur le marché. A la différence de SEE-WHY dont le domaine
d'application est très général, WITNESS est plutôt un système V.I.S. dédié aux systèmes
de production. Un modèle de simulation est construit à partir des notions de pièce,
machine, convoyeur, palettes, etc.... qui sont des notions très caractéristiques des
simulateurs spécialisés.
WITNESS adopte une approche totalement différente de l'approche traditionnelle
consistant à développer le modèle de simulation, le compiler, faire l'édition de liens et
ensuite l'exécuter. Dans WITNESS la construction du modèle se fait de façon progressive
en rajoutant à chaque étape un composant ou un groupe de composants du système de
production. Le modèle obtenu à chaque étape peur être exécuté immédiatement sans
nécessiter de compilation. Cest donc là une caractéristique très importante car elle met
bien en évidence l'intérêt d'une simulation interactive par rapport aux approches
traditionnelles.
WITNESS permet grâce à une interface basée sur un ensemble de menus graphiques,
de construire un modèle de simulation, l'animer, le modifier sans quitter l'environnement de
travail. Parmi les principales fonctions accessibles on peut citer :
- Définition des éléments du modèle (Define phase) : Cette phase est utilisée
pour définir la structure du modèle en fonction des composants physiques du système de
production (machines, pièces, convoyeurs, palettes, etc ... ). L'utilisateur doit associer à
chaque nouveau élément qu'il rajoute au modèle, un nom permettant de l'identifier. Il peut
associer aux entités des attributs numériques (entier ou réel) permettant de transporter une
information propre à chacune d'elles tout au long de leur séjour dans le système (numéro
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
de pièce, temps d'usinage, etc...). Ces attributs sont référencés par des noms au même
titre que les autrès éléments du modèle. De même, il est possible d'utiliser des variables
pour stocker des valeurs numériques tels que le temps opératoire d'une machine, les
temps séparant les arrivées des entités, la quantité de production, etc. Ces variables
peuvent être utilisées n'importe où dans le modèle sans aucune restriction.
- Construction du schéma d'animation (Display Phase) : Chaque élément du
modèle de simulation peut être représenté par une icône graphique qui sera positionnée à
l'écran grâce à une souris. Les icônes peuvent être crées pour le besoin spécifique de
l'application ou choisies dans la librairie du système qui contient en standard 20 icônes
prédéfinies. Le positionnement des icônes peut être effectué dans l'une des quatre
fenêtrès offertes par WITNESS et dont une seule est active à chaque instant . Ceci est très
pratique surtout pour la modélisation des gros systèmes qu'on peut alors décomposer en
sous-systèmes dont chacun peut être visualisé dans une fenêtre différente.
- Définition des paramètres du modèle (Detail Phase) : Cette phase permet de
définir les paramètrès associés à chaque élément du modèle (type de machine, longueur
d'un convoyeur, taille des lots, etc..). Tous les paramètrès liés à la temporisation des
opérations doivent aussi être définis à ce niveau (temps opératoire d'une machine, vitesse
d'un convoyeur, temps séparant les arrivées des pièces, temps moyen entre les pannes,
etc..). La spécification d'un paramètre quelconque se fait à travers une série de questionsréponses avec le système. Enfin le flux des pièces dans le système est défini grâce à des
régles prédéfinis dans WITNESS Chaque élément du modèle (machine, convoyeur,
palette, etc ... ) possède des régles dites d'entrée et de sortie permettant soit de lui charger
une pièce ou de le décharger d'une pièce.WITNESS offre sept (7) régles de base pouvant
être combinées pour permettre la modélisation de routages très complexes.
En plus de l'animation graphique, WITNESS permet aussi l'édition d'un rapport sur les
statistiques d'utilisation des éléments du système (taille moyenne des files d'attente, temps
moyens passés par une pièce dans une file, pourcentage de temps qu'un convoyeur est
resté bloqué, etc ... ). De plus, si la modélisation d'un système ne peut être totalement
réalisée avec WITNESS, ce dernier offre la possibilité à l'utilisateur de développer des
sous-modèles en SEE-WHY et de les lier au modèle principal.
,QWpUrWV SUDWLTXHV G XQH PpWKRGH 9,6
Le développement d'un modèle de simulation selon l'approche traditionnelle diffère
totalement de l'approche adoptée avec un système V.I.S. . Un système de simulation
classique auquel on adjoint des interfaces graphiques que ce soit sous forme de
préprocesseur pour la génération automatique du modèle de simulation, et/ou sous forme
de module dédié à l'animation graphique de la simulation ne peut en aucun cas être
assimilé à un système V.I.S. La différence vient du fait que dans un système V.I.S., la
simulation, l'animation graphique et l'interaction avec le système forment un environnement
intégré où chaque aspect a une importance dans le processus de développement et de
mise au point du modèle de simulation. C'est ainsi que le cycle de vie traditionnel d'un
modèle de simulation n'est plus adapté pour décrire un modèle de type V.I.S.
L'approche traditionnelle est héritée des langages classiques de programmation. Pour
développer et mettre au point un modèle de simulation, l'utilisateur devait souvent répéter
plusieurs fois les mêmes étapes (saisie du modèle, compilation, édition de lien, exécution).
La méthode V.I.S. peut être considérée comme une méthode de programmation
graphique des modèles de simulation. En effet, le modèle de simulation est construit grâce
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
à des concepts graphiques que l'utilisateur manipule à l'écran sans avoir à écrire de code.
Cette approche a surtout été jugée très avantageuse dans la modélisation des systèmes
complexes. Néanmoins la classe des systèmes auxquels elle est le plus adaptée est celle
des réseaux de files d'attente. Un réseau de files d'attente peut être vu comme un
ensemble de noeuds connectés entre eux par des liens (arcs) orientés. Les liens sont
traversés par des transactions (entités) qui subissent des opérations exécutées par les
noeuds (ressources). Les réseaux de files d'attente possèdent des caractéristiques
graphiques qui les rendent facilement représentables à l'écran.
z
L'interconnexion (la topologie) des noeuds est facile à représenter sur un
écran
z Le flux des transactions (entités) dans le réseau peut être visualisé au fur et à
mesure du déroulement de la simulation;
z
L'évolution des statistiques peut être visualisée sous forme graphique ou
numérique au cours de la simulation ou en fin de simulation.
La liste des systèmes qu'on peut modéliser à l'aide de ces concepts est très vaste. Les
systèmes de production constituent un domaine d'application des plus récents. Ce sont
ces derniers qui ont servi comme support à la majorité des systèmes V.I.S. développés à
ce jour. La démarche à suivre pour la construction d'un modèle V.I.S. peut être dégagée à
partir d'une liste de recommandations proposées par certains auteurs et qui sont à l'heure
actuelle communément admises malgré qu'elles ne soient pas le résultat d'une recherche
expérimentale sur le sujet. Ces recommandations ont pour rôle d'assurer une meilleure
pratique de la méthode V.I.S. et peuvent être résumées comme suit:
L'utflisateur final du modèle (ex : client de l'étude) devra avoir l'opportunité d'aider à la
construction du schéma d'animation ainsi que les interactions désirées et ce avant que le
modèle de simulation ne soit entièrement fonctionnel. Ceci permettra de couvrir au départ
tous les besoins de l'utilisateur et d'éviter par la suite une remise en cause du modèle.
Le dessin est un support très utile pour la vérification du modèle par le développeur,
ainsi que pour sa validation par l'utilisateur auquel il est destiné. De ce fait un modèle
valide sera obtenu très tôt si l'aspect visuel est développé avant le développement du
modèle de simulation. Il est donc suggéré de construire le schéma d'animation
antérieurement à l'aspect logique et mathématique du modèle.
Il est difficile et souvent impossible de prédire à l'avance tous les types d'interactions
désirées par l'utilisateur et ce aussi bien par le développeur du modèle que par l'utilisateur
lui-même. Pour cela la conception de l'interface avec le modèle V.I.S. doit être aussi
générale que possible.
Des efforts doivent être faits afin de rendre possible une réutilisation partielle ou totale
d'un modèle développé pour une application donnée, dans une autre application de même
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
type. Pour cela l'utilisation de modèles génériques (paramétrables en fonction des besoins
de l'application) est une solution à explorer. Une conception modulaire du modèle V.I.S.
est aussi une démarche a priviliégier car elle permet la réutilisation partielle du modèle (un
ou plusieurs modules) dans d'autrès applications.
Contrairement à l'approche classique, le cycle de développement d'un modèle V.I.S.
n'est pas figé et dépend étroitement du système utilisé. Cependant, à partir des
recommandations précédentes, on peut énumérer les principales étapes de
développement qui doivent exister quelque soit le système V.I.S. utilisé :
z Construction de l'aspect visuel du modèle en utilisant les fonctions offertes par
le système V.I.S. (menus, éditeur graphique, etc...
z Spécification des paramètrès du
modèle (par exemple à travers une série de
questions-réponses guidée par le système)
z Exécution du modèle de simulation
z Mise au point et vérification du modèle
par interactions avec le système en
utilisant comme support l'animation graphique;
z
Validation du modèle en effectuant des exécutions sur des périodes plus
longues. La phase de mise au point peut être reprise si les résultats ne sont
pas satisfaisants.
Il faut remarquer que dans le processus de développement d'un modèle V.I.S., c'est
l'utilisateur qui décide en fonction de l'évolution de la simulation et de ce qu'il voit à l'écran,
d'entreprendre l'action qu'il juge adéquate (modifier des paramètrès du modèle, faire éditer
des résultats numériques, etc ... pour progresser vers une solution finale.
L'avantage avec la méthode V.I.S. est la réduction des efforts de conceptualisation dans
le processus de modélisation. Dans l'approche classique il existe tout un processus
d'abstraction entre le passage du modèle conceptuel à sa spécification, alors que ceci
devient transparent avec la méthode V.I.S. puisque l'utilisateur manipule directement des
objets graphiques ayant un rapport direct avec le système réel. Le modèle de simulation
n'est donc plus une " boîte noire " et ceci contribue à augmenter sa crédibilité auprès de
l'utilisateur. Ce dernier prend une part active dans tout le processus de développement du
modèle ce qui a pour avantage d'accroitre sa confiance dans les résultats. Enfin, avec un
système V.I.S. il devient même possible de faire exécuter plusieurs modèles en parallèle
sur un même écran et comparer ainsi leurs évolutions.
&RQFOXVLRQ
Aujourd'hui, le nombre d'outils dédiés a la simulation des systèmes proposés sur le
marché se compte par centaine. Ils offrent chaque jour dans leur dernieres versions de
plus en plus de fonctionnalités. Un support comme l'animation graphique des resultats
d'une simulation est pratiquement disponible dans chaque logiciel (ou une de ses
versions). La concurrence se situe essentiellement au niveau de l'adjonction de nouvelles
possibilités en vue soit d'elargir le champs d'utilisation des outils (diversifier les domaines
d'applications) ou augmenter la convivialité du produit).
Les courants technologiques actuels sont en faveur d'une mutation des applications sur
le Web, ce qui devrait inciter les societes de developpement du logiciel de simulation a
revoir leur strategie de developpement et de diffusion. Nombreux sont les travaux qui se
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
focalisent sur les possibilité d'utiliser le Web comme support pour les environnements de
simulation. Des exemples de solution proposées dans ce sens sont : la diffusion des
modèles de simulation sous forme d'applets accessibles a partir d'un naviagateur et ecrits
dans un langage de simulation basé sur Java(SimJava, Silk, etc.) ; le développement
d'environnement autour d'un langage de simulation classique (ex GPSS ou SIMAN)
résidant sur un serveur et accessible depuis un navigateur par le biais de formulaires HTML
utilisés du coté utilisateur pour soumettre un modèle de simulation et/ou ses parametrès ,
et du coté serveur pour délivrer les résultats d'une simulation quelle que soit leur forme.
Cette approche se base principalement sur l'architecture Client/Serveur du Web et la
technique des scripts CGI (Common Gateway Interface).
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
1
PRESENTATION DU LANGAGE SIMAN
1 PHILOSOPHIE GENERALE DU LANGAGE
SIMAN est largement inspiré de SLAMII du fait que son auteur C.D. PEDGEN
fût un des membres de l'équipe ayant développé SLAM. La première caractéristique
de SIMAN est qu'il sépare entre modèle et cadre d'expérimentation (Experimental
Frame). Ceci offre l'avantage de pouvoir simuler un même modèle avec différents
cadres d'expérimention.
Les approches de modélisation proposée par SIMAN sont l'approche par
Interaction de processus et l'approche par événements. Ainsi , un modèle de
simulation à événements discrets peut être modélisé selon l'une ou l'autre de ces
deux approches ou une combinaison des deux.
SIMAN permet aussi de modéliser des systèmes 'continus' en adoptant la
même approche que SLAM c'est à dire grâce à un ensemble d'équations
différentielles ou d'équations aux différences. Ainsi, il devient possible comme dans
SLAM de modéliser aussi des systèmes combinés 'DISCRET-CONTINUS'.
2. MODELISATION DES SYSTEMES A EVENEMENTS DISCRETS
La première approche pour modéliser de tels systèmes est l'approche par
'processus' avec laquelle un modèle est construit sous forme d'un diagramme à
blocs dans lequel chaque bloc permet de modéliser une opération particulière du
système modélisé. Chaque bloc est représenté graphiquement par un symbole et
correspond à primitive ou macro-instruction du langage (Création d'entités, File
d'attente, etc.).
La construction d'un réseau SLAM est orientée de gauche vers la droite , avec
possibilité de mettre des flèches (activités) entre deux noeuds quelconques sans
aucune contrainte. Avec SIMAN, un diagramme est construit de manière
descendante (du haut vers le bas) sans possibilité de des liens directs entre deux
blocs (flèches). Ainsi, un diagramme prend l'allure d'un organigramme.
Un diagramme à blocs peut être construit manuellement puis traduit en un
programme équivalent (suite de macro-instruction). Certaines versions de SIMAN
proposent un utilitaire BLOCKS qui permet de construire interactivement un
diagramme à blocs en manipulant directement les symboles graphiques
correspondant aux blocs. Le programme équivalent au diagramme ainsi construit
sera généré automatiquement par l'utilitaire BLOCKS.
La deuxième approche pour modéliser un système à événements discrets est
l'approche par événements. Le programmeur doit dans ce cas écrire un ensemble
de routines (Subroutines Fortran) dont chacune est chargée de traiter les
changements d'états correspondant à l'occurrence d'un événement. Cette approche
peut être utilisée pour construire totalement un modèle ou bien exploitée à partir d'
un digramme à blocs en vue d'augmenter ce diagramme par des fonctionnalités
spécifiques au système modélisé et qui ne sont pas supportés par les blocs
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
2
disponibles ou remplacer les fonctionnalités de certains blocs par d'autres plus
spécifiques.
En général, l'écriture de routines de traitement des événements fait appel à un
ensemble de sous-programmes offert par SIMAN sous forme d'une librairie de sousprogrammes. Ces sous-programmes permettent de réaliser des opérations de bas
niveau (insertion d'une entité dans une file, recherche d'entités ayant un attribut
particulier, etc.)
3. ARCHITECTURE FONCTIONNEL DE SIMAN
SIMAN offre trois fonctions distinctes :
• Fonction de construction d'un modèle
• Fonction de construction d'un cadre d'expérimentation
• Fonction d'analyse des résultats
Toutes ces fonctions sont mises en oeuvre par le biais de modules individuels
qui communiquent ou interagissent entre eux par le biais de fichiers de données. Il
existe cinq modules (appelés processeur dans la terminologie SIMAN) qui sont :
1. Le processeur de construction d'un modèle sous forme de
diagramme à blocs (BLOCKS). Le résultat généré est un fichier
appelé 'Fichier Modèle' et correspond à ce qu'on est habitué à
appeler un modèle de simulation.
2. Le processeur de construction d'un cadre d'expérimentation pour
un modèle. (EXPRMT). Le résultat généré est un fichier appelé
'Fichier d'expérience : Experiment File'.
3. L'éditeur de liens (LINKER) chargé de lier le modèle et le cadre
d'expérimentation pour produire un programme appelé 'Fichier
Programme : Program File'.
4. Le simulateur proprement dit (SIMAN) chargé d’exécuter le
programme et produire des résultats dans un fichier appelé
'Fichier des Sorties : Output File'.
5. Le processeur de traitement des sorties ou résultat (OUTPUT)
chargé d'analyser , de formatter et d'éditer les résultats contenus
dans le fichier des sorties.
REMARQUES :
Dans le cas de l'utilisation de l'approche par événements, les routines écrites
par le programmeur devront être compilées, puis une phase d'éditions de liens
(LINK) permettra de les lier avec un module objet SIMAN.OBJ (fournie avec le
logiciel et est en quelque sorte une version ouverte du SIMAN) produisant
ainsi un exécutable SIMAN.EXE qui constituera le processeur décrit dans le
point 4 plus haut. C'est donc cette nouvelle version de SIMAN.EXE qui
constitue le simulateur. Ce travail doit être fait avant d’exécuter le programme
de simulation obtenu en 3.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
3
Construction du Modèle
BLOCKS ou Editeur de Texte
MODEL
1
Fichier
Modèle
4
2
LINK
Fichier
Programme
Fichier
Experiment
SIMAN
Exécution
Rapport
Standard
Fichier
Résultats
3
EXPERIMENT
Construction du Cadre
d’Expérimentation
(Editeur de Texte)
OUTPUT
Analyse,..
5
Rapports
4 Entités - Attributs et Variables dans SIMAN
4.1 Entités
Dans le cas des modèles de simulation à événements discrets, la terminologie utilisée
dans SIMAN pour désigner les objets du modèle est la suivante :
•Les objets qui s’engagent dans des activités ou subissent des services sont
appelés des entités (ex : pièce , client, etc.)
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
4
•Les objets qui éxécutent des opérations ou services sont appelés des
ressources (ex: machine, opérateur, etc.)
4.2 Attributs et Variables
A tout moment, l’état du système est défini par les valeurs prises par des variables et
des attributs. Les variables représentent des caractéristiques globales du système et ne
sont donc pas liées à une entité spécfique. Par exemple : le nombre d’entités dans une
file d’attente , l’état d’une ressource seront des variables.
Contrairement aux variables, les attributs représentent des caractéristiques d’une entité
spécifique. Par exemple : le numéro d’une pièce ou le temps d’arrivée d’une pièce dans
le système peuvent constituer des attributs de la pièce.
4.2.1 Attributs
Dans SIMAN, les attributs d’une entité sont conservés dans un tableau à une dimension
ou vecteur appelé A(.). Les éléments de ce tableau sont initialisés par l’utilisateur qui peut
leur affecter des valeurs en fonction de son application. Le nombre maximum d’attributs à
associer à une entité est aussi fonction de l’applicationa est doit être spécifié dans le cadre
d’expérimentation (instruction DISCRETE). Dans l’exemple de la banque, une manière
d’utiliser les attributs serait : utiliser l’attribut A(1) pour stocker le temps d’arrivée d’un client
dans le système, l’attribut A(2) pour stocker la durée de service du client et l’attribut A(3)
pour stocker le numéro du client. Chaque entité possèdera ses propres valeurs qu’elle
transportera en parcourant le système et qui peuvent servir pour contrôler le routage de
l’entité dans le système, la durée d’un service, etc.
En plus du tableau A(.), chaque entité possède une attribut noté M désignant le numéro
de la station courante ou actuelle ou se trouve l’entité. Il représente donc une localisation
physique dans le système telle que une station d’usinage ou une zone de stockage. Cet
attribut est surtout utilisé par les fonctions de transport d’entités (pièces) entre stations. Ce
numéro est automatiquement mis à jour lors des opérations de transfert d’entités via le
système de tranport ou de manutention (convoyeur, transporteur) vers un bloc STATION. Il
est aussi possible d’affecter explicitement une valeur à M correspondant au numéro de la
station à laquelle est arrivée l’entité et ce en utilisant un bloc ASSIGN. L’attribut M peut
aussi être utilisé comme indice pour accéder aux éléments du tableau A(.) , à ceux des
variables globales(X(.), ...), à ceux des ressources définies comme un tableau, etc.
4.2.2 Variables
Les variabales globales accessibles à l’utilisateur sont :
• Un tableau X(.)
• Le tableau S(.)
• Le tableau D(.)
• La variable de type indice J
• La liste des paramètres P
La variable J permet de réaliser un adressage indirect des tableaux. L’indice d’un
élement d’un tableau est de la forme K , J±K , M±K ou K est un entier. Par exemple les
écritures : X(3), X(M), X(J), X(J+2), X(J-10) , X(M+6) et X(M-1) sont toutes valides et
permettent d’avoir accés à un élément du tableau de variables X(.).
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
5
Pour montrer l’utilisation de la variable J considérons l’exemple d’un un atelier dans
lequel des pièces doivent subir des séquences d’opérations sur 4 machines. Afin de
contrôler le routage des pièces dans l’atelier, on peut affecter aux attributs A(1), A(2), A(3)
et A(4) les numéros des machines en fonction de la séquence des opérations que devra
subir une pièce sur ces machines. Afin de connaître à tout moement le numéro de la
machine sur laquelle est en train de passer une pièce, on peut utiliser l’attribut A(5).
Initialement A(5) serait égal à 1 et l’attribut A(1) désigne le numéro de la machine
éxécutant la première opération. Chaque fois qu’une pièce termine l’opération sur une
machine, on incrémente A(5). On pourra alors connaître le numéro de la machine courante
en affectant à J la valeur de A(5) (J=A(5)) , puis en accédant au numéro de la machine
(pouvant être dans A(1), A(2), A(3)ou A(4) ) grâce à l’écriture A(J).
4.2.3 Liste des Attributs et Variables
ATTRIBUTS
A(I)
M
Variables
Utilisateurs
X(I)
S(I)
D(I)
J
P(IP,IS)
Variables
Système
TNOW
NE(I)
NQ(I)
NC(I)
NR(I)
NT(I)
LC(I)
MR(I)
MT(I)
Description
Attribut Numéro I de l’entité active
Attribut de l’entité représentant son numéro de la STATION actuelle
Description
(*)
Toutes ces variables doivent être initialisées par l’utilisateur
Variabale globale I
Variable d’état I (Pour modèles continus)
Dérivée de la Variable d’état I (Pour modèles continus)
Variable entière de type Indice
Valeur du paramètre numéro IP dans l’ensemble des Paramètres
numéro IS
Description
(*)
Toutes ces variables peuvent être utilisées mais sont mises à jour par SIMAN
Temps courant de la simulation
Nombre d’entités en route vers la Station I
Nombre d’entités dans la file d’attente I
Valeur courante du compteur I
Nombre d’unités occupées de la Ressource numéro I
Nombre d’unités occupées du Transporteur I
Longueur des cellules occupées du Convoyeur I
Nombre d’unités de la ressource I
Nombre d’unités du transporteur I
5. BLOCS COMPOSANT UN DIGRAMME
Un diagramme à blocs permet de décrire le mouvement des entités circulant
dans le système. Chaque bloc est représenté par un symbole graphique dont la
forme indique sa fonction. Le cheminement dans le diagramme est établit au
moyen de flèches reliant les blocs entre eux. Les flèches permettent donc de
contrôler le cheminement des entités d'un bloc à l'autre et ce à travers tout le
diagramme.
Comme dans tout modèle à événements discrets, une entité représente un
objet concret ou abstrait circulant dans le système. ça peut être une pièce dans un
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
6
atelier, un client dans une banque, un message dans un réseau de communication,
etc. De même que chaque entité peut posséder des attributs auxquels on peut
assigner (ou affecter) des valeurs dans le but de la distinguer des autres entités ou
de mémoriser certaines informations qui lui sont propres (Temps d'arrivée, durée
de service, etc.). Au fur et à mesure que l'entité circule dans le système, elle peut
être retardée, détruite, combiner avec d'autres pour ne former qu'une seule entité,
etc., ceci dépendant des blocs qu'elles traverse.
SIMAN propose 10 blocs de base distincts , chacun possédant son propre
symbole graphique , un nom propre et une fonction propre aussi. Ceci est le cas
pour les blocs : QUEUE , STATION , BRANCH , PICKQ , QPICK , SELECT et
MATCH.
Cependant certains blocs réalise non pas une seule fonction mais une série de
fonctions différentes. C'est le cas des blocs OPERATION , HOLD et TRANSFERT. Le
choix du type de fonction qu'on souhaite réaliser par l'un de ces blocs, devra donc
être spécifié comme paramètre du bloc. Pour cela, le premier paramètre du bloc
sert justement pour renseigner sur le type de la fonction à réaliser.
Il est courant de désigner l'un des blocs précédents non pas par son nom
mais par le type de fonction souhaitée. Par exemple, le bloc OPERATION permet
entre autres de retarder une entité pendant une certaine durée. Le paramètre
spécifiant qu'on désire retarder une entité sera DELAY. Dans ce cas il est courant
de désigner ce bloc par le bloc DELAY bien que DELAY n'est pas un nom de bloc.
EX :
Type de Fonction
DALAY
Durée du Retard
UNIFORM(2,1)
Bloc OPERATION
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
NOM
OPERATION
TRANSFERT
HOLD
SYMBOLE
FONCTION
Ce bloc permet de modéliser une
grande variété de fonctionnalités qui
peuvent être :
- Générales : assignation de valeurs
aux attributs, créations d'entités,
retarder une entité pendant une
durée déterminée, appel de sousprogramme écrits par l'utilisateur,
etc..
- Associées aux ressources :
changement
de
capacité
d'une
ressource
- relatives à la manutention :
activation, libération d'un convoyeur
ou un chariot
- relatives aux statistiques :
spécifier les observations à collecter
sur le système.
Ce bloc permet de modéliser le
transfert d'entités entre les stations
par un moyen de manutention.
Ce bloc permet de modéliser toute
situation dans laquelle le mouvement
d'une entité doit être retardé. Le
retard peut être dû à :
- Attente d'un signal ou la
satisfaction d'une condition
- Libération d'une ressource ou
d'un dispositif de manutention
(Chariot, ...)
- Regroupement d'un nombre
déterminé d'entités dans la file
d'attente qui précède le bloc HOLD
7
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
NOM
QUEUE
STATION
SYMBOLE
FONCTION
Ce bloc permet de modéliser une file
d'attente dans laquelle les entités
mises en attente à un bloc HOLD ou
MATCH seront conservées.
Ce bloc permet de créer une interface
entre les composants du modèle et le
système
de
transport
ou
de
manutention.
Cette possibilité n'existe pas dans
SLAM.
BRANCH
Ce bloc permet de faire un routage
selon une condition, une probabilité
ou déterministe.
Une branche matérialise don le
chemin que doit emprunter une entité.
8
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
NOM
SYMBOLE
FONCTION
Ce bloc permet de sélectionner une
file d'attente parmi un ensemble de
files qui le suivent (BLOCS QUEUE) en
vue de diriger une entité vers la file
choisie.
PICKQ
Ce bloc permet de sélectionner une
ressource parmi plusieurs associées à
des blocs OPERATION.
SELECT
QPICK
MATCH
Il y a une analogie avec une des
fonctions du noeud SELECT de SLAM.
T
T
T
T
Ce bloc permet de sélectionner des
entités dans un ensemble de files
d'attente (blocs QUEUE) qui le
précèdent. La sélection se fait selon un
critère que l'on doit spécifier.
Il y a une analogie avec une des
fonctions du noeud SELECT de SLAM.
Ce bloc permet de retenir des entités
dans les files d’attente qui le précédent
jusqu’à ce qu’il y ait des entités qui
possèdent la même valeur d’un
attribut dans chacune des file
d’attente. Il est analogue au noeud
MATCH de SLAM.
9
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
10
5.2 Fonctions offertes par les blocs OPERATION, HOLD et
TRANSFERT
Une caractéristique commune à tous les blocs offert par le langage SIMAN
(sans distinction aucune) est que chaque bloc possède des opérandes qui
contrôlent la fonction réalisée par le bloc. Par exemple le bloc DELAY a comme
opérande la durée, le bloc création d'entités (CREATE) a comme opérandes : le
temps séparant les créations, le nombre d'entités à créer à chaque fois et le nombre
maximum d'entités à créer.
Nous allons énumérer la liste des fonctions permises par chacun des 3 blocs
particuliers OPERATION , HOLD et TRANSFERT
5.2.1 Fonctions offertes par le bloc OPERATION
Nom
Description
ASSIGN
Affecter des valeurs aux attributs
CREATE
Créer des entités
DELAY
Retarder une entités pendant une durée
DETECT
Détecter les événements de changement
d'état pour le cas de systèmes continus
FONCTIONS
EVENT
Déclencher un événement spécifié
GENERALES
FINDJ
Rechercher la valeur de l'index
satisfaisant une certaine condition
J
SIGNAL
Envoyer un signal pour terminer le retard
dans lequel s'est engagé une entité (par un
DELAY).
SPLIT
Décomposer un groupe (d'entités) en
éléments individuels
COUNT
Incrémenter un compteur spécifié
Fonctions
Statistiques
TALLY
Prélever (collecter) une observation sur
une valeur spécifiée
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Nom
ASSIGN
Description
Affecter des valeurs aux attributs
ACTIVATE Mettre l'état d'un transporteur spécifié à
ACTIF
EXIT
QUITTER un CONVOYEUR spécifié
FONCTIONS
FREE
QUITTER un TRANSPORTEUR spécifié
HALT
Mettre l'état d'un
spécifié à INACTIF
pour
SYSTEME DE
TRANSPORTEUR
MANUTENTION
START
Mettre l'état d'un CONVOYEUR spécifié à
ACTIF
STOP
Mettre l'état d'un CONVOYEUR spécifié à
INACTIF
SPLIT
Décomposer un groupe (d'entités) en
éléments individuels
Changer la capacité d'une ressource
Fonctions
ALTER
Ressources
RELEASE
Libérer un nombre spécifié d'unités d'une
ressource
COPY
Copier les attributs d'une entité dans une
file d'attente spécifiée
SEARCH
Chercher une file d'attente pour une
entité satisfaisant une condition spécifiée
REMOVE
Supprimer une entité d'une file d'attente
spécifiée
Fonctions
pour
Files d'Attente
11
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
5.2.2 Fonctions offertes par le bloc HOLD
Nom
SCAN
Retarder l'entité jusqu'à ce
condition spécifiée soit satisfaite.
WAIT
Retarder l'entité jusqu'à ce qu'un signal
soit reçu depuis un bloc SIGNAL.
SCAN
Retarder l'entité jusqu'à ce
condition spécifiée soit satisfaite.
WAIT
Retarder l'entité jusqu'à ce qu'un signal
soit reçu depuis un bloc SIGNAL.
ACCESS
Retarder l'entité jusqu'à ce que le nombre
requis de cellules du convoyeur soit
disponible et alloué à l'entité.
REQUEST
Retarder l'entité jusqu'à ce que 1
TRANSPORTEUR soit alloué à l'entité et
arrive à la station ou se trouve l'entité.
COMBINE
Retarder l'entité jusqu'à ce qu'un nombre
spécifié d'entité soit présent dans la file
d'attente qui précède. Une fois présentes,
ces entités sont combinés en un ensemble
solidaire et une entité représentant cet
ensemble ou SET est créée. Les entités
originales sont détruites du SET.
GROUP
Retarder l'entité jusqu'à ce qu'un nombre
spécifié d'entité soit présent dans la file
d'attente qui précède (Bloc QUEUE). Une
fois présentes, ces entités sont combinés
en un ensemble solidaire mais temporaire
et une entité représentant cet ensemble
ou SET est créée. Les entités originales ne
sont pas détruites et peuvent être
reproduites grâce au bloc SPLIT.
Fonctions
Conditionnelles
Fonctions
Conditionnelles
Description
Fonctions
qu'une
qu'une
de
Manutention
Fonctions
pour
Ensemble
ou
Groupe
12
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
13
5.2.3 Fonctions offertes par le bloc TRANSFERT
FONCTIONS
Nom
Description
CONVEY
Transporter une entité à l'aide d'un
convoyeur vers une station précise. Le
temps de convoyage est déterminé par la
distance entre les stations et la vitesse du
convoyeur.
ROUTE
Router une entité vers une station précise.
Le temps de routage est spécifié comme
opérande
DE
MANUTENTION
TRANSPORT Transporter
une entité à l'aide d'un
TRANSPORTEUR vers une station précise.
Le temps de transport est proportionnel à
la distance entre les stations.
6. METHODES DE CONSTRUCTION D'UN MODELE A L'AIDE D'UN
DIAGRAMME
Un modèle de simulation à événements discrets peut être construit selon deux
modes :
z En mode interactif grâce à un utilitaire
z En mode BATCH c.a.d. Manuel grâce à un Editeur de Texte
6.1 MODE INTERACTIF
Cette méthode nécessite l'utilisation d'un utilitaire spéciale appelé BLOCKS
qui fait fonction d'éditeur interactif de diagrammes. Son avantage pratique c'est
qu'il facilite la tâche de l'utilisateur car il génère automatiquement à partir d'un
diagramme construit à l'écran , le modèle programmé (ou Modèle opérationnel ou
suite de macro-Instructions) correspondant.
Pour construire un diagramme, les étapes à faire sont :
1-
Sélectionne un bloc devant composer le diagramme dans un menu
contenu la liste des blocs offerts par SIMAN
2-
L'ajouter au diagramme
3-
Fournir les paramètres éventuels du bloc
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
14
L'ajout d'un bloc à la suite des autres blocs déjà existants se fait
automatiquement par BLOCKS. Ceci est du au fait que la structure d'un
diagramme est hiérarchique et orientée de haut en bas. Ainsi, au fur et à mesure
qu'un bloc est rajouté, il se peut que le partie du diagramme déjà saisie occupe la
totalité de la fenêtre d'édition. Dans ce cas, BLOCKS, effectue un scrolling vers le
haut de l'écran afin d'ajouter le nouveau bloc à la suite des autres.
On peut associer à un bloc un identificateur (8 Caractères). Ce dernier peut
servir par exemple pour faire des branchements vers ce bloc à partir d'un autre
bloc, ou pour référencer ce bloc dans un autre bloc.
Au fur et à mesure de l'ajout des blocs, BLOCKS affecte à chacun un numéro
de séquence qui sera affiché à gauche du bloc. Ce numéro peut par exemple être
utilisé pour éditer un bloc individuellement dans le cas où on veut faire des
modifications sur ce bloc.
Les blocs sont connectés entre grâce à deux symboles (appelés CONNECTORS
dans SIMAN) qui sont :
1
↓:
2.
flèche orienté vers le bas qui est utilisée pour indiquer qu'on passe (les
entités qui circulent !) d'un bloc vers le suivant séquentiellement
LABEL
qui permet d’indiquer que les entités seront
dirigées vers le bloc dont le LABEL est indiqué
et non pas séquentiellement.
Dans le cas ou aucun connecteur n'est rattaché à un bloc, un symbole (ou
connecteur ) spécial est rajouté automatiquement. Ce symbole est : ⊥ et indique
que les entités qui sortiront du bloc auquel a été ajouter ce symbole seront
détruites.
Cependant, il faut souligner que l'ajout de connecteurs à un bloc ne
s'applique pas au bloc TRANSFERT c'est à dire qu'on ne doit pas rajouter de
connecteur à ce type de bloc. En effet, les fonctions du bloc TRANSFERT sont par
définition des fonctions de routage d'entités vers une destination précise
(STATION). Cette dernière sera donc nécessairement un paramètre du bloc même et
c'est pour cela que l'ajout d'un connecteur n'est vraiment pas utile puisqu'on sait
déjà où va l'entité.
En plus des connecteurs, on peut ajouter à un bloc un symbole de marquage
(appelé MARK symbol dans SIMAN) qui a l'allure suivante :
A
Ce symbole permet de mémoriser le temps d'arrivée de l'entité au bloc dans
un attribut spécifique (ici A par exemple) de cette entité.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
15
6.2 MODE BATCH
Dans ce mode la construction d'un modèle 'équivalent d'un diagramme à
blocs', est d'utiliser un éditeur de texte quelconque et de saisir manuellement la
suite de macro-instructions correspondant chacune à un bloc.
Pour faire ce travail, on doit normalement dessiner sur papier le diagramme
puis passer à l'étape de traduction manuelle du diagramme. Pour cela on doit
nécessairement connaître la syntaxe et la structure des macro-instructions.
Une macro-instruction ou plus simplement une primitive du langage SIMAN
est structurée en 5 champs :
Label du Bloc
Nom du Bloc
Opérandes
Marque
Connecteur
& Commentaires ;
Le label du bloc tient sur 8 caractères au maximum et commence donc à la
colonne 1.
Le Nom du bloc commence à partir de la colonne 10 ou même après (ce qui
laisse au moins un blanc entre le label et le nom du bloc) et est séparé du champ
suivant par le caractère ' : '
Les opérandes sont spécifiques à chaque bloc. On les introduits après les
deux points terminant le nom du bloc et ils peuvent s’étaler sur plusieurs lignes.
La fin de la liste des opérandes est aussi indiquée par le caractère ' : '
Les marques et connecteurs appelés dans SIMAN des 'Modifiers' sont
introduits après la lise des opérandes (après le :) et sont séparés entre eux par une
virgule ','. Il existe en fait 3 type de Modifieurs :
z
z
z
DISPOSE : mot clé qui indique que les entités sortant du bloc
sont détruites
MARK(A) : mot clé qui indique que le temps d'arrivée de l'entité
au bloc doit être mémorisé dans l'attribut A de cette entité
NEXT(QUEUE5) : mot clé qui indique que les entités sortant
du bloc doivent être routées vers le bloc ayant pour étiquette ou
Label : QUEUE5
REMARQUE : Dans le cas ou les modifieurs DISPOSE et NEXT sont omis, les
entités poursuivent un chemin séquentiel c'est à dire elles passe
au bloc suivant (la macro-instruction suivante).
La fin de la macro-instruction effective est indiquée par le caractère point
virgule ( ; ) qui sera donc placé juste après le dernier modifieur.
Le commentaire associé à la macro-instruction sera placé après le point
virgule marquant la fin effective de celle-ci.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
16
7 EXEMPLE DE MODELE
7.1 Description du Système à Modéliser
Le système à modéliser consiste à contrôler des pièces. Si une pièce est jugée
non conforme , elle doit passer sur une autre machine pour subir un ajustement
ou rectification. Après avoir subie cette opération, elle doit à nouveau passer au
contrôle. Les pièces qui sont jugées bonnes après contrôle (qu'elles aient subit un
ou plusieurs ajustement ou pas du tout) quittent le système.
On suppose que suite à des observations effectuées sur le système, on a
estimé que 15% des pièces contrôlées sont bonnes et le reste (85%) subit au moins
une fois un ajustement. On suppose aussi les durées des opérations de contrôle et
celle de rectification suivent des lois uniformes. De même que le temps séparant la
création des entités suit une loi uniforme. Nous préciserons le sens des paramètres
de ces lois (UN(1,1) , UN(2,1) et UN(3,1) plus loin.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
Diagramme
CREATE
Explications
Création des pièces et Marquage
du temps d’arrivée dans l’attribut 1
1
UN(1,1)
Attendre la machine de contrôle
dans la file 1
1
CONTROLE
Passer sur la machine de contrôle
SEIZE
Rester sur la machine de contrôle
pendant une durée égale au temps
de service : généré à partir d’une
distribution uniforme.
MACHINE1
DELAY
UN(2,1)
Libérer la machine de contrôle
Selon le résultat du contrôle se
brancher avec une probabilité de
0.15
vers
la
machine
de
rectification et avec une probabilité
de 0.85 vers la sortie.
RELEASE
MACHINE1
1
MACHINE2
WITH, .15
WITH, .85
RECTIFIE
QUITTER
2
SEIZE
Attendre
la
machine
rectification dans la file 2
de
Passer sur
rectification
de
la
machine
Rester sur la machine de
rectification pendant une durée
égale au temps de rectification
(généré à partir d’une distribution
uniforme)
MACHINE2
DELAY
UN(3,1)
Libérer la machine de rectification
et Retourner à la machine de
contrôle
RELEASE
MACHINE2
MACHINE1
⊥
QUITTER
TALLY
Collecter des statistiques sur le
temps passé par les entités dans le
système.
1, INT(1)
Remarque : Beaucoup de paramètres de ce modèle seront spécifiés dans le cadre
d’expérimentation associé au modèle. Ce sera notamment le cas pour les
paramètres des distributions utilisées (Uniforme).
17
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
18
7.2 Programme SIMAN correspondant au diagramme
BEGIN;
CONTROLE
RECTIFIE
QUITTER
Arrivée des pièces
CREATE : UN( 1,1) : MARK(1) ;
Attente Machine1
QUEUE ,1;
SEIZE : MACHINE1;Acquérir Machine1
DELAY : UN( 2,1) ; Occuper Machine1 pendant
un temps = à la durée du contrôle
Libérer Machine1
RELEASE : MACHINE1;
ALLER Soit vers le bloc dont Label est :
BRANCH, 1 ;
RECTIFIE avec une Probabilité= 0.15
WITH , .15, RECTIFIE ;
QUITTER avec une Probabilité= 0.85
WITH , .85, QUITTER ;
Attente Machine2
QUEUE , 2;
SEIZE : MACHINE1;Acquérir Machine2
DELAY : UN( 2,1) ; Occuper Machine2 pendant
un temps = à la durée de rectification
RELEASE : MACHINE2 :
NEXT(CONTROLE) ; Libérer Machine2 et Retour au contrôle
Collecter des statistiques sur le
TALLY : 1 , INT(1) : DISPOSE;
temps de séjour d'une pièce
dans le système et détruire les
entités qui sortent
END;
7.3 Cadre d'expérimentation pour le modèle
BEGIN;
PROJECT , CONTROLE DE PIECES , AUTEUR , 5/1/1998
DISCRETE , 30, 1, 2;
PARAMETERS : 1, 3.5 , 7.5 : 2 , 6.0 , 12 : 3, 20 , 40 ;
RESOURCES : 1 , MACHINE1 , 2 : 2 , MACHINE2 ;
TALLIES : 1 , TEMPS DE SEJOUR;
DSTAT : 1, NQ(1), FILE CONTROLE : 2 , NQ(2), FILE RECTIFIE :
3, NR(1), UTILIZ M1 : 4 NR(2), UTILIZ M2 ;
TRACE;
REPLICATE, 1 , 0 , 100;
END;
7.4 Discussion
Comme on peut le remarquer, le cadre d'expérimentation permet de définir
toutes les paramètre du modèle et de la simulation. Ceci inclut :
- Les valeurs des paramètres des distributions de variables aléatoires
grâce à l'instruction PARAMETERS
- Les caractéristiques des ressources (numéro, nom, capacité initiale)
grâce à l'instruction RESOURCES
- Les caractéristiques des résultats désirés grâce à des instructions
telles que : TALLIES, CSTAT, DSTAT, COUNTERS,RESOURCES
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
19
- Le nombre de simulation à faire , la durée d'une simulation , les
initialisations à faire, etc. et ce grâce à l'instruction REPLICATE
- La spécification de l'option de TRACE, qui permet d'obtenir une trace
d'exécution et ce grâce à l'instruction TRACE
REMARQUES :
Il existe encore d'autres instructions qu'on peut utiliser pour définir un cadre
d'expérimentation. Notamment celles concernant le système de manutention
(TRANSPORTEUR, CONVOYEUR, etc...). Notre objectif étant simplement de donner
une vue générale du langage, le lecteur intéressé pourra se reporter à la
documentation du langage pour plus de détails.
8 ETAPES DE MISE EN OEUVRE D'UNE SIMULATION
Avant de présenter les étapes à suivre pour mettre en oeuvre une simulation,
on doit préciser les éléments qui constituent l'architecture fonctionnelle de
l'environnement proposé par SIMAN. On a :
z BLOCKS.EXE
z MODEL.EXE
z EXMPT.EXE
z LINKER.EXE
z SIMAN.EXE
z OUTPT.EXE
: Utilitaire pour l'édition interactive de diagrammes à
blocs
: Utilitaire pour compilation d'un modèle ; produit
comme résultat un fichier
:
Utilitaire
pour
compilation
d'un
cadre
d'expérimentation ; produit comme résultat un fichier
: Utilitaire pour faire l'édition de liens entre un modèle
compilé et son cadre d'expérimentation aussi compilé ;
produit comme résultat le modèle opérationnel de
simulation (ou exécutable)
: SIMULATEUR SIMAN qui utilise comme entrée le
modèle opérationnel de simulation résultant de l'étape
d'éditions de liens , exécute ce modèle et produit en
sortie les résultats statistiques désirés.
: Utilitaire permettant d'appliquer un certain nombre
d'operations statistiques aux résultats d'une simulation.
Les étapes principales à suivre pour pouvoir réaliser une simulation et obtenir
des résultats sont donc les suivantes :
8.1 CONSTRUCTION DU MODELE
Cette étape que nous avons expliqué plus haut consiste à construire le modèle
soit selon le mode interactif soit selon le mode BATCH. Dans les deux cas, le
résultat de cette étape sera un fichier source contenant la suite de macroinstructions et qui peut être vue aussi comme un digramme à blocs. En effet
puisque dans le cas où on utilise le mode interactif, la traduction du diagramme en
un fichier source contenant une suite équivalente de macro-instruction est faite
automatiquement par l'utilitaire BLOCKS.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
20
Une fois qu'on dispose du fichier source, il faut faire appel au à l'utilitaire
MODEL qui utilise comme entrée ce fichier source et produit en sortie une forme
compilée du modèle.
Fichier Source
MODEL
Modèle Compilé
Ex : si on suppose qu'on a utilisé l'éditeur EDIT de DOS (ou sous
n'importe quel autre éditeur) pour créer le fichier source c'est à dire
saisir la suite de macro-instructions représentant notre modèle et
qu'on a enregistré ce fichier sous le nom TOTO.TXT,
La compilation de ce fichier afin d'obtenir une forme interne du
modèle qui constituera l'entrée de l'éditeur de liens, on fera :
C> SIMAN> MODEL TOTO.TXT MODTOTO
TOTO.TXT est le nom du fichier source et MODTOTO est le nom du
fichier résultat (modèle compilé). L'utilitaire MODEL rajoute
automatiquement une extension au fichier résultat MODTOTO
L'utilitaire MODEL impose que la première instruction qui doit débuter tout
modèle soit l'instruction BEGIN et la dernière instruction marquant la fin du
modèle soit l'instruction END. Ces instructions commence à partir de la colonne 1
et leur format est le suivant :
a)
BEGIN, BSEQ , ISEQ, ILIST ;
ou les paramètres ont les significations suivantes :
BSEQ :
Entier indiquant le numéro à attribuer au premier bloc du
modèle. Si le paramètre est omis, les blocs sont numérotés à partir de 10
(premier bloc aura pour N° 10)
ISEQ :
Incrément à rajouter au numéro du bloc précédent pour
obtenir le numéro du bloc courant (Ceci s'applique à tous les blocs sauf le
premier dont le numéro est indiqué par BSEQ (ou 10 par défaut). Si ISEQ
est omis l'incrément est fixé par défaut à 10.
ILIST :
paramètre égal à YES ou NO est permet de spécifier si on
souhaite obtenir un listing du résultat de la compilation (par défaut égal à
YES).
b)
END;
L'instruction END n'a pas de paramètres.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
21
8.2 Construction d'un cadre d'expérimentation
Le fichier source contenant la suite des instructions spécifiant le cadre
d'expérimentation du modèle est construit en utilisant un éditeur de texte
quelconque et en respectant la syntaxe des instructions. Le jeu d'instruction à
utiliser est totalement différent de celui des macro-instructions qu'on utilise pour
construire un modèle (ou diagramme à blocs). Le fichier
Le fichier source obtenu sera utilisé comme entrée par l'utilitaire EXMPT qui
le compile et produit en sortie un fichier contenant le cadre d'expérimentation sous
une forme compilée.
Fichier Source
EXMPT
Cadre d’expérimenta.
Compilé
Ex : si on suppose qu'on a utilisé l'éditeur EDIT de DOS (ou sous
n'importe quel autre éditeur) pour créer le fichier source contenant
les instructions définissant le cadre d'expérimentation. Si le fichier
s'appelle TITI.TXT
C> SIMAN> EXMPT TITI.TXT CADRTITI
TITI.TXT est le nom du fichier source et CADRTITI est le nom du
fichier résultat (cadre d'expérimentation compilé). L'utilitaire
EXMPT rajoute automatiquement une extension au fichier résultat
CADRTITI
8.3 Création du modèle opérationnel ou Exécutable
Les deux fichiers compilés , celui produit par l'utilitaire MODEL et celui
produit par EXMPT vont servir d'entrée à l'éditeur de liens LINKER propre à SIMAN
(à ne pas confondre avec le LINK de DOS ou de n'importe quel compilateur!) qui
produit comme résultat ce qu'on a appelle le modèle opérationnel ou exécutable.
Modèle
Compilé
LINKER
Modèle
Opérationnel
Cadre d’exp.
Compilé
Ex : L'éditions de liens des fichiers résultant des exemples précédents
donne :
C> SIMAN> LINKER MODTOTO CADRTITI EXECMOD
MODTOTO et CADRTITI sont les 2 fichiers d'entrée du LINKER.
EXECMOD est le fichier dans lequel le LINKER produira le résultat
de l'édition de liens. EXECMOD sera donc le modèle opérationnel
ou exécutable.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
22
8.4 Exécution du Modèle - Expérimentation
Le modèle exécutable obtenu à la suite de l'édition de liens est utilisé comme
entrée par le simulateur SIMAN qui l'éxécute alors et produit en sortie les résultats
statistiques voulus.
Ex : L'exécution du modèle EXECMOD se fera comme suit :
C> SIMAN> SIMAN EXECMOD
9 Eléments de construction d'un Cadre d'expérimentation
Comme nous l'avons souligné, la construction d'un cadre d'expérimentation
consiste en l'édition d'un fichier source contenant un ensemble de directives (ou
instructions ) permettant de spécifier toutes les conditions pour exécuter le modèle
de simulation.
Une directive ou instruction (appelées ELEMENT dans SIMAN) consiste en :
• un nom de l'instruction
• un ou plusieurs opérandes séparés par une virgule
• un point virgule marquant la fin de l'instruction
Certaines instructions peuvent posséder plusieurs groupes d'opérandes qui se
répètent. Ces groupes sont alors séparé par le caractère ':' et à chaque groupe est
associé un numéro (1er , 2ième , ...). Pour certaine instructions , ce numéro d'ordre
des groupes a de l'importance alors que pour d'autre non.
Un opérande peut être obligatoire ou optionnel selon le cas et l'instruction.
Dans le cas d'un opérande optionnel, lorsqu'il est omis, c'est la valeur par défaut
qui est utilisée.
9.1 Principales instructions
Nous allons présenter une liste d' instructions qui sont parmi les plus
importantes. Leur connaissance suffit amplement pour être à même de construire
un cadre d'expérimentation.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.1 Instruction PROJECT
Utilisée pour attribuer un titre (ou label) au rapport contenant les
résultats statistiques édités par SIMAN en fin de simulation.
PROJECT
FORMAT INSTRUCTION:
PROJECT , TITRE , AUTEUR , MOIS/JOUR/ANNEERE ;
OPERANDE
VALEUR DEFAUT
TYPE
Titre du projet (20 caractères MAx.)
TITRE
des Blancs
Nom de l'auteur (20 caractères MAx.)
AUTEUR
des Blancs
date
MOIS/JOUR/ANNNE
1/1/2000
EXEMPLES :
PROJECT , GESTION PRODUCTION, LISA , 1/31/1998 ;
9.2 Instruction DISCRETE
Utilisée pour définir les variables associées à un modèle à événements
discrets représenté soit par un diagramme à blocs ou par une approche de
type événements.
FORMAT INSTRUCTION:
DISCRETE
DISCRETE , MAXENT , MAXATRB , NFILES, NSTA ;
OPERANDE
MAXENT
TYPE
VALEUR DEFAUT
Nombre maximum d'entités qui peuvent
être présentes dans le système en même temps (entier)
MAXATRB
NFILES
NSTAT
Nombre maximum d'attributs associés à une
entité (entier)
Nombre de file d'attentes dans le système (entier)
Nombre de stations dans le système (entier)
0
0
0
0
EXEMPLES :
DISCRETE , 100 , 3 ;
Le nombre maximum d'entités est de 100 et chaque entité possède 3 attributs
qu'on pourra désigner dans le modèle (ou diagramme) par A(1) , A(2) et A(3).
23
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.3 Instruction TALLIES
Permet d'attribuer des identificateurs (labels ou entête) aux
statistiques collectées au cours de la simulation et qui vont apparaître sur
les résultats. Elle permet aussi de définir les unités de périphériques sur
lesquelles auront lieu les sorties.
Cette instruction est a utiliser lorsque dans le modèle (ou diagramme
à blocs) on a utilisé un bloc TALLY (ou bien lorsqu'on a fait appel à la
subroutine TALLY dans le cas d'une approche par événements).
FORMAT INSTRUCTION:
TALLIES
TALLIES : N , ID , UNITE : repeats...............;
OPERANDE
TYPE
VALEUR DEFAUT
N
Numéro du régistre (entier)
ID
Identificateur (16 caractères Max.)
des Blancs
UNITE
Numéro de l'unité périphérique sur laquelle
enregistrer les observations individuelles
(Incrémentée à chaque exécution )
Pas d'observ.
Individuelles
Néant
EXEMPLES :
TALLIES: 1 , TEMPS DE SEJOUR ;
L'identificateur du registre 1 est TEMPS DE SEJOUR. Il n' y a pas de
sauvegarde des observations individuelles (car pas de n° d'unité).
TALLIES: 1 , T. DANS FILE : 2 , T. ENTRE ARRIVEE , 11;
L'identificateur du registre 1 est T. DANS FILE . Il n' y a pas de sauvegarde des
observations individuelles pour la variable associée à ce registre (car pas de n°
d'unité). L'identificateur du registre 2 est T. ENTRE ARRIVEE. Il y a sauvegarde
des observations individuelles sur l'unité N° 11 (qui peut être associée à un fichier
sur disque ou disquette).
24
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.4 Instruction COUNTERS
Permet d'attribuer des identificateurs (labels ou entête) aux compteurs
utilisés dans les modèles à événements discrets.
Cette instruction est a utiliser lorsque dans le modèle (ou diagramme
à blocs) on a utilisé un bloc COUNT (ou bien lorsqu'on a fait appel à la
subroutine COUNT dans le cas d'une approche par événements).
FORMAT INSTRUCTION:
COUNTERS
COUNTERS : N , ID , LIMITE : repeats...............;
OPERANDE
TYPE
VALEUR DEFAUT
N
Numéro du compteur (entier)
ID
Identificateur (16 caractères Max.)
LIMITE
La valeur limite du compteur qui sert pour
stopper la simulation.
Néant
des Blancs
∞
EXEMPLES :
COUNTERS : 1 , CLIENTS SERVIS ;
L'identificateur du compteur N° 1 est CLIENTS SERVIS. La valeur limite de ce
compteur est fixée à 500. Dès que le compteur atteint (ou dépasse) cette limite,
la simulation s'arrête.
COUNTERS : 1 , PIECES ROUGES : 2 , PIECES JAUNES , 50;
L'identificateur du compteur N° 1 est PIECES ROUGES. Sa valeur limite est
infinie. L'identificateur du compteur N° 2 est PIECES JAUNES. Sa valeur limite
est fixée à 50. Dès que le compteur 2 atteint (ou dépasse) 50 , la simulation
s'arrête.
L'identificateur du registre 1 est T. DANS FILE . Il n' y a pas de sauvegarde des
observations individuelles pour la variable associée à ce registre (car pas de n°
d'unité). L'identificateur du registre 2 est T. ENTRE ARRIVEE. Il y a sauvegarde
des observations individuelles sur l'unité N° 11 (qui peut être associée à un fichier
sur disque ou disquette).
25
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.5 Instruction RESOURCES
Utilisée pour déclarer une ressource utilisée dans un diagramme à
blocs.
Les ressources peuvent être de deux types : les ressources simples et
les ressources indicées (sous forme d'un vecteur).
Dans ce qui suit, nous allons présenter uniquement le type simple.
On peut déclarer une ou plusieurs ressources dans une même
instruction RESOURCES. Dans ce cas, les paramètres associées à chaque
ressource (numéro, nom , capacité initiale) seront séparés entre eux par
une virgule et séparés des autres par ':'
FORMAT INSTRUCTION:
RESOURCES
RESOURCES : Numéro , Nom , Capacité : repeats ............ ;
OPERANDE
Numéro
Nom
Capacité
TYPE
Numéro de la ressource (entier)
Nom de la ressource (8 caractères Max.)
Nombre initial d'unités (entier)
VALEUR DEFAUT
Néant
Néant
1
EXEMPLES :
RESOURCES : 1 , SERVEUR ;
La ressource porte le numéro 1 et pour nom SERVEUR. Sa capacité initiale est
de 1 unité (valeur par défaut).
RESOURCES : 1 , FRAISEUSE , 4 : 2 , TOUR;
La ressource portant le numéro 1 a pour nom FRAISEUSE et sa capacité initiale
est de 4 unités. La ressource portant le numéro 2 a pour nom TOUR et sa
capacité initiale est de 1 unité (valeur par défaut).
La variable système (de SIMAN) NR(I) permet de connaître le nombre d'unités
occupées de la ressource portant le numéro I.
La variable système (de SIMAN) MR(J) permet de connaître le nombre d'unités
actuel (courant) de la ressource portant le numéro J.
26
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.6 Instruction REPLICATE
Permet de spécifier le nombre de simulations à réaliser, le temps de début de la
première simulation, la durée maximale de chaque exécution et les initialisations à faire
entre deux exécutions consécutives. Dans le cas ou cette instruction n'est pas utilisée, alors
une il y aura une seule exécution de la simulation dont la fin devra être contrôlée à
l'intérieur du modèle de simulation. Il existe deux types d'initialisations qu'on peut
demander :
• Initialisation du système au début de chaque exécution :
On peut initialiser ou non le système avant de commencer l'exécution d'une
nouvelle simulation (réplication) grâce à une paramètre de l'instruction qu'on positionne à
YES ou NO. Dans le cas ou on choisit l'option YES (initialiser), SIMAN remet toutes les
variables et les files d'attente à leur état initial avant de commencer la simulation. Ainsi
toutes les simulations demandées (réplications) débuteront dans les mêmes conditions. Si
par contre, l'option choisie est NO (ne pas initialiser), l'état du système n'est pas réinitialisé
entre deux exécutions consécutives. Ainsi, les conditions de terminaison de la nième
exécution serviront de conditions initiales pour l'exécution suivante.
• Ignorer les Observations collectées durant une réplication
On peut ignorer ou conserver les observations collectées au cours de l'exécution
d'une simulation en le spécifiant grâce à un paramètre de l'instruction qu'on positionne à
YES ou NO. Dans le cas ou on choisit l'option YES (Ignorer), toutes les observations
collectées dans la précédente réplication sont ignorées et ne sont pas prises en compte
pour l'exécution d'une nouvelle simulation. Ainsi, les statistiques fournies en sortie
concernent une seule réplication. Si par contre, l'option choisie est NO (Ne pas Ignorer), les
observations des différentes réplications ne sont pas ignorées et seront utilisées pour
produire les résultats statistiques. Ces résultats sont donc basés sur les observations
faites dans la dernière réplications ainsi que celles faites dans toutes les précédentes.
FORMAT INSTRUCTION:
REPLICATE
REPLICATE : NRUNS , Tdébut , TMaxRun, INITSYS, INITSTAT;
OPERANDE
NRUNS
Tdébut
TMaxRun
INITSYS
INITSTAT
EXEMPLES :
TYPE
VALEUR DEFAUT
Nombre de simulations à faire (entier)
Temps début de la première simulation (Réel)
Durée Maximale de chaque simulation (Réel)
Initialisation du système (YES ou NO)
IGNORER les Observations (YES ou NO)
1
0.0
∞
YES
YES
REPLICATE , 1 , 0 , 1000 ;
Une seule exécution qui commence au temps 0 et se termine au temps 1000.
REPLICATE , 10 , 0 , 200 , NO;
Ici on demande 10 exécutions, la première commençant au temps 0. Chaque exécution
dure au maximum 200 unités de temps et il n 'y aura pas réinitialisation du système
entre les exécutions.
27
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.7 Instruction PARAMETERS
Utilisée pour déclarer les paramètres des variables aléatoires utilisées dans le modèle. Le
nombre de paramètres n'étant pas le même pour toutes les variables aléatoires, SIMAN utilise un
numéro pour désigner un ensemble ou groupe de paramètres. Ainsi, lorsqu'on utilise dans le modèle
la distribution de la variable aléatoire, on lui passe comme argument un numéro désignant un
ensemble de paramètres déclarés dans le cadre d'expérimentation à l'aide de l'instruction
PARAMETERS.
Les distributions de probabilités offertes par SIMAN sont :
Distribution
•
•
•
•
•
•
•
•
•
•
Nom
EX
ER
UN
TR
RN
RL
GA
BE
NP
WE
Exponentielle
Erlang
Uniforme
Triangulaire
Normale
Lognormal
Gamma
Beta
Poisson
Weibull
• Distribution Empirique
DP
• Constante
CO
FORMAT INSTRUCTION:
P1
Paramètr
es
P2
P3
Moyenne
Moy. Exponentielle
Minimum
Minimum
Moyenne
Moyenne
beta
theta
Moyenne
beta
•
K
Maximum
Mode
Ecart type
Ecart type
alpha
phi
•
alpha
•
•
•
Minimum
•
•
•
•
•
•
Probabilité Cumuléé ,Valeur........
constante
•
•
PARAMETERS
PARAMETERS : N,P, ....P : repeats...............;
OPERANDE
TYPE
VALEUR DEFAUT
N
Numéro d'un ensemble ou groupe de paramètres
Néant
P
Valeur d'un paramètre (réelle)
Néant
EXEMPLES :
PARAMETERS : 5 , 3.0 , 1.2 : 4 , 0.3 , 1 , 0.9 , 2 , 1.0 , 3 ;
On a défini deux ensembles ou groupes de paramètres. L'un ayant le numéro 5 et le deuxième
pour numéro 4. L’ensemble numéro 5 a deux paramètres dont les valeurs sont 3.0 et 1.2. Si on
utilise par exemple le numéro de cet ensemble comme argument d’une distribution normale , alors
le paramètre 3.0 sera consiédrée comme la moyenne de la distribution et le paramètre 1.2 comme
l’écart type. Utilisé avec la distribution Uniforme, 3.0 sera considéré comme le minimum et 1.2
comme le maximum (ce qui peut engendrer une erreur Minimum > maximum !). Pour l’ensemble
ayant pour numéro 4, s’il est utilisé avec une distribution empirique, cela signifie que la variable
aléatoire prend pour valeurs 1 , 2 et 3 avec les probabilités cumulées 0.3 , 0.9 et 1.0
respectivement.
On remarque donc que la valeur d’un paramètre est interprétée en fonction de son ordre
d’apparition dans le groupe de paramètres et de la distribution qui référence ce groupe.
28
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.8 Instruction RANKINGS
Utilisée pour définir la règle de gestion des files d'attentes. Par défault , une file d'attente est
gérée selon la règle FIFO (First In - First Out : Premier Arrivé - Premier Servi). Cependant, dans
certains cas, cette règle peut ne pas être adaptée pour la gestion d'une file d'attente donnée et il serait
utile de pouvoir la changer selon le besoin du modèle. Ceci peut justement être fait grâce à
l'instruction RANKINGS.
Les règles de gestion possibles sont :
FIFO : les entités sont rangées dans la file selon leur temps d'arrivée
dans la file et la première arrivée sera servie en premier.
LIFO : les entités sont rangées dans la file selon leur temps d'arrivée
dans la file mais la dernière arrivée sera servie en premier.
LVF(K) : les entités sont rangées selon un ordre croissant de la valeur de
l'attribut numéro K de l'entité. Ainsi l'entité qui sera servie en
premier est celle dont la valeur de cet attribut est la plus petite.
HVF(K) : les entités sont rangées selon un ordre decroissant de la valeur
de l'attribut numéro K de l'entité. Ainsi l'entité qui sera servie en
premier est celle dont la valeur de cet attribut est la plus
grande.
FORMAT INSTRUCTION:
RANKINGS
RANKINGS : N , REGLE : .............;
OPERANDE
DEFAUT
TYPE
N
Numéro de la file d'attente ou ensemble
de files auxquelles appliquer la règle spécifiée
REGLE
Règle de gestion : FIFO , LIFO , LVF(K) ou HVF(K)
K étant un entier
EXEMPLES :
VALEUR
Néant
Néant
RANKINGS : 5 , LIFO : 1-4 LVF(3);
On a défini pour la file d’attente numéro 5 la règle de gestion LIFO. Pour les files d’attentes 1 à
4 on applique la règle LVF c’est à dire que les entités seront classées selon un ordre croissant de la
valeur de leur attribut numéro 3 {LVF (3)}.
Toutes les autres files seront gérées par défaut selon la règle FIFO.
29
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.9 Instruction DSTAT
Utilisée pour obtenir des statistiques liées au paramètre temps (Timepersistent) sur des variables d'un modèle à événements discrets. A chaque
variable sera associé un numéro qui désigne un régistre dans lequel seront
maintenues les statistiques sommaires (Moyenne, variance, ecart type, ...)
pour la variable correspondante.
FORMAT INSTRUCTION:
DSTAT
DSTAT : N , DVAR , ID , UNITE : repeats...............;
OPERANDE
VALEUR DEFAUT
Numéro associé à la statistique(entier)
N
DVAR
TYPE
Néant
Nom de la variable pour laquelle on veut
collecter des statistiques liées au temps
[X(K), NE(K) , NQ(K) , NR(K), NT(K), LC(K), MR(K) ou MT(K) ]
Identificateur (16 caractères Max.)
(entête sur le rapport de sortie)
ID
UNITE
Numéro de l'unité périphérique sur laquelle
enregistrer chaque changement de la variable
Unité est incrémenté à chaque nouvelle exécution)
Néant
des Blancs
Pas de
Sauvegarde
EXEMPLES :
DSTAT : 1 , NQ(1) , QUEUE 1 : 2 , NR(1) , UTILIZ. MACHINE;
La variable numéro 1 représente le nombre d'entités dans la file 1 (NQ(1)).
L'identificateur qui sera utilisé comme entête lors de l'édition des statistiques
concernant cette variable est QUEUE 1. La variable numéro 2 représente le
nombre d'unités de la ressource 1 qui sont occupées (NR(1)). L'identificateur qui
sera utilisé comme entête lors de l'édition des statistiques concernant cette
variable est UTILIZ. MACHINE.
30
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
9.10 Instruction TRACE
Utilisée pour obtenir une trace d'exécution de la simulation. Dans le
cas d'un modèle à événements discrets (diagramme à blocs), la trace fourni
des informations détaillées sur le mouvement des entités à travers les blocs
du diagramme, les valeurs prises par les variables, les ressources allouées,
etc.
Dans le cas d'une approche par événements, la trace fournit des
informations sur les occurrences des événements ainsi que toutes les
opérations réalisées lors du traitement d'un événement.
On peut en plus des informations fournies en standard par SIMAN
dans une trace, demander la trace des valeurs de variables spécifiques
(jusqu'à 4 variables : NQ(), S(), ...).
Un tel rapport de trace sert principalement à des fins de mise au point
et de vérification d'un modèle.
FORMAT INSTRUCTION:
TRACE
TRACE : Tdébut, Tfin, Condition, VAR ,.....VAR;
OPERANDE
VALEUR DEFAUT
TYPE
Tdébut
Temps de début de la trace
(Relatif au temps de début de la simulation)
0.0
Tfin
Temps de fin de la trace
(Relatif au temps de début de la simulation)
∞
Condition pour exécuter la trace
(si Condition = vrai tracer sinon rien)
Condition
Var
Nom de la variable ou attribut à tracer
(maximum 4 variables)
Pas de variables
Tracées
EXEMPLES :
TRACE;
Une trace standard est produite au temps 0 (Tdébut = 0.0 par défaut)
relativement au temps de début de la simulation. Ceci revient à dire que la trace
a lieu depuis le début de la simulation et se poursuit jusqu'à la fin de la
simulation (Tfin est par défaut infini).
TRACE, 0 , 10 , M.EQ.1.OR.M.EQ.2, A(1), NQ(1), S(1) , M;
Cette trace commence au temps 0 (Tdébut = 0) et dure pendant 10 unités de
temps. La trace n'a lieu que si la condition (M.EQ.1.OR.M.EQ.2) est vraie. On
demande en plus de la trace standard, de tracer aussi les variables A(1) , NQ(1) ,
S(1) et M.
31
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
32
(OpPHQWV GH FRQVWUXFWLRQ G XQ GLDJUDPPH j EORFV SDUWLH PRGqOH
Nous allons présenter une liste non exhaustive de blocs à utiliser pour la
construction d'un diagramme à blocs (ou la partie Modèle). Cette liste suffit aussi
pour être à même de construire un modèle de simulation qu'il faudra soumettre à
l'utilitaire MODEL tel que expliqué plus haut.
BLOC :
CREATE (Création d'entités)
SYMBOLE GRAPHIQUE
CREATE, NB
TBC , MC
FONCTION : Ce bloc permet la création d'entités (injection d'entités
dans le système).
FORMAT INSTRUCTION :
CREATE, NB , : TBC , MC : MODIFIERS ;
PARAMETRE
TYPE
VALEUR DEFAUT
NB
Nombre d'entités à créer à chaque fois
Entier > 0 ou X(K) k étant 1 entier
1
TBC
Time Between création: durée entre
les créations (expression)
∞
MC
Nombre maximum d'entités à créer
∞
EXEMPLES :
CREATE
EX(1,1)
Il y a création d'une entité à chaque fois. La première
entité est créée au temps égal à 0. Le temps séparant
les créations suit une distribution exponentielle. Le
nombre maximum de créations est infini.
CREATE , EX(1,1);
CREATE, X(1)
UN(2,1) , 12
Le nombre d'entités à créer à chaque fois est de X(1).
Le premier lot d'entités est créée au temps égal à 0.
Le temps séparant les créations suit une distribution
uniforme. Le nombre maximum de créations est de
est de 12.
CREATE , X(1) : UN(2,1), 12;
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC :
QUEUE (File d'attente )
SYMBOLE GRAPHIQUE
IFL , QC
LBALK
FONCTION :
Ce bloc permet de modéliser une file d'attente. Une entité se met en file
d'attente parce que l'état du système ne lui permet pas de progresser. Par
exemple, elle demande l'occupation d'une ressource (machine, opérateur, ..) qui
n'est pas libre.
Une file d'attente est caractérisée par sa capacité maximale et par un numéro.
Normalement, lorsqu'une entité arrive dans une queue qui est pleine , cette
entité est détruite (perdue). Néanmoins SIMAN propose une option permet de
dévier (BALK ou Balking) de telles entités vers d'autres blocs. Il suffit de préciser
le label du bloc où on veut diriger les entités qui arrivent dans une queue pleine.
Une file d'attente est caractérisée aussi par sa discipline de gestion (FIFO
:premier arrivée-PremierServi , LIFO : Dernier-Arrivé-Premier Servi, HVF(K) :
High Value-First premier servi est celui ayant la plus grande valeur de l'attribut
K, LVF(K) : Low Value Fisrt premier servi sera celui qui a la plus petite valeur de
l'attribut K.ne peut plus progresser la création d'entités (injection d'entités dans
le système). Cette discipline n'est pas spécifiée dans le bloc QUEUE mais dans le
cadre d'expérimentation.
FORMAT INSTRUCTION :
QUEUE, IFL , QC , LBALK : MODIFIERS ;
PARAMETRE
TYPE
Numéro de la file
(entier : K , M+K ou M-K )
Capacité de la file (A(I), X(I) ou I)
IFL
QC
LABLK
Label du bloc vers lequel diriger
les entités si la file est pleine
VALEUR DEFAUT
Néant
∞
Détruire l'entité
EXEMPLES :
1
QUEUE, 1 ;
1, 3
Le numéro de la file est 1. Sa capacité est infinie.
Le numéro de la file est 1 et sa capacité est de 3. Les
entités qui arriveront alors que la file est pleine seront
détruites.
QUEUE, 1, 3 ;
1, X(3)
VERIF
QUEUE, 1, X(3), VERIF ;
Le numéro de la file est 1 et sa capacité est fournie
par de la valeur courante de la variable SIMAN X(3).
Les entités qui arriveront alors que la file est pleine
seront dirigées vers le bloc ayant pour étiquette
VERIF.
33
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
REMARQUES :
La modélisation d'un phénomène qui engendre la création d'une file d'attente
se fait en utilisant un bloc de type HOLD. Un tel bloc doit donc être toujours
precédé par au moins un bloc QUEUE afin de retenir les entités devant attendre
qu'un changement d'état ait lieu. La combinaison la plus simple de ces deux
blocs serait :
Cette combinaison peut servir à modéliser une variété de situations dans
lesquelles une entité se met en attente d'un changement d'état du système. De
même, il est possible de faire précéder un bloc HOLD par plusieurs blocs
QUEUE et non pas un seul (voir le bloc QPICK).
La combinaison la plus courante est celle modélisant une demande
d'allocation d'une ressource par une entité. C'est le bloc qu'on appelle SEIZE du
nom de la fonction réalisée (SEIZE) et qui n'est en fait qu'un bloc HOLD (Voir les
explications données plus haut concernant le bloc HOLD).
Notion de RESSOURCE dans SIMAN :
Le terme ressource désigne tout objet du système pouvant exécuter un
service pour le compte d'une entité. Une ressource est donc allouée à une entité
qui en fait la demande et est caractérisé par son état qui peut être : Libre (IDLE)
ou Occupé (Busy). Elle possède aussi une capacité qui est le nombre d'unités de
la ressource. Ainsi une entité peut demander l'allocation de plusieurs unités de
la ressource en même temps. De même qu'une particularité intéressante de cette
notion de ressource, est que plusieurs entités distinctes peuvent disposer
simultanément de la ressource, chaque entité disposant d'un certain nombre
d'unités. Des exemples d'objet d'un système qu'on peut modéliser comme une
ressource sont : Machine, opérateur, Outils (d'une machine à outils), etc.
Une ressource est identifiée par son nom et sa capacité qui sont spécifiés
dans le cadre d'expérimentation et non dans le modèle (ou diagramme à blocs).
L'allocation d'une ressource à une entité se fait par le biais d'un bloc de type
HOLD avec comme fonction SEIZE. Lorsque plusieurs bloc SEIZE demandent l
'allocation d'une même ressource, l'allocation se fait selon une priorité spécifiée
comme paramètre du bloc SEIZE. Lorsque le nombre d'unités de la ressource
requis par une entité est disponible, ces unités sont allouées à l'entité qui quitte
alors le bloc SEIZE. Dans le cas contraire, l'entité reste dans la file d'attente
associée au bloc QUEUE précédent le SEIZE jusqu'à ce que le nombre d'unités
soit disponible.
La priorité d'allocation d'une ressource peut être spécifiée comme un entier,
un attribut de la première entité se trouvant dans la file d'attente ou comme la
valeur de la variable globale X(I) de SIMAN. Dans tous les cas , la préférence est
donnée à l'entité ayant la plus petite valeur de la priorité.
34
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC :
SEIZE (Allocation d'une Ressource)
SYMBOLE GRAPHIQUE
SEIZE , PRIOR
RNAME , NR
FONCTION :
Ce bloc permet d'allouer une ressource à une entité. L'entité reste
dans la file d'attente (bloc QUEUE précédent ce bloc SEIZE) jusqu'à ce
que le nombre d'unités demandé et la priorité (en cas de conflit avec
d'autre entités qui demandent aussi l'allocation de la même ressource) lui
permettent de traverser le bloc SEIZE. Une entité qui traverse le bloc
SEIZE est donc une entité qui a pu disposer des unités qu'elle a
demandé. L'état de ces unités passe à Occupé (BUSY).
FORMAT INSTRUCTION :
SEIZE , PRIOR : RNAME , NR : MODIFIERS ;
PARAMETRE
PRIOR
RNAME
NR
TYPE
Priorité d’allocation de la Ressource
(A(I) , X(I) , ou I : I étant un entier)
Nom de la Ressource
Nombre d'unités à allouer
(A(I), X(I) ou I : I est un entier)
VALEUR DEFAUT
1
Néant
1
EXEMPLES :
1
SEIZE
Les entités attendent dans la file
n°1 et demandent d'allouer 2
unités de la ressource ayant
pour
nom : OPERATOR
SEIZE : OPERATOR, 2 ;
OPERATOR, 2
1
SEIZE, A(1)
SERVEUR
Les entités attendent dans la file
n°1 et demandent d'allouer 1
unité de la ressource ayant pour
nom : SERVEUR. La priorité du
SEIZE , A(1) : SERVEUR ;
bloc SEIZE par rapport aux
autres est égale à la valeur de
l'attribut A(1) de la première
entité de la file 1.
35
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC :
RELEASE (Libération d'une Ressource)
SYMBOLE GRAPHIQUE
RELEASE
RNAME , NR
FONCTION :
Une entité peut libérer une ou plusieurs unités d'une ressource. Ceci
se fait en utilisant un bloc OPERATION avec comme fonction RELEASE et
en spécifiant le nom de la ressource et le nombre d'unités à libérer. L'état
des unités libérées est changé et passe à LIBRE (IDLE). Ces unités
deviennent donc disponible pour une éventuelle allocation à d'autres
entités qui en font la demande dans les blocs SEIZE.
FORMAT INSTRUCTION :
RELEASE : RNAME , NR : MODIFIERS ;
PARAMETRE
RNAME
NR
TYPE
Nom de la Ressource
(voir instruction RESOURCE du
cadre d'expérimentation)
Nombre d'unités à libérer
(A(I), X(I) ou I : I est un entier)
VALEUR DEFAUT
Néant
1
EXEMPLES :
RELEASE
SERVEUR
Une unité de la ressource
ayant pour nom SERVEUR
RELEASE : SERVEUR;
est libérée.
RELEASE
OPERATOR,5
RELEASE : OPERATOR , 5;
RELEASE
DISQUE, A(1)
RELEASE : DISQUE, A(1) ;
5 unités de la ressource
ayant pour nom OPERATOR
est libérée.
Le nombre d'unités de la
ressource ayant pour nom
DISQUE qui sont libérées
est spécifié dans l'attribut
n° 1 de l'entité (A(1)).
36
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC :
ASSIGN (Affectation de valeur à une variable ou à
un Attribut)
SYMBOLE GRAPHIQUE
ASSIGN
VAR = valeur
FONCTION :
Ce bloc permet d'affect une valeur à une variable ou à un attribut
FORMAT INSTRUCTION :
ASSIGN : VAR = valeur : MODIFIERS ;
PARAMETRE
VAR
TYPE
VALEUR DEFAUT
Nom de la variable
A(I), X(I), S(I) , D(I) , P(I,K), J, M
valeur
une expression
Néant
Néant
EXEMPLES :
La valeur 3 est affecté au premier attribut (N° 1)
de chaque entité arrivant au bloc ASSIGN.
ASSIGN
A(1) = 3
ASSIGN : A(1) = 3;
La valeur qui sera affectée à la variable X(1)
sera calculée en générant une valeur à partir
d'une distribution exponentielle à laquelle on
additionne 0.2. le résultat est affecté à X(1)
ASSIGN
X(1)= EX(1,1) +0.2
ASSIGN : X(1) = EX(1,1) + 0.2;
37
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC :
DELAY (Consommation de temps par une entité)
SYMBOLE GRAPHIQUE
DELAY
Durée
FONCTION :
Ce noeud permet de modéliser une activité dans laquelle s'engage une
entité et qui consomme du temps (ex: subir une opération sur une
ressource).
FORMAT INSTRUCTION :
DELAY : Durée : MODIFIERS ;
PARAMETRE
Durée
TYPE
VALEUR DEFAUT
une expression spécifiant la durée
(constante, expression arithmétique
impliquant des variables SIMAN)
0.0
EXEMPLES :
DELAY
A(1)
La durée est la valeur de l'attribut A(1) de
l'entité arrivant au bloc. Cette valeur aura été
par exemple affectée à l'attribut A(1) dans un
bloc ASSIGN.
DELAY : A(1);
DELAY
La durée est égale à la valeur donnée par
l'évaluation de l'expression
X(M+1) + 0.3
DELAY : X(M+1) + 0.3;
38
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC :
TALLY (Collecte d'observations = Pointage)
SYMBOLE GRAPHIQUE
TALLY
N , VAR
FONCTION :
Ce bloc permet de collecter la valeur d'une variable à chaque arrivée à
ce bloc. Les valeurs collectées sont additionnées dans un registre identifié
par son numéro N spécifié comme argument du bloc. Des statistiques
telle que la moyenne, variance, minimum , maximum ainsi que le nombre
d'observations relevées sont aussi maintenues. Il est possible de collecter
les observations individuelles qu'on conservera dans un fichier.
FORMAT INSTRUCTION :
TALLY : N , VAR : MODIFIERS ;
PARAMETRE
N
VAR
TYPE
Entier représente le numéro
d'un registre
La valeur à collecter
(Expression , INT(K) ou BET(K) )
VALEUR DEFAUT
Néant
Néant
INT(K) : Collecte de TNOW - A(K)
BET(K) : Collecte de TNOW - X(K)
EXEMPLES :
INT signifie INTERVAL et consiste à collecter la
valeur calculée TNOW - A(2) à chaque arrivée d'une
entité au bloc. La collecte se fera dans le registre
1 , INT(2)
ayant pour numéro 1. Par exemple si dans un bloc
précédent on a marqué (MARK(2) ) l'attribut 2 de
l'entité, TNOW - A(2) représente alors le temps mis
TALLY : 1, INT(2) ;
par l'entité pour aller du bloc ou on a fait le marquage
jusqu'au bloc TALLY.
TALLY
TALLY
2 , BET(1)
TALLY : 2, BET(1) ;
BET signifie BETWEEN et consiste à collecter la
valeur calculée TNOW - X(1) à chaque arrivée d'une
entité au bloc et initialisation de X(1) avec TNOW. La
collecte se fera dans le registre ayant pour numéro
2. Les valeurs collectées représente les temps entre
les arrivées successives au bloc.
39
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC :
COUNT (Collecte d'observations par
incrémentation de compteur)
SYMBOLE GRAPHIQUE
COUNT
N , INC
FONCTION :
Ce bloc permet d'incrémenter un compteur N avec un pas (INC) à
chaque arrivée d'une entité au bloc. Ce bloc peut aussi être utilisé pour
contrôler la fin de la simulation. En effet , après incrémentation du
compteur, sa valeur est automatiquement comparée à une limite qui est
spécifiées dans le cadre d'expérimentation (Experimental Frame). Si la
valeur du compteur est ≥ à cette limite, la simulation s'arrête.
FORMAT INSTRUCTION :
COUNT : N , INC : MODIFIERS ;
PARAMETRE
N
TYPE
Entier représente le numéro
d'un registre (compteur)
Le pas d'incrémentation
(A(I) , X(I) ou I )
INC
VALEUR DEFAUT
Néant
1
EXEMPLES :
COUNT
1,1
Le compteur 1 est incrémenté de 1 chaque fois qu'une
entité arrive au bloc. Si après incrémentation , la
valeur du compteur est > ou = à la limite du
compteur (spécifiée dans l'Experimental Frame), la
simulation est arrêté.
COUNT : 1, 1 ;
COUNT
M , A(1)
COUNT : M, A(1) ;
Le compteur M est incrémenté avec A(1) . Si après
incrémentation , la valeur du compteur est > ou = à la
limite du compteur (spécifiée dans l'Experimental
Frame), la simulation est arrêté.
40
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC :
BRANCH (branchement vers un bloc non séquentiel)
MAXTAKE
SYMBOLE GRAPHIQUE
IF, Cond
With, P
ELSE ou ALWAYS
Label1
Label2
Label3
FONCTION :
Ce bloc permet de faire faire des branchements conditionnel ou probabiliste
vers d'autres blocs. Il offre un moyen plus sophistiqué de contrôle du flux des
entités. Il existe 3 types de branchements :
- Probabiliste (WITH, P) : dans ce cas la branche est sékectionnée avec une
probabilité P. La somme des probabilités de ce type de branche doit être
comprise entre 0 et 1.
- Conditionnel (IF , Condition) : la branche est sélectionnée si la condition est
vraie.
- Déterministe (ELSE ou ALWAYS) : la branche est sélectionnée si un nombre
maximum de MAXTAKE branches n'a pas été sélectionnées.
Un branchement se fait toujours vers un autre bloc dont on fournit le label.
FORMAT INSTRUCTION :
PARAMETRE
MAXTAKE
P
C
Label1 , ..
TYPE
BRANCH , MAXTAKE :
IF , Cond , Label1 :
WITH, P , Label2 :
ELSE (ou ALWAYS) : Label3 ;
VALEUR DEFAUT
∞
Nombre de branches maximum à emprunter
(sur chaque branche sera routée une copie
de l 'entité qui arrive au bloc à créer
Probabilité de selection d'une branche
(Constante ou expression entre 0 et 1)
Condition
Labels des blocs vers lesquels se brancher
Néant
Néant
Néant
41
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
EXEMPLES:
2
IF, A(1).EQ.1
With, A(2)
ELSE
NEXT
REFAIRE
EXIT
BRANCH , 2 :
IF , A(1).EQ.1 , NEXT :
WITH, A(2) , REFAIRE :
ELSE , EXIT ;
ALWAYS
MACHINE1
ALWAYS
MACHINE2
BRANCH :
ALWAYS , MACHINE1 :
ALWAYS , MACHINE2;
On emprunte 2 branches aux maximum. La première
branche est empruntée si la condition A(1).EQ.1 est
vraie. Dans ce cas une copie de l’entité est routée
vers le bloc ayant pour label NEXT. Le choix de la
deuxième branche est probabiliste. Cette branche
sera donc empruntée avec une probabilité égale à
l’attribut A(2) de l’entité. Une copie de l’entité sera
routée vers le bloc ayant pour Label REFAIRE. La
dernière branche est de type deterministe et sera
empruntée si au moins une des branches précédentes
n’aura pas été empruntée. Dans ce cas, une copie de
l’entité sera routée vers le bloc ayant pour Label
EXIT.
Dans cet exemple, les deux branches sont
deterministes. La valeur par défaut de MAXTAKE
étant infinie, les deux branches seront donc
empruntée et une copie de l’entité sera routée vers le
bloc ayant pour label MACHINE1et une autre copie
vers le bloc ayant pour label MACHINE2 .
42
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOCS : WAIT et SIGNAL (Attente de durée indéfinie)
Symboles graphiques :
SIGNAL
WAIT
NSIGNAL
NSIGNAL
Fonction :
Contrairement au bloc DELAY qui permet de modéliser les phénomènes
d’attente dont on connait à l’avance la durée, le bloc WAIT permet quant à lui
de modéliser les phénomènes d’ attente dont la durée n’est pas connue et est
fonction de l’évolution de l’état du système. Ce bloc WAIT fonctionne en
conjonction avec un autre bloc SIGNAL qui permet d’envoyer un signal en
vue de débloquer les entités qui se sont mises en attente par un bloc WAIT.
FORMAT INSTRUCTIONs:
WAIT : NSIGNAL : MODIFIERS;
SIGNAL : NSIGNAL : MODIFIERS;
OPERANDE
VALEUR DEFAUT
TYPE
NSIGNAL
Nuémro du signal à attendre (entier)
(A(I), X(I) ou I)
Néant
EXEMPLES :
QUEUE , 1;
1
WAIT : A(1);
WAIT
Une entité qui arrive au bloc WAIT
se met en attente du signal dont le
numéro est égal à l'attribut A(1) de
l'entité. La file d'attente dans laquelle
les entités attendront est la file N° 1.
A(1)
SIGNAL
2
SIGNAL : 2;
Lorsqu'une entité arrive à ce bloc,
toutes les entités se trouvant dans la
file N°1 et dont l'attribut A(1) est égal
à 2 quittent la file d'attente et
traversent WAIT
43
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOCS : ALTER (Modification de la capacité d'une Ressource)
Symbole graphique :
ALTER
RNAME, Unités
Fonction :
Ce bloc permet de modifier la capacité (nombre d’unités) d’une ressource.
FORMAT INSTRUCTION:
ALTER : RNAME , Unités : MODIFIERS;
OPERANDE
RNAME
Unités
TYPE
VALEUR DEFAUT
Nom de la ressource
Nombre d'unités à ajouter ou retrancher
de la capacité courante de la ressource
(A(I), X(I) ou I)
Néant
Néant
EXEMPLES :
ALTER
SERVEUR,
-2
Le nombre d'unités de la ressource SERVEUR est
decrémenté de 2 unités.
ALTER : SERVEUR , -2;
ALTER
FRAISEUSE, A(1)
Le nombre d'unités de la ressource FRAISEUSE
est changé avec une valeur égale à l'attribut A(1)
de l'entité qui arrive au bloc ALTER. Ce changement
peut être une incrémentation (A(1) > 0) ou l'inverse.
ALTER : FRAISEUSE , A(1);
44
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOCS : SELECT (Selection d'une Ressource parmi plusieurs)
Symbole graphique :
REGLE
LABEL
LABEL
Fonction :
Lorsqu’une entité doit subir une opération sur une ressource et qu’il existe
plusieurs ressources différentes (noms différents) qui peuvent réaliser
l’opération, le choix ou la sélection d’une ressource parmi cet ensemble est
fait grâce au bloc SELECT. Pour cela, des crières ou règles de sélection d’une
ressource sont nécessaires. On dispose des critères suivants :
• CYC
• RAND
: Choix cyclique. On choisit la ressource disponible qui suit
immédiatement celle qu’on a alloué juste avant. Au niveau du
modèle, il s’agira du bloc SEIZE ou PREEMPT (associé à une
resource) qui suit le bloc SEIZE ou PREEMPT vers lequel on a
dirigé une entité lui allouant ainsi cette ressource.
: Choix Aléatoire. On choisit aléatoirement la ressource disponible
(nombre d’unités disponible suffisant). Au niveau du modèle, il
s’agira de choisir un bloc SEIZE ou PREEMPT vers lequel diriger
l’entité.
• POR
: Choix selon l’ordre d’apparition. Contrairement au choix
aléatoire, ici on choisit la première ressource disponible
(nombre d’unités disponible suffisant).
• LNB
: (Largest Number Busy). Choisir parmi les ressources ayant le
plus grand d’unités occupées, la première dont le nombre
d’unités encore libres est suffisant.
• SNB
: (Smallest Number Busy). Choisir parmi les ressources ayant le
plus petit nombre d’unités occupées, la première dont le
nombre d’unités encore libres est suffisant.
• LRC
: (Largest Remaining Capacity). Choisir parmi les ressources
ayant la capacité la plus grande (en nombre d’unités) , la
première dont le nombre d’unités encore libres est suffisant.
• SRC
: (Smallest Remaining Capacity). Choisir parmi les ressources
ayant la capacité la plus petite (en nombre d’unités) , la
première dont le nombre d’unités encore libres est suffisant.
• UR(K)
: (User Rule). Choisir une ressource en fonction d’un paramètre UR
calculée par une routine écrité par l’utilisateur(Subroutine
FORTRAN).
• ER(N)
: (Experimental Rule). Choisir une ressource en fonction d’un règle
N définie dans le cadre d’expérimentation (Experimental Frame:
RULES).
45
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
FORMAT INSTRUCTION:
SELECT : REGLE , LABEL : LABEL : ........LABEL;
OPERANDE
TYPE
VALEUR DEFAUT
REGLE
Règle de sélection d'une ressource
LABEL
Label d'un bloc HOLD (voir les types de
fonctions possibles : SEIZE , PREEMPT , ...)
POR
Néant
EXEMPLES :
1
RAN
Lorsqu'une entité arrive au bloc QUEUE, et qu'il
existe des Machines libres , le choix de la machine
à lui allouer est fait de manière aléatoire(RAN).
Dans le cas où toutes les machines sont occupées,
l'entité
attend dans la file N°1.
MACHINE1
MACHINE2
MACHINE3
M1
M2
SEIZE
L'ordre d'apparition des LABELS des blocs
HOLD (SEIZE.....) dans SELECT est utilisé par
la règle POR.
MACHINE1
SEIZE
MACHINE2
QUEUE,1;
SELECT, RAN : M1:M2:M3;
M1 SEIZE : MACHINE1;
M2 SEIZE : MACHINE2;
M3
SEIZE
MACHINE3
M3 SEIZE : MACHINE3;
46
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOC : MATCH (Synchronisation du mouvement des entités)
Symbole graphique :
Format
MATCH, MA : QLBL , LABEL : ..........QLBL, LABEL;
MA
T
T
: N° attribut de synchronisation (défaut : néant)
QLBL : Label d'un bloc QUEUE (défaut : Néant)
LABEL: label du bloc destination correspondant à ce bloc QUEUE (défaut : Détruire)
Fonction :
Il arrive souvent que l’exécution d’une opération necessite la presence de plusieurs entités en même
temps. ceci est le cas par exemple d’une opération d’assemblage de pièces qui ne peut demarrer
que lorsque les pièces (entités) à assembler soient toutes présentes. Il faudra donc un mécanisme
pour synchroniser le mouvement des entités dans le système. C’est justement ce que fait le bloc
MATCH.
MATCH s’applique à deux ou plusieurs blocs QUEUE qui le précèdent et consiste à retarder les
entités dans leurs files d’attente respectives (Blocs QUEUE) jusqu’à ce que toutes ces entités
possèdent la même valeur de l’attribut de synchronisation.
Lorsqu’une entité arrive au bloc MATCH, une recherche est déclenchée dans les blocs QUEUE
precedents pour voir si chaque bloc contient une entité ayant la même valeur de l’attribut de
synchronisation. Si c’est le cas, chacune des entités résidant dans un bloc QUEUE est extraite du
bloc puis routée vers le bloc dont le LABEL est spécifié comme paramètre du bloc MATCH.
Normalement pour chaque bloc QUEUE correspond un LABEL du bloc vers lequel sera routée
l’entité prise dans la file d’attente associée au bloc QUEUE. Si ce label est omis, l’entité extraite
du bloc QUEUE est détruite.
Chaque bloc QUEUE associé à un bloc MATCH doit posséder un LABEL et utiliser comme
connecteur l’option DETACH pour empecher son utilisation par un autre bloc MATCH ou
QPICK.
T
T
Les entités de la file 1 représentent
des malades. Les entités de la file 2
représentent les dossiers. Une visite ne
peut avoir lieu que lorsque le malade
est présent ainsi que son dossier.
En supposant qu'à chaque malade est
associé un numéro qui a été affecté à
l'attribut N°3 A(3). On suppose aussi
qu'à l'attribut N°3 de l'entité
représentant le dossier du malade a été
affecté le numéro du malade
correspondant (ASSIGN).
L'attribut N°3 sert donc d'attribut de synchronisation dans le bloc MATCH. Lorsqu'un malade arrive dans le
bloc QUEUE et qu'un dossier est aussi présent dans le bloc QUEUE associé à la file 2 et que ces deux entités
ont la même valeur de l'attribut N°3, le MATCH a lieu. Le malade est extrait du bloc QUEUE dont le LABEL
est MALADE puis routé vers le bloc ayant pour LABEL VISITE. Le dossier correspondant à ce malade et
figurant dans le bloc QUEUE dont le label est DOSSIER est extrait du bloc QUEUE puis detruit du fait
qu'aucun label n'a été spécifié pour ce bloc QUEUE.
47
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
48
BLOC : PREEMPT (Allocation de Ressource par Preemption)
Symbole graphique :
PREEMPT, PR
RNAME, NA, LSEND
FORMAT INSTRUCTION:
PREEMPT, PR : RNAME , NA , LSEND : MODIFIERS....;
OPERANDE
TYPE
VALEUR DEFAUT
PR
Priorité de préemption (entier A(I), X(I) ou I)
1
RNAME
Nom de la ressource
Néant
NA
Néant
Nuémro de l'attribut dans lequel stocker le temps restant
de l’entité à laquelle on a retiré la ressource
LSEND Label du bloc vers lequel diriger l'entité à laquelle
Bloc QUEUE associé au bloc SEIZE
on a retiré la ressource
ou PREEMPT précédent
EXEMPLES :
PREEMPT
MACHINE
L'entité qui arrive au bloc essaie d’acquérir une unité de la ressource
Machine. Si la ressource est occupée et que la préemption ne peut avoir
lieu à cause de la priorité de préemption (1), l’entité est mise en attente
dans la file associée au bloc QUEUE précédent jusqu’à ce que 1 unité
lui soit allouée.
PREEMPT : MACHINE;
PREEMPT, A(1)
CPU , 2, RELANCER
L'entité qui arrive au bloc essaie d’acquérir une unité de la
ressource CPU. La priorité de préemption est spécifiée
dans l’attribut A(1) de l’entité. Le temps de traitement
restant de l’entité à laquelle sera retirée le CPU est stocké
dans l’attribut 2 de l’entité qui sera alors routée vers le bloc
ayant pour Label RELANCER.
PREEMPT , A(1) : CPU , 2 , RELANCER;
Le bloc PREEMPT est une spécialisation du bloc HOLD qui permet de modéliser l’allocation d’une ressource
par préemption. Ceci siginifie que cette ressource peut être déjà occupée par une entité qui en a disposé dans un
bloc SEIZE - DELAY ou dans un autre bloc PREEMPT. Dans ce cas, il se peut qu’on lui retire cette ressource
pour l’allouer à une autre entité qui arrive au bloc PREEMPT. Le processus de préemption est contrôlé par un
paramètre de priorité spécifié comme opérande du bloc PREEMPT. Lorsqu’une entité détient une ressource
qu’elle s’est faite alloué dans un bloc SEIZE, toutes les entités arrivant à un bloc PREEMPT et demandant à
acquérir cette ressource sont prioritaires sur cette entité et ce quelque soit la priorité spécifiée. Par contre lorsque
la ressource a été allouée à une entité dans un bloc PREEMPT, toutes les entités arrivant à un bloc PREEMPT et
demandant à acquérir cette ressource ne peuvent l’acquérir que si leur priorité est supérieure à celle de cette entité
(spécifiée comme paramètre du PREEMPT).
Lorsqu’une Ressource a été retirée à une entité suite à un PREEMPT, cette entité est remise dans la file d’attente
associée au bloc QUEUE prédédent le bloc SEIZE ou PREEMPT dans lequel s’était faite l’allocation. Cette entité
sera placée en tête de file et se verra allouer la ressource dès que celle-ci devienne disponible. Il est possible de
diriger explicitement l’entité vers un autre bloc au lieu du bloc QUEUE qui est pris par défaut. Ceci peut être fait
en spécifiant le label du nouveau bloc ainsi que le numéro d’attribut dans lequel stocker le temps de service
restant comme paramètres du bloc PREEMPT.
Le nombre d’unités d’une ressource qui est alloué par un bloc PREEMPT est toujours 1. L’ utilisation habituelle
du bloc PREEMPT est pour les ressources ayant une capacité de 1 unité. Dans le cas où la ressource a une capacité
> 1 unité, c’est toujours à la dernière unité allouée de cette ressource que s’appliquera le PREEMPT.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
49
FILES D’ATTENTE PARALLELES
Lorsqu’on a modéliser une ressource à laquelle sont associées plusieurs files d’attente contenant chacune un
type d’entité, va se poser le problème de choix de la file dans laquelle prendre une entité pour lui allouer la
ressource. Ce cas est modélisé grâce au bloc QPICK
Une autre situation où on est amené à choisir une file d’attente parmi plusieurs est celle d’une entité qui arrive à
une ressource à laquelle sont associées plusieurs files d’attente. Un problème de choix de la file dans laquelle
insérer l’entité se pose aussi. Ce cas est modélisé grâce au bloc PICKQ.
La règle à utiliser pour la selection d’une file d’attente (QUEUE SELECTION RULE) doit être spécifiée comme
paramètre du bloc (PICKQ ou QPICK). SIMAN offre un ensemble de règles de sélection d’une file d’attente
(caractérisée par le bloc QUEUE correspondant) qui sont :
• CYC
: Choix cyclique. On choisit le premier bloc QUEUE suivant celui qu’on a slectionné juste avant.
• RAND
: Choix Aléatoire. On choisit aléatoirement un bloc QUEUE parmi l’ensemble des blocs
disponibles.
• POR : Choix selon l’ordre d’apparition. Contrairement au choix aléatoire, ici on choisit le premier bloc
QUEUE disponible.
• LNQ : (Largest Number in QUEUE). Choisir le bloc QUEUE ayant le plus grand d’entités dans la file.
Utiliser la règle POR en cas de conflit.
• SNQ : (Smallest Number in QUEUE). Choisir le bloc QUEUE ressources ayant le plus petit nombre
d’entités dans la file. Utiliser la règle POR en cas de conflit.
• LRC
: (Largest Remaining Capacity). Choisir le bloc QUEUE ayant le plus grand nombre
d’emplacements vides dans la file. Utiliser la règle POR en cas de conflit.
• SRC
: (Smallest Remaining Capacity). Choisir le bloc QUEUE ayant le plus petit nombre
d’emplacements vides dans la file. Utiliser la règle POR en cas de conflit.
• UR(K) : (User Rule). Choisir le bloc QUEUE N° UR ou UR est un numéro calculé par une routine écrité
par l’utilisateur sous forme de Fonction Fortran UR(L,K).
• ER(N) : (Experimental Rule). Choisir un bloc QUEUE en fonction de la règle N définie dans le cadre
d’expérimentation (Experimental Frame: RULES).
Dans le cas du choix de la file dans laquelle insérer une entité avec le bloc PICKQ, il se peut que toutes les
files soient pleines. Par défault, l’entité qui arrive est détruite. Cependant, il est possible d’éviter cette
destruction en spécifiant le label du bloc vers lequel diriger cette entité lorsque toutes les files sont pleines.
C’est ce qu’on appelle le BALKING (ou dévier , rediriger). Le label de ce bloc sera alors un opérandre du
bloc PICKQ.
Les blocs QPICK et PICKQ sont utilisés avec au moins 2 blocs QUEUE. Les labels des blocs QUEUE sont
spécifiés comme paramètres du bloc QPICK ou PICKQ. L’entité choisie par le bloc QPICK est routée vers le
block HOLD ou SELECT qui suit immédiatement le bloc QPICK. Dans le cas de PICKQ, l’entité qui arrive à
ce bloc est dirigée vers le bloc QUEUE choisi en fonction de la règle de selection ou est routée vers le bloc de
BALKING si toutes les files sont pleines. L’ordre d’énumération des Labels des blocs QUEUE dans
l’instruction QPICK ou PICKQ établit une priorité qui sert pour l’application de la règle de selection POR
décrite plus haut.
Dans la combinaison des blocs QUEUE-HOLD qui permet de modéliser une ressource à une seule file d’attente ,
la connection entre ces deux blocs est faite selon l’ordre d’apparition des blocs dans le modèle. Pour le cas
d’un bloc QUEUE et d’un bloc QPICK, la connection est faite par le biais des Labels des blocs QUEUE et
non par l’ordre ou le séquencement des blocs dans le modèle. Ainsi chaque bloc QUEUE devant être associé à
QPICK devra avoir un LABEL. Les mêmes remarques sont valables aussi pour le cas du bloc PICKQ.
Par convention, un bloc QUEUE ne peut être connecté qu’à un seul autre bloc dans le modèle. Dans ce cas , si
un bloc QUEUE est associé à un bloc QPICK, il ne devra pas être associé à un autre bloc. Ceci siginifie que
ce bloc QUEUE ne doit pas être connecté à un bloc HOLD ou SLECT et aussi que son Label ne doit pas
être utilisé comme opérande d’un autre bloc (QPICK, MATCH). Afin de prevenir la connection implicite
faite par SIMAN entre un bloc et le suivant , il est necessaire de spécifer qu’on détache ce bloc QUEUE
utilisé par QPICK de son successeur dans le modèle. Ceci se fait grâce à l’option (CONNECTEUR)
DETACH qu’on spécifie dans le bloc QUEUE concerné. Ainsi, ce bloc ne sera pas connecté à son
successeur et reste cependant associé au bloc QPICK par le biais de son LABEL.
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOCS : QPICK (Prise d'une entité dans une file d'attente choisie
parmi plusieurs)
Symbole :
QSR
LABEL1
LABEL2
T
T
FORMAT INSTRUCTION:
QPICK , QSR : LABEL1:.......:LABELn;
OPERANDE
TYPE
QSR
VALEUR DEFAUT
(Queue Selection Rule) Règle de selection de la file
(CYC, RAN, POR, SNQ, ...)
Label de chacun des bloc QUEUE précédents
LABELi
EXEMPLE AVEC QPICK :
POR
FILE1
FILE2
T
T
SEIZE
MACHINE
POR
Néant
La ressource Machine est allouée
aux entités résidant dans les files
d’attente 1 et 2 correspondant aux
blocs QUEUE ayant pour labels
FILE1 et FILE2. La règle de
selection de la file d’attente qui sera
utilisée par QPICK est la règle POR
qui signifie que la priorité est
fonction de l’ordre d’énumération
des labels dans QPICK. Ici c’est la
file 1 correspondant au label FILE1
qui sera choisie en priorité. Les
entités de la file 2 ne seront donc
selectionnées que si la file 1 est vide.
On remarque l’utilisation du
connecteur DETACH avec les deux
blocs QUEUE afin d’émpecher
que ces blocs soient connectés à
d’autres.
50
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
BLOCS : PICKQ (Routage d'une entité vers une file d'attente choisie
parmi plusieurs files )
Symbole :
QSR
LBALK
LABEL1
LABEL2
FORMAT INSTRUCTION:
PICKQ , QSR, LBALK : LABEL1:.......:LABELn;
OPERANDE
TYPE
QSR
LBALK
LABELi
VALEUR DEFAUT
Règle de selection de la file (CYC, RAN, ...)
Label du bloc vers lequel router l’entité si files pleines
Label de chacun des bloc QUEUE suivants
EXEMPLE AVEC PICKQ :
SNQ
EXIT
FILE1
FILE2
),/(
SEIZE
CABINE1
),/(
SEIZE
CABINE2
POR
Détruire l’entité
Néant
Les entités qui arrivent au
bloc PICKQ seront dirigées
vers l’un des blocs QUEUE
ayant pour lables FILE1 et
FILE2. La règle de selection
de la file d’attente qui sera
utilisée par PICKQ est la
règle SNQ qui signifie de
choisir la file contenant le
plus petit nombre d’entités.
Dans le cas ou les deux files
sont
à
leur
capacité
maximale (qui est de 50) ,
l’entité qui arrive est
redirigée (Balked) vers le
bloc ayant pour label EXIT.
Si ce label n’a pas été
spécifié, l’entité aurait été
détruite (option par défaut).
51
Dr Brahim BELATTAR. LISA. Département d'Informatique. Faculté des Sciences de l'Ingénieur. Université de Batna.
52
Fin de ce chapitre
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
ANNEXE A :
Liste 1999 des progiciels de simulation diffus e par
the Institute for Operations Research and the Management Sciences.
Lionheart Publishing, Inc.
2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
URL: http://www.lionhrtpub.com
Product
ALPHA/Sim
Vendor
Typical
Applications
ALPHATECH Business process
Inc.
reengineering,
service delivery,
manufacturing
systems, military
command & control,
more
Primary
Markets
Military,
manufacturing,
health care,
service industry
AMS:
Semiconductor
Manugistics Used in the
Semiconducto Inc.
component
semiconductor
r
industry for capacity manufacturing
Operating
System(s)
IBM PC: Windows
NT; Sun Workstation:
Solaris, Sun OS
Y2K compliant
versions of operating
systems
planning, factorylevel planning &
floor scheduling.
Win 95/NT
Arena
Systems
Business process
Modeling
analysis, discrete
Corporation event simulation,
modeling
Manufacturing,
logistics, supply
chain, services
@RISK
PALISADE General purpose,
Corporation cost analysis
Financial, oil and Win 95/98, NT, 3.x,
gas, health care Mac OS
AutoMod
AutoSimulat Shop scheduling,
ions
manufacturing,
warehousing and
distribution, work
cell layout
Manufacturing,
aerospace,
automotive,
pharmaceuticals
NT or Win 95
C Library
Numerical General
Algorithms
Group
Finance,
industries,
universities,
laboratories
UNIX and Windows
NT
Call Center
MAESTRO
The Model
Builders
Inc.
Call centers
Windows 95/NT
Call center work
force staffing and
technology
evaluation.
1
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
CB Predictor
Decisioneeri Project likely
ng Inc.
revenue figures and
cash flows, forecast
product demand for
inventory control,
project next year's
sales
Any forecaster or Windows 95, 98, or
NT 4.0
planner, in any
industry, could
use this product.
JobTime Plus JobTime
Used for simulationbased advanced
planning and
scheduling.
Manufacturing
DOS, Windows 3.x,
applications in
Win 95/98, NT Client
and NT Server
the small- to
medium-sized job
shops,
pharmaceuticals,
media
duplication,
assemble to
order, engineer to
order. Can also
be used to
schedule complex
training
campaigns.
COMNET III
CACI
Products
Company
Data
communications,
telecommunications,
network design,
network planning
All
Windows 95/98/NT,
UNIX, HP/UX, SGI
Crystal Ball
Pro
Decisioneeri Business planning
ng Inc.
and analysis,
cost/benefit
analysis, risk
management,
petroleum
exploration
Financial
services, oil and
gas,
pharmaceutical,
environmental
analysis
Windows 95, 98, or
NT4.0
DecisionPro
3.0
Vanguard
Busines financial
Software
modeling, decision
Corporation modeling
Management
consulting,
manufacturing,
legal
Windows 95, 98, NT
Systems
Inc.
NT/95/98
Manufacturing,
warehousing and
distribution
Deneb/Quest Deneb
Manufacturing,
material handling,
discrete material
flow analysis
ExpertFit
Fitting probability
Manufacturing,
Windows 3.1, 95, 98,
distributions to data defense,
NT
communications,
services, health
care
Robotics
Inc.
Averill M.
Law &
Associates
2
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
Extend
Imagine
That Inc.
Engineering design,
scientific analysis,
custom
programming
Extend &
BPR
Imagine
That Inc.
Process modeling, Business,
Windows 95, 98, NT
ABC, workflow, cycle government,
3.1; Mac 68020+,
Power Mac
time, strategic
telecomanalysis, technology munications,
insertion analysis
banking, health
care, education,
financial services
Science,
Windows 95, 98, NT,
engineering,
3.1; Mac 68020+,
Power Mac
electronics,
education, health
care,
environmental
studies,
defense/aerospac
e
Extend & BPR Imagine
&
That Inc.
Manufacturing
General, queing,
manufacturing,
costing analysis,
business, industrial
and commercial
modeling
Extend &
Imagine
Manufacturing That Inc.
Industrial and
Materials
Windows 98, 95, NT
commercial
handling,
3.1, Mac 68020+,
Power Mac
modeling, JIT,
networks,
queueing, costing, manufacturing,
logistics, throughput transportation,
analysis
government/milit
ary, service
industries
Engineering,
science,
manufacturing,
business,
government,
service
industries,
education
Windows 95, 98, NT
3.1; Mac 68020+,
Power Mac
FACTOR/AIM SYMIX/Prits Manufacturing
Manufacturing
Windows 95, NT 4.0
GPSS/H
Wolverine General,
Software
manufacturing,
Corporation transportation,
computing
systems/networks,
mining, logistics,
queuing, etc.
General (not
Win 3.x, 95, 98, NT;
industry-specific) OS/2; DOS; Solaris
GPSS/PC
DOS
Minuteman Simulation for
Manufacturing,
Software
optimization or
transportation,
analysis of design - health care,
general
communications,
general - wide
range of
applications
ker Division decision support
3
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
H/SCHED
Haverly
Systems
Inc.
Refinery scheduling, Petroleum
crude oil scheduling, refining
product blending
scheduling,
distribution
scheduling
Windows 95/98/NT
IBM Supply
Chain
Simulator
IBM
Supply chain
analysis, cost
analysis, inventory
optimization
Windows NT
Distribution,
transportation,
manufacturing
ithink Analyst High
Suited for high-level All markets.
5.1.1
Performanc strategic modeling, Suited to any
e Systems
Inc.
does have discrete
functionality
Windows, Mac
application where
the user seeks to
understand the
behavior of a
system & test
their assumptions
about the impacts
of changes they
may make to
those systems.
MAST
Simulation
Environment
CMS
Research
Inc.
Manufacturing,
machine tool
companies
Windows 95/NT
MedModel
PROMODEL Health care,
Corporation capacity analysis,
facility design,
optimization
Health care
Windows, NT
micro-GPSS
Ingolf Stahl General purpose
discrete events
simulation
Educational
(business and
engineering)
DOS, Windows, Web
systems
Micro Saint
Win 95/98/NT
Micro
General, health
Human
Analysis & care, human factors, factors/ergonomi
Design Inc. manufacturing
cs
MODSIM III
CACI
Products
Company
NAG Fortran Numerical
Library, Mark Algorithms
18
Group
Transportation, air
traffic, military,
logistics, telecommunications
All
Windows, Sun
Solaris, HPUX, SGI
General
Financial,
government &
educational
research
UNIX, Linux, NT, HPUX, AIX, DOS, IRIX,
Solaris, Sun OS
4
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
NAG Fortran
90 Library
Numerical General
Algorithms
Group
Programmers and Linux, NT, HP-UX,
software
AIX, IRIX, Solaris,
Sun OS, other UNIX
developers,
scientists and
engineers
NAG Fortran
SMP Library
Numerical General
Algorithms
Group
Finance,
laboratories,
industry
NAG Parallel
Library
Numerical General
Algorithms
Group
Science,
UNIX, AIX, IRIX,
Solaris, UNICOS
engineering,
financial analysis
& research
Optima 2.5
Micrografx
Inc.
Optima is a process TelecomWindows 3.1, 95, 98,
NT 3.51 or later
analysis application munications,
offering high-end
financial services,
simulation
pharmaceutical,
capabilities. Used for manufacturing,
BPR, TQM, etc.
health care, and
more
PASION32
Stanislaw
Raczynski
Simulation
IRIX, Solaris, UNIX &
NT
Manufacturing,
engineering,
education,
operation
research
Windows 95 and
Borland's Delphi 3
ProcessModel PROMODEL General, process
Manufacturing,
financial call
centers, health
care
Windows, NT
ProModel
PROMODEL Manufacturing,
Corporation facility design,
process
optimization,
material handling,
supply chain
Manufacturing
Windows, NT
Proof
Animation
Wolverine Manufacturing,
Software
material handling,
Corporation transportation,
general
General
Windows 95/98/NT
PS-ENGINE
Prosolvia
AB
PS-ENGINE Plant
Design; PS-ENGINE
Assembly; PSENGINE Layout; PSENGINE Review
Midsized
operations with
their main focus
in discrete
manufacturing
Windows NT
QueGauss
Aptech
Systems
Inc.
General queing
simulation
Engineering,
health care,
financial
DOS, Win NT/95/98
Corporation improvement,
reengineering
5
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
ServiceModel PROMODEL General, service
Windows, NT
Financial, call
centers, airlines,
restaurants
SIGMA
Custom
General discrete
Simulations event simulations;
simulation
education; supports
all modeling
paradigms
Manufacturing
All versions of
Microsoft Windows
factory and
equipment
modeling, health
care, and banking
operations
Silk
ThreadTec
Inc.
Manufacturing,
communications,
general
Manufacturing,
communications
Any Java-compatible
OS
SimGauss
Aptech
Systems
Inc.
General dynamic
simulation of
differential
equations
Engineering,
health care,
financial
DOS, Win NT/95/98
SIMNON 3.0
SSPA
Maritime
Consulting
AB
Differential and
difference EQ;
simulation of
dynamic systems
Technical schools, Windows
developing
industries
SIMPLE++
Tecnomatix Simulation,
Manufacturing,
Windows NT/95,
UNIX
Technologie production planning, transportation,
s Inc.
scheduling,
petro-chemicals,
forecasting,
financial services,
optimization, object- telecomoriented
munications,
programming
automotive,
aerospace,
electronics
SIMPROCESS
CACI
Products
Company
SIMUL8
Windows 95/98/NT
Visual
General purpose
Manufacturing,
Thinking
discrete-event visual distribution,
Internationa simulation tool
health care,
l
business process
reengineering,
financial
SLX
Wolverine Manufacturing,
Software
material handling,
Corporation transportation,
general
Corporation apps., queuing,
costing,
optimization
Business process
All
General
Windows 95/98/NT
Windows 95, 98, NT
6
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
Stat::Fit
Geer
Mountain
Software
Corp.
Distribution Fitting
for general
simulation
applications
Taylor ED
Logistics
Suite
F&H
Manufacturing,
Simulations material handling
Visual
Simulation
Environment
Orca
Computer
Inc.
General
Win 95, 98, NT 4.0
All manufacturing,
health care,
financial, quality
and reliability,
service
industries, etc.
Manufacturing,
distribution,
Win 95, Win NT
warehousing,
financial, service
Generically
Windows 95/98/NT
applicable for use 4.0, Openstep/Mach
in any market.
Unix
WITNESS 9.0 Lanner
Business process
Group Inc. reengineering, plant
layout, scheduling,
queuing, cost
analysis
Manufacturing,
Windows 3.1, 95, NT,
98
automotive,
defense,
pharmaceuticals,
chemicals,
electronics,
hydrocarbon
WorkFlow
Analyzer
Meta
Business process
Software
reengineering,
Corporation workflow analysis
Financial
services,
government
Windows NT/95
7
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
*****************************************************************************
*
Model
Building
Input
via
DistriProbution
gramFitting
ming
Support
Graphic
Model
Construction
Product
Run-time
Debug
Code Reuse
Output (objects, TemAnalysis plates, subSupport
models)
(Interactive
debugger)
y
-
-
y
y
y
AMS:
y
Semiconductor
-
y
y
y
-
Arena
y
y
y
y
y
y
@RISK
-
-
-
-
-
-
AutoMod
y
y
y
y
y
y
C Library
-
y
-
-
y
-
Call Center
MAESTRO
y
-
-
y
-
-
CB Predictor
-
-
-
y
-
-
JobTime Plus
y
y
-
y
y
y
COMNET III
y
-
-
-
-
-
Crystal Ball Pro -
y
y
y
-
y
DecisionPro 3.0 y
y
y
y
y
y
Deneb/Quest
y
y
y
y
y
y
ExpertFit
-
-
y
-
-
-
Extend
y
y
y
y
y
y
Extend & BPR
y
y
y
y
y
y
Extend & BPR & y
Manufacturing
y
y
y
y
y
Extend &
Manufacturing
y
y
y
y
y
y
FACTOR/AIM
y
-
-
y
y
y
GPSS/H
-
y
y
-
-
y
GPSS/PC
-
y
-
y
-
y
H/SCHED
-
y
-
y
y
-
ALPHA/Sim
8
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
IBM Supply
y
Chain Simulator
-
y
y
y
-
ithink Analyst
5.1.1
y
-
-
y
y
y
MAST
Simulation
Environment
-
-
-
-
-
-
MedModel
y
y
y
y
y
y
micro-GPSS
y
y
-
y
-
-
Micro Saint
y
y
-
y
y
y
MODSIM III
y
y
y
y
y
y
NAG Fortran
Library, Mark
18
-
y
-
-
y
-
NAG Fortran 90 Library
y
-
-
y
-
NAG Fortran
SMP Library
-
y
-
y
-
-
NAG Parallel
Library
-
y
-
-
y
-
Optima 2.5
y
n
y
y
y
y
PASION32
y
y
-
y
y
-
ProcessModel
y
-
y
y
y
y
ProModel
y
y
y
y
y
y
Proof
Animation
-
-
-
-
-
-
PS-ENGINE
y
y
y
y
y
-
QueGauss
-
y
-
y
-
-
ServiceModel
y
y
y
y
y
y
SIGMA
y
y
y
y
y
y
Silk
y
y
-
-
y
y
SimGauss
-
y
-
y
-
-
SIMNON 3.0
-
y
-
-
y
-
SIMPLE++
y
y
y
y
y
-
SIMPROCESS
y
y
y
y
y
-
SIMUL8
y
y
-
y
y
y
9
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
SLX
-
y
y
y
y
y
Stat::Fit
-
-
y
-
-
-
Taylor ED
Logistics Suite
y
y
y
y
y
y
Visual
Simulation
Environment
y
y
-
y
y
y
WITNESS 9.0
y
-
-
y
y
y
WorkFlow
Analyzer
y
-
y
y
-
y
10
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
****************************************************************************
**
Product
Is animation
by post
processor/
trace file
Can the
Can animation
output
be viewed
be animated in real-time
List
compatible
animation
software, if any
ALPHA/Sim y
n
n
N/A
y
AMS:
Semiconduc
tor
y
n
Arena
y
y
y
@RISK
n
-
-
AutoMod
y
y
y
C Library
-
-
-
Call Center n
MAESTRO
y
n
CB
Predictor
n
n
n
N/A
JobTime
Plus
y
n
y
Wolverine Proof
COMNET
III
y
y
n
N/A
Crystal Ball n
Pro
n
n
N/A
DecisionPro n
3.0
n
n
Deneb/Que y
st
y
y
ExpertFit
-
-
-
Extend
y
y
y
Proof animation (animation
also built into program)
Extend &
BPR
y
y
y
Proof animation (animation
also built into program)
y
Extend &
BPR &
Manufacturi
ng
y
y
Proof animation (animation
also built into program)
y
Extend &
Manufacturi
ng
y
y
Proof animation (animation
also built into program)
VRML 2.0
11
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
FACTOR/AI y
M
y
n
GPSS/H
y
n
y
Proof animation
GPSS/PC
y
y
y
Proof animation
H/SCHED
y
y
-
IBM Supply y
Chain
Simulator
y
n
y
y
n
y
MAST
Simulation
Environmen
t
y
y
y
n
n
micro-GPSS y
n
y
Micro Saint y
n
n
MODSIM
III
y
y
n
NAG
Fortran
Library,
Mark 18
n
-
-
NAG
Fortran 90
Library
n
-
-
NAG
Fortran SMP
Library
-
-
NAG
Parallel
Library
-
-
-
Optima
2.5
y
y
n
PASION32
y
n
y
ProcessMod y
el
n
n
y
n
n
ithink
Analyst
5.1.1
MedModel
ProModel
N/A - internal feature to
ithink
Proof animation (Wolverine
Software)
12
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
y
y
y
PS-ENGINE y
y
n
-
-
-
ServiceMod y
el
n
n
SIGMA
y
y
y
Silk
y
y
n
SimGauss
n
-
-
SIMNON
3.0
n
n
n
SIMPLE++ y
y
-
SIMPROCES y
S
y
n
SIMUL8
y
y
n
SLX
y
y
y
Stat::Fit
n
n
n
Proof
Animation
QueGauss
This is animation software.
Graphical model generates
standard C code for full
control of output format.
Devise from Division (VR)
Uses proof animation;
supports real-time and
postprocessor mode
y
y
y
All animations, graphics,
and statistics are selfcontained and fully
integrated in the package.
Visual
Simulation
y
Environmen
t
y
n
None
WITNESS
9.0
y
y
-
WorkFlow
Analyzer
y
y
n
Taylor ED
Logistics
Suite
13
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
****************************************************************************
**
Product
ALPHA/Sim
Major New Features
Comments
For spring 1999: Addition
of ports on box nodes
(encapsulation feature to
assist in model reuse).
This release will run on
Windows 95/98, NT &
UNIX (Solaris).
ALPHA/Sim is a general-purpose, discrete-event
simulation tool based on Petri nets. The
graphical modeling environment provides a
simple yet powerful set of model building
blocks, making it easy to learn & use
productively.
AMS:
Transport modeling,
Semiconductor stocker to equipment,
interstep transfers, whole
lot binning/
classification, batching
multiple products,
improved batch sequential
modeling, constrained lot
starts, split lots & setup
changes in burn-in,
planning with engineering
lots
Arena
@RISK
AutoMod
Version 3.5 includes a
Arena Business Edition is the newest member of
project bar & navigation the Arena product family. Designed specifically
tree to help you visualize for process analysts, it features a Visio stencil &
the organization of your flowchart module for defining your process, a
model; model hierarchy & spreadsheet interface for entering data, plus
reports.
submodels; a Visio link
that lets you associate any
Visio shape with an Arena
module; & connector
animation.
Performs risk analysis via Monte Carlo
simulation. Features sensitivity and scenario
analysis. Part of DecisionTools Suite.
Model Communications
AutoSimulations Inc., headquartered in
Module - enables user to Bountiful, Utah, develops, markets & supports
transfer model data
simulation & scheduling software products for
among multiple models or the manufacturing and material handling
with external applications industries. The company has over 1,300
through Windows sockets; installations worldwide.
3-D graphical simulation
software - Enables rapid &
accurate modeling of
complex manfctg. &
material; Photoeye
14
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
C Library
NAG has made major
additions to the
optimization chapter,
improved thread-safety
and Y2K compliance.
A collection of over 300 sophisticated
subroutines for mathematical & statistical
computation.
Call Center
MAESTRO
Quantify the impact of
using one group of agents
with General Skills" vs.
using multiple groups of
agents where each group
has a "Specialized skill."
Call Center MAESTRO allows managers to
quickly 1) analyze the effect of call volume
and/or staffing level on service quality; 2)
visualize the effect of forecasted call volume on
staff utilization, and 3) quantify the benefit of
additional technology.
CB Predictor
100 percent Microsoft
Excel compatibility, bestof-breed forecasting
algorithms, userdefinable confidence
parameters, customizable
forecast reporting engine,
pivot tables for easy data
management
CB Predictor incorporates the most advanced
methods of Time-Series Forecasting (TSF) into
an easy-to-use Microsoft Excel add-in. TSF
techniques analyze historical data to predict
future performance. CB Predictor taps into this
cache & produces forecasts.
JobTime Plus
Year 2000 compliance,
Demand is modeled by defining template
Visual Drag & Drop
production routings that show how to make a
Schedule Board, Theory of given part. The route is a sequence of
Constraints compatibility, operations, specifying work center, setup time,
Backward Pass Simulation, unit cycle time, move time, & other modeling
fields. Built-in features included.
interface to MRP/ERP
systems, material/
inventory constraints
COMNET III
New add-on modules:
application profiler,
distributed software
module, satellite and
mobile module.
COMNET III accurately predicts LAN, WAN, and
enterprise network performance. COMNET III
enables users to reduce risk by experimenting
with diverse network alternatives before
implementing their plans.
Crystal Ball
Pro
This is a suite of products
that includes Crystal Ball,
the Developers Kit, the
Extenders, & OptQuest.
OptQuest is the only
commercially available
tool that offers global
optimization for
spreadsheets under
conditions of uncertainty.
Crystal Ball Pro is a powerful yet easy-to-use
suite of forecasting and risk analysis tools that
enhance spreadsheet modeling. It gives you the
ability to perform Monte Carlo analysis
combined with optimization on your
spreadsheet models.
15
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
DecisionPro
3.0
Version 3.0 adds over 100 DecisionPro is a general-purpose modeling and
new features, giving users simulation tool. It supports Monte Carlo
more control over model simulation, decision tree analysis, linear
presentation and
programming, forecasting, math programming,
and Web-based expert system development.
improving simulation
performance. Simulations
run up to 60 times the
speed of similar
spreadsheet models.
Deneb/Quest AS/RS; Value-added
Full range of CAD translators; import work cell
from other Deneb simulation products.
costing; VRML1.0; AVI,
Read/write to external files and processes.
MPEG movie output;
saving & retrieving groups
of elements; directly
reading CATIA geometry;
Pro/
ENGINEER and
Unigraphics translators
available on PC
ExpertFit
Batch-mode processing,
distribution viewer,
homogeneity testing of
several data sets,
improved histograms with
a scroll bar for
interactively updating the
interval widths, support
for simulation software
products AutoSched AP,
SImPROCESS, SIMUL8 , &
SLX
ExpertFit will automatically & accurately
determine which of 39 probability distributions
best represents a data set in seconds. It will
then put the selected distribution into the
proper format for 33 simulation products.
Extend
The acknowledged
standard for dynamic
modeling and simulation
now features animated
online tutorials that show
you how to build & run
Extend models, fine
control of block location,
optional connection line
animation, progressive
block improvements.
Other powerful features include unlimited layers
of hierarchy, customizable animation, hot links
to Microsoft Office, one-click output analysis,
automatic report generation, userdefinable attributes, interactive model
execution.
16
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
Extend &
BPR
Make the most of new
Provides an integrated financial & operational
features such as animated approach for modeling & evaluating business
online tutorials that show processes. Includes high-level reengineering
how to build and run
capabilities such as batching & cycle timing.
Extend models, optional Plus, built-in activity-based costing & automated
connection line animation, stat. analysis
updated blocks &
numerous new functions
that prove Extend is the
simulation software for
the next millenium.
Extend & BPR The acknowledged
&
standard for dynamic
Manufacturing modeling and simulation
The ultimate in simulation flexibility helps you
maximize your improvement efforts.This
product can help managers reduce costs,
now features animated
manufacturing professionals streamlining
online tutorials that show operations, and engineers designing new
components.
you how to build & run
Extend models, fine
control of block location,
optional connection line
animation, progressive
block improvements.
Extend &
Take advantage of new
Industrial strength modeling system w/
Manufacturing features such as animated customizable interfaces. Contains specialized
online tutorials that show
how to build and run
Extend models, fine
control of block location,
optional connection line
animation, & numerous
new functions.
FACTOR/AIM
GPSS/H
Manufacturing organizations around the world
use AIM for process design, process
improvement, prod. planning, & prod.
scheduling. AIM allows you to build models
without programming and extends its
manufacturing capabilities to include modeling
cost.
Parameterized error
messages
GPSS/PC
H/SCHED
blocks for processing, batching, trans., routing
& other industrial processes. Combines
sophisticaed stat. anlysis with preemption,
reneging & more.
Extremely powerful and scalable generalpurpose simulation language. Maintains
lightning-fast performance even on
large/complicated models. No limits" software."
We plan to release a Windows version of GPSS
based on our GPSS World OS 2 version.
Improves Gantt, time line
and process flow displays;
total integration with
planning & crude assay
management
H/SCHED is a suite of process industry
scheduling applications for refinery, crude oil
and product movement scheduling. H/SCHED
helps to develop alternative plans through the
use of simulation tools, interactive Gantt charts,
& decision tables.
17
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
IBM Supply
Chain
Simulator
Web-based client-server
interface for running
multiple scenarios
It's a solution, not a shrink-wrapped package.
Must be combined with consulting services
and/or training.
ithink Analyst Released 32-bit version
5.1.1
that simulates up to 4
times faster than v 5.0.
Also allows users to open
more than one copy of the
software & added
improved support for
copying & pasting
structure. Added
QuickTime 3.0 support.
MedModel
Built-in optimization,
improved speed
micro-GPSS
WebGPSS, developed in
Streamlined version of GPSS, cutting learning
Java, for doing simulations time in half. Described in Simulation Made
Simple with micro-GPSS
on the Web, with GUI
allowing for building
programs by clicking on
block symbols with new
graphics, in June 1999
Micro Saint
Designed for the healthcare industry, MedModel
has the ability to improve healthcare processes
overnight. Typical applications include facility
redesign, capacity analysis, cost reduction &
staffing plans.
Micro Saint is the only software to include
optimization in the base price product.
MODSIM III
Web-based simulation;
database connectivity;
distributed simulation
NAG Fortran
Library, Mark
18
Mark 18 of the Fortran
NAG provides a robust, reusable library of the
Library has extended the most sought-after numerical routines for
successful math. modeling. Y2K compliant.
areas of ordinary
differential equations,
partial differential
equations, interpolation,
optimization, sparse linear
algebra and OR
NAG Fortran
90 Library
Two new chapters: Matrix The NAG Fortran f190 Library was designed to
& Vector Operation &
capitalize on the increased functionality, power
Multivariate Analysis; new & simplicity of Fortran 90. Fortran 90 offers
modules: Kelvin functions, improved productivity & is compliant with both
Fortran 90 & Fortran 95. Also Y2K compliant.
norms of a matrix,
constrained nonlinear
least squares, and more;
18 new documented
procedures
MODSIM III is the most powerful, objectoriented simulation language in the world. It is
designed for modeling complex and large
systems by software engineers.
18
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
NAG Fortran
SMP Library
Maximization of the
processing potential of
SMP machines in the key
areas of linear algebra,
FFTs & multivariate
statistics.
NAG Parallel
Library
Significant improvements The NAG Parallel Library is a collection of
in routine handling:
parallel routines written in Fortran 77 for the
quadrature, minimizing & solution of numerical & statistical problems
maximizing a function;
targeted primarily at distributed memory
machines. Y2K compliant.
matrix operations &
distribution; eigenvalues &
eigenvectors;
simultaneous linear
equations; linear
equations; least square
problems; sparse linear
algebra;more
Optima 2.5
Web export in HTML and
GIF format; FlowCharter
import filter; hierarchical
component viewer;
intellimouse support
PASION32
Hi-res graphics,
completely Windows 95
ProcessModel New ProcessModel 3.0,
improved interface,
guarantee and
optimization
This numerical library is optimized for use on
Symmetric Multi-Processor (SMP) computers &
contains the full functionality of the NAG Fortran
Library. Y2K compliant.
General purpose, Delphi-based simulation
systems. Supports queuing models, continuous,
ODE, bond graphs, signal flow, animation
ProcessModel is an easy-to-use simulation tool
for improving business processes. This
revolutionary technology allows virtually anyone
to benefit from using simulation. If you can
create a flow chart of the process, you can
improve it with ProcessModel.
ProModel
One-year guarantee;
built-in optimization
Proof
Animation
Real-time capability; AVI General purpose, Windows-based animation
capture; WAV playback
software which can be used with a wide variety
of discrete event simulation software.
ProModel, a leader in the simulation software
industry, offers the only simulation tool with
built-in optimization. Imagine being able to find
solutions to your problems faster than ever
before. Improve manufacturing processes faster
than ever before.
19
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
20
PS-ENGINE
PS-ENGINE is developed
to be a powerful yet easyto-use simulation tool.
Simulation models are
created by using drag and
drop, making work quick
and easy. No
programming is required.
The software is VBA
enabled.
QueGauss
32-bit Windows capability QueGauss extends Gauss to provide queing
simulation. Models written using this extension
have full access to the speed and high-level
functions provided by Gauss. The interactive
nature of Gauss makes it quick and easy to
develop and test models.
ServiceModel
One-year guarantee;
ServiceModel is the only simulation tool
costing, optimization and designed specifically for the service industry.
improved user interface
With this powerful simulation tool, you can
decrease customer waiting times, improve
processes & decrease costs with the click of a
button.
SIGMA
Optional standard process
flowcharting format,
multiple sessions,
simultaneous execution
and replication of models,
development of reusable
simulation tools.
Automatic C code
generation to support
simple spreadsheet
interfaces for
experimentation.
SIGMA was the first Windows simulation lang. &
exclusively uses direct system API calls to
optimize use of memory & execution speed.
Fully interactive model development, animation,
& testing. SIGMA's completely general Event
Graph method is easy to learn
Silk
Java Beans modeling &
animation component;
Java Development Kit
(JDK) 1.2; Java
Foundation classes
(JFK)/Swing support
Silk merges familiar process-oriented modeling
with the Java language for object-oriented,
Internet-capable simulation. Animated
simulation models can be placed on a web site
& executed within standard browser software.
SimGauss
32-bit Windows capability SimGauss extends Gauss to provide dynamic
system simulation. Models written using this
extension have full access to the speed and
high-level functions provided by Gauss. The
interactive nature of Gauss makes it quick and
easy to develop and test models.
PS-ENGINE provides a powerful simulation tool
for the manufacturing industry. With this
product, simulation becomes - for the first time
- a valuable and easy-to-use everyday tool for
the manufacturing industry.
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
SIMNON 3.0
Dev. platform is Win 32;
Double precision
calculation (64 bytes);
external systems to be
connected to Simnon can
be written in Fortran
and/or C++.
SIMPLE++
Faster handling by Block DDE and RPC - server;
built in color syntax; demo available on
www.sspa.se
/simnon
SIMPLE ++, a fully object-oriented, graphical &
integrated discrete events simulation
environment, is used to optimize manufacturing
systems as well as business processes. SIMPLE
++ is also unique in enabling the reuse of the
simulation model for online
SIMPROCESS
Interfaces with Workflow
Management tools, BPR
tools
SIMPROCESS integrates process mapping,
hierarchical, event-driven simulation, and
activity-based costing into a single tool.
SIMUL8
Ability to convert Visio
flow chart diagrams into
simulation models;
enhanced user interface
for Visual Logic Editor,
Excel, VB/VBA; userconfigurable toolbars;
template facility with
password security; plugins for modeling,
transportation object
SIMUL8 offers you the latest in workflow
modeling. Simply build your system by dragging
objects (machines, buffers, conveyors, people,
tools) onto the screen and connecting them.
Learn why industry leaders like Ford are buying
SIMUL8 in packs of 100.
SLX
HLA compatibility
Layered simulation development tool. Can be
customized to fit a wide variety of applications.
Has unique extensibility mechanisms.
Stat::Fit
Distribution Viewer Stat::Fit statistically fits input data to analytical
Allows the user to see how distributions. The Auto::Fit function
parameters affect the
automatically fits continuous and discrete
shapes of distributions;
distributions, providing relative comparisons
Derounding Functions - to between distribution types.
expand rounded data for
greater fitting accuracy
Taylor ED
Logistics Suite
21
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
22
Visual
Simulation
Environment
Fully & truly objectoriented; model
developement from
libraries of reusable
components without
programming; dynamic
object decomposition;
hierarchical model
architecture; graphical &
picture-based; input data
specification; multiple
animation viewers
VSE's toolset includes Editor, Simulator, Output
Analyzer & Teacher. VSE provides state-of-theart object-oriented technology with message
passing, inheritance & encapsulation. Libraries
of reusable model components can be built.
WITNESS 9.0
Hierarchical model
structure; easy-to-reuse
components, power and
free conveyors, part
arrival schedules in
spreadsheet format,
reporting formats,
designer element sets,
tree style" element
selector and long names"
Virtual and easy to use, WITNESS Release 9
offers a powerful and highly flexible engine to
handle the most complex scenarios. The product
provides the capability to model virtually any
working environment and inexpensively perform
what if" analyses."
WorkFlow
Analyzer
Interface to FileNet Visual
Workflow, Plexus FloWare,
DST Systems AWD; model
repository and MetaWeb
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
ANNEXE B :
23
Sites INTERNET de progiciels de simulation
Avec une breve decsription du progiciel
Arena
Arena simulation software creates animated computer models that accurately
represent virtually any system. First released in 1993, Arena is a flexible and
powerful tool. It has an object-oriented design and the unique ability to be tailored
to any application area. Arena also is very easy to use; with its point and click
interface and fill in the blank dialogue boxes, there is never a need for
programming.
http://www.sm.com/arena.htm
Platforms: Win95, WinNT
AweSim!
AweSim! a totally new general purpose simulation system, designed and developed
to utilize the latest in simulation and Windows technology. AweSim!makes
simulation easy. Built on over 20 years of simulation experience it predicts the
performance of complex systems. AweSim! works and can work for you!
AweSim! is the first Windows simulation product to support multiple concurrent
animations from a single model. See entities flow over a network diagram in one
window, while another window shows a realistic animation of the model's status.
And another window shows the key performance measures - updated as the
simulation executes.
http://www.wintek.com/pcorp/awesim.htm
Platforms: Win3.1, Win95, WinNT
Extend
Extend is a dynamic, iconic simulation environment with a built-in development
system for extensibility. It enables you to simulate discrete event, continuous, and
combined discrete event/continuous processes and systems. Virtually anything you
could possibly imagine can easily be built by using Extend's libraries of pre-built
blocks. No programming is necessary; however, you may if you so desire.
Everything you need for model building is here ... the authoring environment and
development system are built in.
http://www.imaginethatinc.com/aboutext.htm
Platforms: Mac Win3.1, Win95, WinNT
Extend+Manufacturing
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
24
Extend+BPR is combines the Extend program with a manufacturing process model
that gives you a tool to make significant changes in your industrial or commercial
operation. This dynamic modeling tool assists in the prediction of system
bottlenecks, determination of buffer lengths, build times, and process timing so
costs can be justified before resources are committed, options can be analyzed, and
operating procedures documented. Extend+Manufacturing has been designed
specifically for Industrial Engineers, Operations Researchers, and Manufacturing
Analysts for operations improvement, information processing, service industries,
distribution systems, material handling, transportation systems, and most other
discrete event processes.
GPSS/H Professional
GPSS/H is a general-purpose tool for building models of discreet-event systems.
Unlike some simulation software which forces you to fit your application into a rigid,
inflexible framework, GPSS/H is versatile enough to handle the problems and
intricacies of a wide variety of systems. GPSS/H gives you the building blocks to
make your simulation as detailed as you want. A GPSS/H model is easy to use,
modify, maintain, and transfer to other platforms.
Parallel Performance http://www.ppgsoft.com/wo_h.html
Platforms: MS-DOS, Win3.1
GPSS/PC
GPSS/PC is an efficient implementation of the popular simulation language GPSS
(General Purpose Simulation System). GPSS/PC is more than a programming
language, it is a complete simulation environment specifically designed for
interactive use on today's high speed microprocessors. The program uses graphics
and animation to model various types of simulation environments.
Platforms: MS-DOS, Win3.1
iThink
iThink, which is an adaptation of STELLA, is a powerful and flexible package for
building and simulating business and organizational processes. The software, which
includes extensive conceptual and technical documentation, has emerged as a key
tool for addressing business issues of all types, ranging from strategic planning to
business process re-engineering.
High Performance http://www.hps-inc.com/ithink.html
Platforms: Mac, Win3.1
MAST
MAST is a software tool designed, developed and implemented for the study of
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
25
flexibility. It combines state-of-the-art manufacturing models using rough-cut
analysis (also known as rapid modeling) with simulation and color graphic
animation. MAST enables you to evaluate manufacturing capacity, identify
bottlenecks and answer "what if" questions such as the effects of new production
requirements or changes in labor allocations. All this and more can be achieved
without programming, modeling or text editing.
CMS Research, Inc. http://www.powernetonline.com/~cmsres/mast.htm
Platforms: Win95, Win98, WinNT
MODSIM III
The Modular Simulation language, MODSIM III, is an object oriented, strongly
typed, general purpose, high level programming language. MODSIM III provides
both object oriented programming and discrete event simulation capabilities in one
language. It is used to build large, process-based simulation models with modular
and object oriented development techniques.
CACI http://www.caciasl.com/modsim.html
SIMPROCESS
SIMPROCESS is a hierarchical and integrated process simulation tool that radically
improves your productivity for process modeling and analysis. SIMPROCESS is
designed for BPR and IT professionals of industrial and service enterprises who
need to reduce the time and risk it takes to service customers, fulfill demand, and
develop new products. Unlike other tools, SIMPROCESS integrates process
mapping, hierarchical event-driven simulation, and activity-based costing into a
single tool.
CACI http://www.caciasl.com/simprocess.html
SIMSCRIPT II.5
SIMSCRIPT II.5 is a powerful, free-form, English-like simulation language
designed to greatly simplify writing programs for simulation modelling. Programs
written in SIMSCRIPT II.5 are easily read and maintained. They are accurate,
efficient, and generate results which are acceptable to users. Unlike other
simulation programming languages, SIMSCRIPT II.5 requires no coding in other
languages. SIMSCRIPT II.5 has been fully supported for over 33 years.
CACI http://www.caciasl.com/simscript.html
Platforms: Win95, WinNT, UNIX
SIMUL8
SIMUL8 is a Windows based visual discrete event simulation software tool that
provides bottom line performance measures and insights into how any configuration
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
26
of machines and people will perform in combination with one another. While
SIMUL8 is very easy to use it also provides all the features that even simulation
specialists require.
Visual Thinking International
http://www.visualt.com/sim8home.htm
Platforms: Win95, WinNT
SLAM II
SLAM II is a simulation program used in research at various universities. It is being
used at the University of Flordia and the University of Cincinnati.
Pritsker Corporation
http://www.wintek.com/pcorp/
http://www.circa.ufl.edu/circa/handouts/vms/slam2/slam2.html
Platforms: Mac, Win3.1, Win95, WinNT, UNIX
STELLA
STELLA is a powerful and flexible package for building and simulating models of
dynamic systems and processes. Using a simple set of building block icons, you can
construct a map of a process or issue of any kind. The diagram automatically
generates equations, used for simulation, allowing you to bring your map to life.
Output can be viewed as graphs, tables, diagram animation or QuickTime movies.
Multi-run sensitivity analysis allows you to explore a variety of what-if scenarios as
you (or your students) explore the interdependencies of the system under scrutiny
High Performance
http://www.hps-inc.com/stella.html
Platforms: Mac, Win3.1
Taylor II
Taylor II is a full capability discrete event simulation Package. It includes advanced
statistical capability for input analysis and the ability to design experiments for
multiple replication/scenario analysis.
Three levels of 2D animation and true 3D wire frame animation and true 3D shaded
solids modeling (with light source definition) for unsurpassed model presentation.
True XYZ representation enabling you to model and animate elements,
transporters, conveyors, and parts at any XYZ point location. Conveyors and paths
can have rounded, angled, or inclined movement. Hierarchical modeling which
allows you to save whole models as clusters which can be deleted, moved, or scaled
as a single object.
Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna.
F&H Simulations
http://www.taylorii.com/
27
