Modelisation and Simulation Sur Ordinate PDF

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

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

• 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.

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

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)

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

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. En
simulation, on s’attache généralement a distinguer les types de modèles suivants :
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

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.

2.3.2 Expérimentation directe et indirecte
Fig 3(a) Expérimentation directe et indirecte


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

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

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.
T
2 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.
T
3 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).
T
4 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

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 sous-
systè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

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é

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

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 :
Fixes : 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é...)
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

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


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


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 discrets-
continus".
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

(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)

: Event scheduling, Next Event
2)
: Activity Scanning
3) : 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
niveau 1 : Correspond au programme de contrôle de la simulation appelé aussi
S exécutif ou noyau
niveau 2 : Correspond aux opérations décrivant la dynamique du système
simulé. Du point de vue de l’utilisateur, ce niveau constitue le
S modèle de simulation proprement dit
niveau 3 : 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


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.

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.

Evénement : Arrivée_Client
Planifier ou prévoir la prochaine Arrivée ;
Si le SERVEUR est Occupé
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).

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 */
z ETAT_SERVEUR ← Libre
Fin
Fin événement 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.

Fig7 : Organigramme de la routine Arrivée_Client


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

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 :

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
On va supposer les dates d’arrivée des clients et la durée de service de chaque

client connues et sont :

Numéro Client Date Arrivée Durée de Service

1 3.2 3.8
2 10.9 3.5
3 13.2 4.2
4 14.8 3.1
5 17.7 2.4
6 19.8 4.3
7 21.5 2.7
8 26.3 2.1
9 32.1 2.5
10 36.6 3.4
Numéro Date Date Début Date Fin Service Temps Temps passé
Client Arrivée Service (4) = (3) + d’attente Dans le système
(1) (2) (3) Durée service (5) = (3) - (2) (6) = (4) - (2)
1 3.2 3.2 7.0 0.0 3.8
2 10.9 10.9 14.4 0.0 3.5
3 13.2 14.4 18.6 1.2 5.4
4 14.8 18.6 21.7 3.8 6.9
5 17.7 21.7 24.1 4.0 6.4
6 19.8 24.1 28.4 4.3 8.6
7 21.5 28.4 31.1 6.9 9.6
8 26.3 31.1 33.2 4.8 6.9
9 32.1 33.2 35.7 1.1 3.6
10 36.6 36.6 40.0 0.0 3.4
Total : 26.1 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.

Date Numéro Type Nombre Nombre Etat du Temps

Evénement Client Evénement dans la file dans Serveur Libre du
le système Serveur
0.0 - début 0 0 libre -
3.2 1 Arrivée 0 1 occupé 3.2
7.0 1 Départ 0 0 libre 0
13.2 3 Arrivée 1 2 occupé 0
14.4 2 Départ 0 1 occupé 0
Tot : 17 Tot : 33 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%

Taille Max de la file :3
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

é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: défini par une collection de variables d'état décrivant l'état du
système à a un temps particulier.
L'horloge de la simulation: variable indiquant la valeur courante du temps de la
simulation.
La liste des événements: Une liste qui contient les dates d'occurrence des événement
devant avoir lieu dans le futur.
Des compteurs Variables utilisées pour collecter des informations
statistiques: statistiques sur les performances du système.
La routine d'initialisation. Sous programme servant a initialiser le modèle de simulation
au temps zéro.
Routine de Gestion du sous programme qui détermine le prochain événement a
temps (controle du temps): partir de la liste des événements et intialise l'horloge de
simulation avec le date d’occurrence de cet événement
courant.
Routines associées aux sous programme qui met à jour l'état du système quand un
événements: type particulier d'événement se produit (il y a une routine
d'événement pour chaque type d'événement).
bibliothèque de routines ensemble de sous programmes utilisés pour générer des
utilitaires: variables aléatoires identifées comme faisant partie du
modèle de simulation.
Générateur des résultats: 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.
Le programme principal: 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

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 pQpUDWLRQ GH YDULDEOHV
JpQpUDWLRQ SURFKDLQV HYHQHPHQWV DOpDWRLUH V
HW DMRXWHU D OD OLVWH
# 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

é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


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:

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.

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é)

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 :

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 Les questions auxquelles devra apporter une réponse l’étude par simulation
qu’on veut mener
z Le personnel qui sera requis
z Le matériel et logiciel informatique
z Les divers scénarios qu’on veut investiguer, les sorties attendues,
z Les coûts de l’étude ainsi que les temps requis
z 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

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)


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 Le modérateur : ou chef de groupe

T Le concepteur : qui a développé le modèle conceptuel
T Le programmeur : qui a traduit le M.C. en programme
T Le testeur : 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.
%) # $ & $$


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

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 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...)
z 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 Faire une Collecte des données sur les temps séparant les arrivées de
clients.
T Effectuer un test statistique pour s’assurer que l’hypothèse

d’indépendance de cette variable est acceptable.
T Estimer le paramètre de la distribution supposée (exponentielle dont le

paramètre est une moyenne).
T 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.

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
(3mn) est à retenir ou à rejeter. (Voir aussi le test du χ )
2
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

• 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.

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 L’état initial ou de début de la simulation (file vide ou non, serveurs libres

ou occupés,...)
T Le temps à partir duquel on commence la collecte des statistiques
T La durée de la simulation
T 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


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

‘‘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 Le volume de données disponibles

T Les données disponibles sont réelles ou de simples estimations
T 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

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

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 Chi-
Deux 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 Chi-
deux). 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 fréquences de panne observées

0.0 < x ≤ 1.0 27
1.0 < x ≤ 2.0 13
2.0 < x ≤ 3.0 31
3.0 < x ≤ 4.0 18
4.0 < x ≤ 8.0 11
Total 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 :


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

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

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.

.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

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.


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


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

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 3D\V 'DWH

6,06&5,37 USA 1963
6,08/$ Norvège 1966
*366 USA 1968
*$63 USA 1974
4*(57 USA 1977


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


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

/9(4 '(3$57 6(59(54

1/9(4
/ 6723

7(67
$'9$1&(

59(;32

6723 6(59(5
5(/($6(

7(50,1$7(

La traduction de ce diagramme sous forme de programme GPSS (modèle de simulation

operationnel) conduit au programme listé ci-dessous :


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 .


! "
" " " "#$ $ $
SERVER 0.516 1000 0.523 AVAIL
48(8( 0$;,080 $9(5$*( 727$/ =(52 3(5&(17 $9(5$*( $9(5$*( 47$%/( &855(17
&217(176 &217(176 (175,(6 (175,(6 =(526 7,0(81,7 7,0(81,7 180%(5 &217(176
SERVERQ 8 0.605 1000 454 45.4 0.614 1.124 0
" " % " %

" "
1 OFF 100000 101001 1001 0.71
2 OFF 200000 200999 999 0.69
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


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


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

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.

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

6,08/$7,21 352-(&7 EXEMPLE %< ..................
'$7( 01/01/1999 581 180%(5 1 2) 1
&855(17 7,0( .9171E+03
67$7,67,&$/ $55$<6 &/($5(' $7 7,0( OOOOE+00
67$7,67,&6 )25 9$5,$%/(6 %$6(' 21 2%6(59$7,21
0($1 67$1'$5' &2()) 2) 0,1,080 0$;,080 12 2)

9$/8( '(9,$7,21 9$5,$7,21 9$/8( 9$/8( 2%6
'(/$< ,1 48(8( .608E+00 .100E+01 .165E+01 .000E+00 .589E+01
),/( 67$7,67,&6
),/( $9(5$*( 67$1'$5' 0$;,080 &855(17 $9(5$*(

180%(5 /$%(/7<3( /(1*7+ '(9,$7,21 /(1*7+ /(1*7+ :$,7 7,0(
1 AWAIT .662 1.354 9 0 .608
2 CALENDAR 1.555 .497 3 2 .285
5(6285&( 67$7,67,&6
5(6285&( 5(6285&( &855(17 $9(5$*( 67$1'$5' 0$;,080 &855(17
180%(5 /$%(/ &$3$&,7< 87,/ '(9,$7,21 87,/ 87,/
1 SERVER 1 .55 .497 1 1
5(6285&( 5(6285&( &855(17 $9(5$*( 0,1,080 0$;,080

180%(5 /$%(/ $9$,/$%/( $9$,/$%/( $9$,/$%/( $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,

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

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. générer des arrivées de clients
48(8( attente du serveur
6(,=( 6(59(5 demande d’allocation du serveur
7$//< ,17 enregistrer le temps d’attente dans la file
&2817 comptabiliser le nombre d’attentes
'(/$< (; occuper le serveur pendant une durée
5(/($6( 6(59(5 ',6326( libérer le serveur et quitter le système
(1'

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

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 .50658 1.14931 .00000 10.0000 978.28
2 SERVER UTIL. .51872 .49965 .00000 1.00000 978.28

-------------
%&'& &&
----------------------------------------------
1 CUSTOMER DELAYS 1000 1000
Figure 3.9 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

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

des résultats ou l’ animation graphique de la simulation.


/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

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).

)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]


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

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,0$1 6,06&5,37 6/$0
7UDQVDFWLRQ (QWLW\ 3URFHVV (QWLW\ Notion utilisée pour désigner

tout objet pouvant subir des
services
)DFLOLWLHV 5HVRXUFH 5HVRXUFH 5HVRXUFH Notion utilisée pour désigner
6WRUDJHV tout objet pouvant exécuter un
service
&KDLQ )LOH 6HW )LOH Structure utilisée pour gérer les
objets en attente d'un service
*(1(5$7( &5($7( $&7,9$7( &5($7( Primitive d'injection d'entités
$Q dans le système
Séquence de primitives
6(,=( 6(,=( 5(48(67 $:$,7 modélisant une opération sur
une ressource :
$'9$1&( '(/$< :25. $&7,9,7<
5($/($6( 5($/($6( 5(/,148,6+ )5(( ....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

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 Critère
1 Interface H/M conviviale
2 Possibilité de disposer d’une B.D. pour organiser les données
3 Outil de mise au point (Debogueur)
4 Interaction Via une Souris
5 Section d’assistance dans la documentation du L.S.
6 Sauvegarde des modèles de simulation
7 Sauvegarde des Résultats
8 Entrée des données et des commandes par clavier
9 Librairie de modules réutilisables
10 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

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élisation-
simulation. 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 à

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

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

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.

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

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

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 questions-
ré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

à 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

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

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
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 sous-
programmes. 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.
Construction du Modèle
BLOCKS ou Editeur de Texte
MODEL
1
Fichier
Modèle
4
2 Fichier SIMAN Rapport

LINK Programme Exécution Standard
Fichier
Experiment Fichier
Résultats
3
EXPERIMENT OUTPUT 5
Analyse,..
Construction du Cadre Rapports

d’Expérimentation
(Editeur de Texte)
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.)
•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(.).
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 Description
A(I) Attribut Numéro I de l’entité active
M Attribut de l’entité représentant son numéro de la STATION actuelle
Variables Description
(*)
Utilisateurs Toutes ces variables doivent être initialisées par l’utilisateur
X(I) Variabale globale I
S(I) Variable d’état I (Pour modèles continus)
D(I) Dérivée de la Variable d’état I (Pour modèles continus)
J Variable entière de type Indice
P(IP,IS) Valeur du paramètre numéro IP dans l’ensemble des Paramètres
numéro IS
Variables Description
(*)
Système Toutes ces variables peuvent être utilisées mais sont mises à jour par SIMAN
TNOW Temps courant de la simulation
NE(I) Nombre d’entités en route vers la Station I
NQ(I) Nombre d’entités dans la file d’attente I
NC(I) Valeur courante du compteur I
NR(I) Nombre d’unités occupées de la Ressource numéro I
NT(I) Nombre d’unités occupées du Transporteur I
LC(I) Longueur des cellules occupées du Convoyeur I
MR(I) Nombre d’unités de la ressource I
MT(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
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
NOM SYMBOLE FONCTION
Ce bloc permet de modéliser une

OPERATION 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 sous-
programme é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 transfert d'entités entre les stations
par un moyen de manutention.
Ce bloc permet de modéliser toute

HOLD 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
Ce bloc permet de modéliser une file

QUEUE 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

STATION entre les composants du modèle et le
système de transport ou de
manutention.
Cette possibilité n'existe pas dans

SLAM.
Ce bloc permet de faire un routage

BRANCH selon une condition, une probabilité
ou déterministe.
Une branche matérialise don le
chemin que doit emprunter une entité.
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
PICKQ choisie.
Ce bloc permet de sélectionner une

ressource parmi plusieurs associées à
des blocs OPERATION.
SELECT Il y a une analogie avec une des

fonctions du noeud SELECT de SLAM.
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
QPICK T critère que l'on doit spécifier.
T
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
MATCH
T possèdent la même valeur d’un
attribut dans chacune des file
T d’attente. Il est analogue au noeud
MATCH de SLAM.
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
FONCTIONS
DETECT Détecter les événements de changement
d'état pour le cas de systèmes continus
EVENT Déclencher un événement spécifié
GENERALES
FINDJ Rechercher la valeur de l'index J
satisfaisant une certaine condition
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
Prélever (collecter) une observation sur
Statistiques TALLY une valeur spécifiée
Nom Description
ASSIGN 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é
pour
SYSTEME DE HALT Mettre l'état d'un TRANSPORTEUR

spécifié à INACTIF
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
Libérer un nombre spécifié d'unités d'une

Ressources RELEASE ressource
COPY Copier les attributs d'une entité dans une

Fonctions file d'attente spécifiée
pour
SEARCH Chercher une file d'attente pour une

Files d'Attente entité satisfaisant une condition spécifiée
REMOVE Supprimer une entité d'une file d'attente

spécifiée
5.2.2 Fonctions offertes par le bloc HOLD
Nom Description
SCAN Retarder l'entité jusqu'à ce qu'une

Fonctions condition spécifiée soit satisfaite.
Conditionnelles WAIT Retarder l'entité jusqu'à ce qu'un signal

soit reçu depuis un bloc SIGNAL.
SCAN Retarder l'entité jusqu'à ce qu'une

Fonctions condition spécifiée soit satisfaite.
Conditionnelles 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

Fonctions requis de cellules du convoyeur soit
disponible et alloué à l'entité.
de
Manutention 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

Fonctions spécifié d'entité soit présent dans la file
d'attente qui précède. Une fois présentes,
pour 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.
Ensemble GROUP Retarder l'entité jusqu'à ce qu'un nombre

ou spécifié d'entité soit présent dans la file
Groupe 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.
5.2.3 Fonctions offertes par le bloc TRANSFERT
Nom Description
FONCTIONS CONVEY Transporter une entité à l'aide d'un

convoyeur vers une station précise. Le
DE temps de convoyage est déterminé par la
distance entre les stations et la vitesse du
convoyeur.
MANUTENTION ROUTE Router une entité vers une station précise.

Le temps de routage est spécifié comme
opérande
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

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 ↓: 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
2. 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

A
(appelé MARK symbol dans SIMAN) qui a l'allure suivante :
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é.
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 & Commentaires ;

Connecteur
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
DISPOSE : mot clé qui indique que les entités sortant du bloc
sont détruites
z
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é
z
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.
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.
Diagramme Explications
Création des pièces et Marquage

CREATE
1 du temps d’arrivée dans l’attribut 1
UN(1,1)
Attendre la machine de contrôle
dans la file 1
CONTROLE 1
Passer sur la machine de contrôle

SEIZE
MACHINE1 Rester sur la machine de contrôle
pendant une durée égale au temps
de service : généré à partir d’une
DELAY distribution uniforme.
UN(2,1)
Libérer la machine de contrôle
RELEASE Selon le résultat du contrôle se

MACHINE1 brancher avec une probabilité de
0.15 vers la machine de
rectification et avec une probabilité
1 de 0.85 vers la sortie.
WITH, .15 MACHINE2
Attendre la machine de
WITH, .85 QUITTER
rectification dans la file 2
2 Passer sur la machine de

RECTIFIE rectification
SEIZE Rester sur la machine de

MACHINE2 rectification pendant une durée
égale au temps de rectification
(généré à partir d’une distribution
DELAY uniforme)
UN(3,1)
Libérer la machine de rectification
et Retourner à la machine de
RELEASE contrôle
MACHINE2
MACHINE1 Collecter des statistiques sur le

temps passé par les entités dans le
⊥ système.
TALLY
QUITTER
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).
7.2 Programme SIMAN correspondant au diagramme

BEGIN;
CREATE : UN( 1,1) : MARK(1) ; Arrivée des pièces

CONTROLE QUEUE ,1; Attente Machine1
SEIZE : MACHINE1;Acquérir Machine1
DELAY : UN( 2,1) ; Occuper Machine1 pendant
un temps = à la durée du contrôle
RELEASE : MACHINE1; Libérer Machine1
BRANCH, 1 ; ALLER Soit vers le bloc dont Label est :
WITH , .15, RECTIFIE ; RECTIFIE avec une Probabilité= 0.15
WITH , .85, QUITTER ; QUITTER avec une Probabilité= 0.85
RECTIFIE QUEUE , 2; Attente Machine2
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
QUITTER TALLY : 1 , INT(1) : DISPOSE; Collecter des statistiques sur le
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
- 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 : Utilitaire pour l'édition interactive de diagrammes à

blocs
z MODEL.EXE : Utilitaire pour compilation d'un modèle ; produit
comme résultat un fichier
z EXMPT.EXE : Utilitaire pour compilation d'un cadre

d'expérimentation ; produit comme résultat un fichier
z LINKER.EXE : 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)
z SIMAN.EXE : 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.
z OUTPT.EXE : 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 macro-
instructions 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.
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.

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é Modèle
LINKER 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.
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.
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.
FORMAT INSTRUCTION: PROJECT
PROJECT , TITRE , AUTEUR , MOIS/JOUR/ANNEERE ;
OPERANDE TYPE VALEUR DEFAUT
TITRE Titre du projet (20 caractères MAx.) des Blancs
AUTEUR Nom de l'auteur (20 caractères MAx.) des Blancs
MOIS/JOUR/ANNNE date 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 ;
MAXENT Nombre maximum d'entités qui peuvent 0

être présentes dans le système en même temps (entier)
MAXATRB Nombre maximum d'attributs associés à une 0

entité (entier)
NFILES Nombre de file d'attentes dans le système (entier) 0
NSTAT Nombre de stations dans le système (entier) 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).
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...............;
N Numéro du régistre (entier) Néant
ID Identificateur (16 caractères Max.) des Blancs
UNITE Numéro de l'unité périphérique sur laquelle Pas d'observ.

enregistrer les observations individuelles Individuelles
(Incrémentée à chaque exécution )
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).
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...............;
N Numéro du compteur (entier) Néant
LIMITE La valeur limite du compteur qui sert pour ∞

stopper la simulation.
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).
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 ............ ;
Numéro Numéro de la ressource (entier) Néant

Nom Nom de la ressource (8 caractères Max.) Néant
Capacité Nombre initial d'unités (entier) 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.
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;
NRUNS Nombre de simulations à faire (entier) 1

Tdébut Temps début de la première simulation (Réel) 0.0
TMaxRun Durée Maximale de chaque simulation (Réel) ∞
INITSYS Initialisation du système (YES ou NO) YES
INITSTAT IGNORER les Observations (YES ou NO) YES
EXEMPLES : 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.
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 Paramètr

es
P1 P2 P3
• Exponentielle EX Moyenne • •
• Erlang ER Moy. Exponentielle K •
• Uniforme UN Minimum Maximum •
• Triangulaire TR Minimum Mode Minimum
• Normale RN Moyenne Ecart type •
• Lognormal RL Moyenne Ecart type •
• Gamma GA beta alpha •
• Beta BE theta phi •
• Poisson NP Moyenne • •
• Weibull WE beta alpha •
• Distribution Empirique DP Probabilité Cumuléé ,Valeur........
• Constante CO constante • •
FORMAT INSTRUCTION: PARAMETERS
PARAMETERS : N,P, ....P : repeats...............;
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.
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 TYPE VALEUR

DEFAUT
N Numéro de la file d'attente ou ensemble Néant

de files auxquelles appliquer la règle spécifiée
REGLE Règle de gestion : FIFO , LIFO , LVF(K) ou HVF(K) Néant

K étant un entier
EXEMPLES : 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.
9.9 Instruction DSTAT
Utilisée pour obtenir des statistiques liées au paramètre temps (Time-

persistent) 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...............;
N Numéro associé à la statistique(entier) Néant
DVAR Nom de la variable pour laquelle on veut Néant

collecter des statistiques liées au temps
[X(K), NE(K) , NQ(K) , NR(K), NT(K), LC(K), MR(K) ou MT(K) ]

(entête sur le rapport de sortie)
UNITE Numéro de l'unité périphérique sur laquelle Pas de

enregistrer chaque changement de la variable Sauvegarde
Unité est incrémenté à chaque nouvelle exécution)
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.
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;
Tdébut Temps de début de la trace 0.0

(Relatif au temps de début de la simulation)
Tfin Temps de fin de la trace ∞

(Relatif au temps de début de la simulation)
Condition Condition pour exécuter la trace

(si Condition = vrai tracer sinon rien)
Var Nom de la variable ou attribut à tracer Pas de variables

(maximum 4 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.
(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 1

Entier > 0 ou X(K) k étant 1 entier
TBC Time Between création: durée entre ∞

les créations (expression)
MC Nombre maximum d'entités à créer ∞
EXEMPLES :
CREATE 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
EX(1,1) les créations suit une distribution exponentielle. Le
nombre maximum de créations est infini.
CREATE , EX(1,1);
Le nombre d'entités à créer à chaque fois est de X(1).

CREATE, 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
UN(2,1) , 12 uniforme. Le nombre maximum de créations est de
est de 12.
CREATE , X(1) : UN(2,1), 12;
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.
QUEUE, IFL , QC , LBALK : MODIFIERS ;
IFL Numéro de la file Néant

(entier : K , M+K ou M-K )
QC Capacité de la file (A(I), X(I) ou I) ∞
LABLK Label du bloc vers lequel diriger Détruire l'entité

les entités si la file est pleine
EXEMPLES :
1 Le numéro de la file est 1. Sa capacité est infinie.
QUEUE, 1 ;
Le numéro de la file est 1 et sa capacité est de 3. Les
1, 3 entités qui arriveront alors que la file est pleine seront
détruites.
QUEUE, 1, 3 ;
Le numéro de la file est 1 et sa capacité est fournie
1, X(3) par de la valeur courante de la variable SIMAN X(3).
VERIF Les entités qui arriveront alors que la file est pleine
QUEUE, 1, X(3), VERIF ; seront dirigées vers le bloc ayant pour étiquette
VERIF.
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é.
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).
SEIZE , PRIOR : RNAME , NR : MODIFIERS ;
PRIOR Priorité d’allocation de la Ressource 1

(A(I) , X(I) , ou I : I étant un entier)
RNAME Nom de la Ressource Néant
NR Nombre d'unités à allouer 1
(A(I), X(I) ou I : I est un entier)
EXEMPLES :
1 Les entités attendent dans la file

n°1 et demandent d'allouer 2
unités de la ressource ayant
SEIZE SEIZE : OPERATOR, 2 ; pour nom : OPERATOR
OPERATOR, 2
1 Les entités attendent dans la file

n°1 et demandent d'allouer 1
unité de la ressource ayant pour
SEIZE, A(1) nom : SERVEUR. La priorité du
SEIZE , A(1) : SERVEUR ;
bloc SEIZE par rapport aux
SERVEUR autres est égale à la valeur de
l'attribut A(1) de la première
entité de la file 1.
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.
RELEASE : RNAME , NR : MODIFIERS ;
RNAME Nom de la Ressource Néant

(voir instruction RESOURCE du
cadre d'expérimentation)
NR Nombre d'unités à libérer 1

(A(I), X(I) ou I : I est un entier)
EXEMPLES :
Une unité de la ressource

RELEASE
ayant pour nom SERVEUR
RELEASE : SERVEUR; est libérée.
SERVEUR
RELEASE
5 unités de la ressource
OPERATOR,5 RELEASE : OPERATOR , 5;
ayant pour nom OPERATOR
est libérée.
RELEASE Le nombre d'unités de la

ressource ayant pour nom
DISQUE, A(1) RELEASE : DISQUE, A(1) ; DISQUE qui sont libérées
est spécifié dans l'attribut
n° 1 de l'entité (A(1)).
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
ASSIGN : VAR = valeur : MODIFIERS ;
VAR Nom de la variable Néant

A(I), X(I), S(I) , D(I) , P(I,K), J, M
valeur une expression Néant
EXEMPLES :
ASSIGN
La valeur 3 est affecté au premier attribut (N° 1)
de chaque entité arrivant au bloc ASSIGN. A(1) = 3
ASSIGN : A(1) = 3;
La valeur qui sera affectée à la variable X(1) ASSIGN

sera calculée en générant une valeur à partir
X(1)= EX(1,1) +0.2
d'une distribution exponentielle à laquelle on
additionne 0.2. le résultat est affecté à X(1)
ASSIGN : X(1) = EX(1,1) + 0.2;

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).
DELAY : Durée : MODIFIERS ;
Durée une expression spécifiant la durée 0.0

(constante, expression arithmétique
impliquant des variables SIMAN)
EXEMPLES :
La durée est la valeur de l'attribut A(1) de
DELAY l'entité arrivant au bloc. Cette valeur aura été
par exemple affectée à l'attribut A(1) dans un
A(1) 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;

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.
TALLY : N , VAR : MODIFIERS ;
N Entier représente le numéro Néant

d'un registre
VAR La valeur à collecter Néant
(Expression , INT(K) ou BET(K) )
INT(K) : Collecte de TNOW - A(K)

BET(K) : Collecte de TNOW - X(K)
EXEMPLES :
INT signifie INTERVAL et consiste à collecter la
TALLY 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
TALLY : 1, INT(2) ; l'entité, TNOW - A(2) représente alors le temps mis
par l'entité pour aller du bloc ou on a fait le marquage
jusqu'au bloc TALLY.
TALLY BET signifie BETWEEN et consiste à collecter la

valeur calculée TNOW - X(1) à chaque arrivée d'une
2 , BET(1)
entité au bloc et initialisation de X(1) avec TNOW. La
collecte se fera dans le registre ayant pour numéro
TALLY : 2, BET(1) ; 2. Les valeurs collectées représente les temps entre
les arrivées successives au bloc.
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.
COUNT : N , INC : MODIFIERS ;
N Entier représente le numéro Néant

d'un registre (compteur)
INC Le pas d'incrémentation 1
(A(I) , X(I) ou I )
EXEMPLES :
Le compteur 1 est incrémenté de 1 chaque fois qu'une
entité arrive au bloc. Si après incrémentation , la
COUNT
valeur du compteur est > ou = à la limite du
1,1 compteur (spécifiée dans l'Experimental Frame), la
simulation est arrêté.
COUNT : 1, 1 ;
Le compteur M est incrémenté avec A(1) . Si après
incrémentation , la valeur du compteur est > ou = à la
COUNT limite du compteur (spécifiée dans l'Experimental
Frame), la simulation est arrêté.
M , A(1)
COUNT : M, A(1) ;
BLOC : BRANCH (branchement vers un bloc non séquentiel)
SYMBOLE GRAPHIQUE MAXTAKE
IF, Cond Label1

With, P Label2
ELSE ou ALWAYS 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 : BRANCH , MAXTAKE :

IF , Cond , Label1 :
WITH, P , Label2 :
ELSE (ou ALWAYS) : Label3 ;
MAXTAKE Nombre de branches maximum à emprunter ∞

(sur chaque branche sera routée une copie
de l 'entité qui arrive au bloc à créer
P Probabilité de selection d'une branche Néant

(Constante ou expression entre 0 et 1)
C Condition Néant
Label1 , .. Labels des blocs vers lesquels se brancher Néant

EXEMPLES:
On emprunte 2 branches aux maximum. La première

branche est empruntée si la condition A(1).EQ.1 est
2 vraie. Dans ce cas une copie de l’entité est routée
vers le bloc ayant pour label NEXT. Le choix de la
IF, A(1).EQ.1 NEXT deuxième branche est probabiliste. Cette branche
With, A(2) REFAIRE sera donc empruntée avec une probabilité égale à
ELSE EXIT l’attribut A(2) de l’entité. Une copie de l’entité sera
routée vers le bloc ayant pour Label REFAIRE. La
BRANCH , 2 : dernière branche est de type deterministe et sera
IF , A(1).EQ.1 , NEXT : empruntée si au moins une des branches précédentes
WITH, A(2) , REFAIRE : n’aura pas été empruntée. Dans ce cas, une copie de
ELSE , EXIT ; l’entité sera routée vers le bloc ayant pour Label
EXIT.
ALWAYS MACHINE1 Dans cet exemple, les deux branches sont

deterministes. La valeur par défaut de MAXTAKE
ALWAYS MACHINE2 étant infinie, les deux branches seront donc
empruntée et une copie de l’entité sera routée vers le
BRANCH : bloc ayant pour label MACHINE1et une autre copie
ALWAYS , MACHINE1 : vers le bloc ayant pour label MACHINE2 .
ALWAYS , MACHINE2;
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;
NSIGNAL Nuémro du signal à attendre (entier) Néant

(A(I), X(I) ou I)
EXEMPLES :
QUEUE , 1; Une entité qui arrive au bloc WAIT

se met en attente du signal dont le
1 numéro est égal à l'attribut A(1) de
WAIT : A(1); l'entité. La file d'attente dans laquelle
WAIT les entités attendront est la file N° 1.
A(1)
Lorsqu'une entité arrive à ce bloc,
SIGNAL : 2; toutes les entités se trouvant dans la
SIGNAL
file N°1 et dont l'attribut A(1) est égal
2 à 2 quittent la file d'attente et
traversent WAIT
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;
RNAME Nom de la ressource Néant
Unités Nombre d'unités à ajouter ou retrancher Néant

de la capacité courante de la ressource
(A(I), X(I) ou I)
EXEMPLES :
ALTER
SERVEUR, -2 Le nombre d'unités de la ressource SERVEUR est

decrémenté de 2 unités.
ALTER : SERVEUR , -2;

ALTER
Le nombre d'unités de la ressource FRAISEUSE
FRAISEUSE, A(1) 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);

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 : 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.
• RAND : 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).
FORMAT INSTRUCTION:
SELECT : REGLE , LABEL : LABEL : ........LABEL;
REGLE Règle de sélection d'une ressource POR
LABEL Label d'un bloc HOLD (voir les types de Néant

fonctions possibles : SEIZE , PREEMPT , ...)
EXEMPLES :
1
Lorsqu'une entité arrive au bloc QUEUE, et qu'il
existe des Machines libres , le choix de la machine
RAN à lui allouer est fait de manière aléatoire(RAN).
Dans le cas où toutes les machines sont occupées,
MACHINE1 l'entité attend dans la file N°1.
MACHINE2
MACHINE3
L'ordre d'apparition des LABELS des blocs
HOLD (SEIZE.....) dans SELECT est utilisé par
la règle POR.
SEIZE
M1
MACHINE1
QUEUE,1;
SEIZE SELECT, RAN : M1:M2:M3;
M2
MACHINE2 M1 SEIZE : MACHINE1;
M2 SEIZE : MACHINE2;
SEIZE
M3 M3 SEIZE : MACHINE3;
MACHINE3
BLOC : MATCH (Synchronisation du mouvement des entités)
Symbole graphique :

Format
MATCH, MA : QLBL , LABEL : ..........QLBL, LABEL; T

T
MA : 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.

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é
T

représentant le dossier du malade a été

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.
BLOC : PREEMPT (Allocation de Ressource par Preemption)

Symbole graphique :
PREEMPT, PR
RNAME, NA, LSEND
FORMAT INSTRUCTION:
PREEMPT, PR : RNAME , NA , LSEND : MODIFIERS....;
PR Priorité de préemption (entier A(I), X(I) ou I) 1
RNAME Nom de la ressource Néant
NA Nuémro de l'attribut dans lequel stocker le temps restant Néant

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 :
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
PREEMPT lieu à cause de la priorité de préemption (1), l’entité est mise en attente
MACHINE dans la file associée au bloc QUEUE précédent jusqu’à ce que 1 unité
lui soit allouée.
PREEMPT : MACHINE;
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é
PREEMPT, A(1) dans l’attribut 2 de l’entité qui sera alors routée vers le bloc
CPU , 2, RELANCER 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.
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.
BLOCS : QPICK (Prise d'une entité dans une file d'attente choisie
parmi plusieurs)
Symbole :
QSR
LABEL1 T
LABEL2 T
FORMAT INSTRUCTION:
QPICK , QSR : LABEL1:.......:LABELn;
QSR (Queue Selection Rule) Règle de selection de la file POR

(CYC, RAN, POR, SNQ, ...)
LABELi Label de chacun des bloc QUEUE précédents Néant
EXEMPLE AVEC QPICK : 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
POR fonction de l’ordre d’énumération
des labels dans QPICK. Ici c’est la
FILE1 T
file 1 correspondant au label FILE1
FILE2 T qui sera choisie en priorité. Les
entités de la file 2 ne seront donc
selectionnées que si la file 1 est vide.
SEIZE
On remarque l’utilisation du
MACHINE
connecteur DETACH avec les deux
blocs QUEUE afin d’émpecher
que ces blocs soient connectés à
d’autres.
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;
QSR Règle de selection de la file (CYC, RAN, ...) POR

LBALK Label du bloc vers lequel router l’entité si files pleines Détruire l’entité
LABELi Label de chacun des bloc QUEUE suivants Néant
EXEMPLE AVEC PICKQ : Les entités qui arrivent au

SNQ bloc PICKQ seront dirigées
vers l’un des blocs QUEUE
EXIT

ayant pour lables FILE1 et
FILE1
FILE2. La règle de selection
FILE2 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é
SEIZE
maximale (qui est de 50) ,
CABINE1 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é
SEIZE
détruite (option par défaut).
CABINE2

Fin de ce chapitre

Dr Brahim BELATTAR. LISA. D partement d'Informatique. Facult des Sciences de l'Ingnieur. Universit de Batna. 1
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
Typical Primary Operating

Product Vendor Applications Markets System(s)
ALPHA/Sim ALPHATECH Business process Military, IBM PC: Windows

Inc. reengineering, manufacturing, NT; Sun Workstation:
service delivery, health care, Solaris, Sun OS
manufacturing service industry
systems, military
command & control,
more
AMS: Manugistics Used in the Semiconductor Y2K compliant

Semiconducto Inc. semiconductor component versions of operating
r industry for capacity manufacturing systems
planning, factory-
level planning &
floor scheduling.
Arena Systems Business process Manufacturing, Win 95/NT

Modeling analysis, discrete logistics, supply
Corporation event simulation, chain, services
modeling
@RISK PALISADE General purpose, Financial, oil and Win 95/98, NT, 3.x,
Corporation cost analysis gas, health care Mac OS
AutoMod AutoSimulat Shop scheduling, Manufacturing, NT or Win 95

ions manufacturing, aerospace,
warehousing and automotive,
distribution, work pharmaceuticals
cell layout
C Library Numerical General Finance, UNIX and Windows

Algorithms industries, NT
Group universities,
laboratories
Call Center The Model Call center work Call centers Windows 95/NT
MAESTRO Builders force staffing and
Inc. technology
evaluation.
CB Predictor Decisioneeri Project likely Any forecaster or Windows 95, 98, or

ng Inc. revenue figures and planner, in any NT 4.0
cash flows, forecast industry, could
product demand for use this product.
inventory control,
project next year's
sales
JobTime Plus JobTime Used for simulation- Manufacturing DOS, Windows 3.x,
Systems based advanced applications in Win 95/98, NT Client
Inc. planning and the small- to and NT Server
scheduling. 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 Data All Windows 95/98/NT,

Products communications, UNIX, HP/UX, SGI
Company telecom-
munications,
network design,
network planning
Crystal Ball Decisioneeri Business planning Financial Windows 95, 98, or

Pro ng Inc. and analysis, services, oil and NT4.0
cost/benefit gas,
analysis, risk pharmaceutical,
management, environmental
petroleum analysis
exploration
DecisionPro Vanguard Busines financial Management Windows 95, 98, NT

3.0 Software modeling, decision consulting,
Corporation modeling manufacturing,
legal
Deneb/Quest Deneb Manufacturing, Manufacturing, NT/95/98

Robotics material handling, warehousing and
Inc. discrete material distribution
flow analysis
ExpertFit Averill M. Fitting probability Manufacturing, Windows 3.1, 95, 98,

Law & distributions to data defense, NT
Associates communications,
services, health
care
Extend Imagine Engineering design, Science, Windows 95, 98, NT,

That Inc. scientific analysis, engineering, 3.1; Mac 68020+,
custom electronics, Power Mac
programming education, health
care,
environmental
studies,
defense/aerospac
e
Extend & Imagine Process modeling, Business, Windows 95, 98, NT

BPR That Inc. ABC, workflow, cycle government, 3.1; Mac 68020+,
time, strategic telecom- Power Mac
analysis, technology munications,
insertion analysis banking, health
care, education,
financial services
Extend & BPR Imagine General, queing, Engineering, Windows 95, 98, NT
& That Inc. manufacturing, science, 3.1; Mac 68020+,
Manufacturing costing analysis, manufacturing, Power Mac
business, industrial business,
and commercial government,
modeling service
industries,
education
Extend & Imagine Industrial and Materials Windows 98, 95, NT

Manufacturing That Inc. commercial handling, 3.1, Mac 68020+,
modeling, JIT, networks, Power Mac
queueing, costing, manufacturing,
logistics, throughput transportation,
analysis government/milit
ary, service
industries
FACTOR/AIM SYMIX/Prits Manufacturing Manufacturing Windows 95, NT 4.0

ker Division decision support
GPSS/H Wolverine General, General (not Win 3.x, 95, 98, NT;
Software manufacturing, industry-specific) OS/2; DOS; Solaris
Corporation transportation,
computing
systems/networks,
mining, logistics,
queuing, etc.
GPSS/PC Minuteman Simulation for Manufacturing, DOS

Software optimization or transportation,
analysis of design - health care,
general communications,
general - wide
range of
applications
H/SCHED Haverly Refinery scheduling, Petroleum Windows 95/98/NT

Systems crude oil scheduling, refining
Inc. product blending
scheduling,
distribution
scheduling
IBM Supply IBM Supply chain Distribution, Windows NT

Chain analysis, cost transportation,
Simulator analysis, inventory manufacturing
optimization
ithink Analyst High Suited for high-level All markets. Windows, Mac
5.1.1 Performanc strategic modeling, Suited to any
e Systems does have discrete application where
Inc. functionality 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 CMS Manufacturing, Windows 95/NT

Simulation Research machine tool
Environment Inc. companies
MedModel PROMODEL Health care, Health care Windows, NT

Corporation capacity analysis,
facility design,
optimization
micro-GPSS Ingolf Stahl General purpose Educational DOS, Windows, Web

discrete events (business and systems
simulation engineering)
Micro Saint Micro General, health Human Win 95/98/NT

Analysis & care, human factors, factors/ergonomi
Design Inc. manufacturing cs
MODSIM III CACI Transportation, air All Windows, Sun

Products traffic, military, Solaris, HPUX, SGI
Company logistics, telecom-
munications
NAG Fortran Numerical General Financial, UNIX, Linux, NT, HP-

Library, Mark Algorithms government & UX, AIX, DOS, IRIX,
18 Group educational Solaris, Sun OS
research
NAG Fortran Numerical General Programmers and Linux, NT, HP-UX,

90 Library Algorithms software AIX, IRIX, Solaris,
Group developers, Sun OS, other UNIX
scientists and
engineers
NAG Fortran Numerical General Finance, IRIX, Solaris, UNIX &

SMP Library Algorithms laboratories, NT
Group industry
NAG Parallel Numerical General Science, UNIX, AIX, IRIX,

Library Algorithms engineering, Solaris, UNICOS
Group financial analysis
& research
Optima 2.5 Micrografx Optima is a process Telecom- Windows 3.1, 95, 98,
Inc. analysis application munications, NT 3.51 or later
offering high-end financial services,
simulation pharmaceutical,
capabilities. Used for manufacturing,
BPR, TQM, etc. health care, and
more
PASION32 Stanislaw Simulation Manufacturing, Windows 95 and

Raczynski engineering, Borland's Delphi 3
education,
operation
research
ProcessModel PROMODEL General, process Manufacturing, Windows, NT

Corporation improvement, financial call
reengineering centers, health
care
ProModel PROMODEL Manufacturing, Manufacturing Windows, NT

Corporation facility design,
process
optimization,
material handling,
supply chain
Proof Wolverine Manufacturing, General Windows 95/98/NT

Animation Software material handling,
general
PS-ENGINE Prosolvia PS-ENGINE Plant Midsized Windows NT

AB Design; PS-ENGINE operations with
Assembly; PS- their main focus
ENGINE Layout; PS- in discrete
ENGINE Review manufacturing
QueGauss Aptech General queing Engineering, DOS, Win NT/95/98

Systems simulation health care,
Inc. financial
ServiceModel PROMODEL General, service Financial, call Windows, NT

Corporation apps., queuing, centers, airlines,
costing, restaurants
optimization
SIGMA Custom General discrete Manufacturing All versions of

Simulations event simulations; factory and Microsoft Windows
simulation equipment
education; supports modeling, health
all modeling care, and banking
paradigms operations
Silk ThreadTec Manufacturing, Manufacturing, Any Java-compatible

Inc. communications, communications OS
general
SimGauss Aptech General dynamic Engineering, DOS, Win NT/95/98

Systems simulation of health care,
Inc. differential financial
equations
SIMNON 3.0 SSPA Differential and Technical schools, Windows

Maritime difference EQ; developing
Consulting simulation of industries
AB dynamic systems
SIMPLE++ Tecnomatix Simulation, Manufacturing, Windows NT/95,

Technologie production planning, transportation, UNIX
s Inc. scheduling, petro-chemicals,
forecasting, financial services,
optimization, object- telecom-
oriented munications,
programming automotive,
aerospace,
electronics
SIMPROCESS CACI Business process All Windows 95/98/NT

Products
Company
SIMUL8 Visual General purpose Manufacturing, Windows 95/98/NT

Thinking discrete-event visual distribution,
Internationa simulation tool health care,
l business process
reengineering,
financial
SLX Wolverine Manufacturing, General Windows 95, 98, NT

Software material handling,
general
Stat::Fit Geer Distribution Fitting All - Win 95, 98, NT 4.0

Mountain for general manufacturing,
Software simulation health care,
Corp. applications financial, quality
and reliability,
service
industries, etc.
Manufacturing,
Taylor ED
F&H Manufacturing, distribution,
Logistics Win 95, Win NT
Suite
Simulations material handling warehousing,
financial, service
Visual Orca General Generically Windows 95/98/NT

Simulation Computer applicable for use 4.0, Openstep/Mach
Environment Inc. in any market. Unix
WITNESS 9.0 Lanner Business process Manufacturing, Windows 3.1, 95, NT,
Group Inc. reengineering, plant automotive, 98
layout, scheduling, defense,
queuing, cost pharmaceuticals,
analysis chemicals,
electronics,
hydrocarbon
WorkFlow Meta Business process Financial Windows NT/95

Analyzer Software reengineering, services,
Corporation workflow analysis government
*****************************************************************************
*
Model
Graphic Building Input Run-time
Model via Distri- Code Reuse Debug
Con- Pro- bution Output (objects, Tem- (Inter-
struc- gram- Fitting Analysis plates, sub- active
Product tion ming Support Support models) debugger)
ALPHA/Sim y - - y y y
AMS: y - y y y -
Semiconductor
Arena y y y y y y
@RISK - - - - - -
AutoMod y y y y y y
C Library - y - - y -
Call Center y - - y - -
MAESTRO
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 y y y y y

Manufacturing
Extend & y y y y y y
Manufacturing
FACTOR/AIM y - - y y y
GPSS/H - y y - - y
GPSS/PC - y - y - y
H/SCHED - y - y y -
IBM Supply y - y y y -
Chain Simulator
ithink Analyst y - - y y y
5.1.1
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 - y - - y -
Library, Mark
18
NAG Fortran 90 - y - - y -
Library
NAG Fortran - y - y - -
SMP Library
NAG Parallel - y - - y -
Library
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
SLX - y y y y y
Stat::Fit - - y - - -
Taylor ED y y y y y y
Logistics Suite
Visual y y - y y y
Simulation
Environment
WITNESS 9.0 y - - y y y
WorkFlow y - y y - y
Analyzer
****************************************************************************
**
Is animation List
Can the Can animation by post compatible
output be viewed processor/ animation
Product be animated in real-time trace file software, if any
ALPHA/Sim y n n N/A
AMS: y y n
Semiconduc
tor
Arena y y y
@RISK n - -
AutoMod y y y
C Library - - -
Call Center n y n
MAESTRO
CB n n n N/A
Predictor
JobTime y n y Wolverine Proof

Plus
COMNET y y n N/A
III
Crystal Ball n n n N/A

Pro
DecisionPro n n n
3.0
Deneb/Que y y y VRML 2.0

st
ExpertFit - - -
Extend y y y Proof animation (animation

also built into program)
Extend & y y y Proof animation (animation

BPR also built into program)

BPR & also built into program)
Manufacturi
ng

Manufacturi also built into program)
ng
FACTOR/AI y y n
M
GPSS/H y n y Proof animation
GPSS/PC y y y Proof animation
H/SCHED y y -
IBM Supply y y n
Chain
Simulator
ithink y y n N/A - internal feature to

Analyst ithink
5.1.1
MAST y y y
Simulation
Environmen
t
MedModel y n n
micro-GPSS y n y Proof animation (Wolverine

Software)
Micro Saint y n n
MODSIM y y n
III
NAG n - -
Fortran
Library,
Mark 18
NAG n - -
Fortran 90
Library
NAG - - -
Fortran SMP
Library
NAG - - -
Parallel
Library
Optima y y n
2.5
PASION32 y n y
ProcessMod y n n
el
ProModel y n n
Proof y y y This is animation software.

Animation
PS-ENGINE y y n
QueGauss - - -
ServiceMod y n n
el
SIGMA y y y Graphical model generates

standard C code for full
control of output format.
Silk y y n
SimGauss n - -
SIMNON n n n
3.0
SIMPLE++ y y - Devise from Division (VR)
SIMPROCES y y n
S
SIMUL8 y y n
SLX y y y Uses proof animation;

supports real-time and
post-
processor mode
Stat::Fit n n n
All animations, graphics,

Taylor ED
and statistics are self-
Logistics y y y
contained and fully
Suite
integrated in the package.
Visual
Simulation
y y n None
Environmen
t
WITNESS
y y -
9.0
WorkFlow
y y n
Analyzer
****************************************************************************
**
Product Major New Features Comments
ALPHA/Sim For spring 1999: Addition ALPHA/Sim is a general-purpose, discrete-event

of ports on box nodes simulation tool based on Petri nets. The
(encapsulation feature to graphical modeling environment provides a
assist in model reuse). simple yet powerful set of model building
This release will run on blocks, making it easy to learn & use
Windows 95/98, NT & productively.
UNIX (Solaris).
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 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
submodels; a Visio link reports.
that lets you associate any
Visio shape with an Arena
module; & connector
animation.
@RISK Performs risk analysis via Monte Carlo

simulation. Features sensitivity and scenario
analysis. Part of DecisionTools Suite.
AutoMod 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
C Library NAG has made major A collection of over 300 sophisticated

additions to the subroutines for mathematical & statistical
optimization chapter, computation.
improved thread-safety
and Y2K compliance.
Call Center Quantify the impact of Call Center MAESTRO allows managers to
MAESTRO using one group of agents quickly 1) analyze the effect of call volume
with General Skills" vs. and/or staffing level on service quality; 2)
using multiple groups of visualize the effect of forecasted call volume on
agents where each group staff utilization, and 3) quantify the benefit of
has a "Specialized skill." additional technology.
CB Predictor 100 percent Microsoft CB Predictor incorporates the most advanced

Excel compatibility, best- methods of Time-Series Forecasting (TSF) into
of-breed forecasting an easy-to-use Microsoft Excel add-in. TSF
algorithms, user- techniques analyze historical data to predict
definable confidence future performance. CB Predictor taps into this
parameters, customizable cache & produces forecasts.
forecast reporting engine,
pivot tables for easy data
management
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
interface to MRP/ERP fields. Built-in features included.
systems, material/
inventory constraints
COMNET III New add-on modules: COMNET III accurately predicts LAN, WAN, and
application profiler, enterprise network performance. COMNET III
distributed software enables users to reduce risk by experimenting
module, satellite and with diverse network alternatives before
mobile module. implementing their plans.
Crystal Ball This is a suite of products Crystal Ball Pro is a powerful yet easy-to-use
Pro that includes Crystal Ball, suite of forecasting and risk analysis tools that
the Developers Kit, the enhance spreadsheet modeling. It gives you the
Extenders, & OptQuest. ability to perform Monte Carlo analysis
OptQuest is the only combined with optimization on your
commercially available spreadsheet models.
tool that offers global
optimization for
spreadsheets under
conditions of uncertainty.
DecisionPro Version 3.0 adds over 100 DecisionPro is a general-purpose modeling and
3.0 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,
improving simulation and Web-based expert system development.
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
costing; VRML1.0; AVI, from other Deneb simulation products.
MPEG movie output; Read/write to external files and processes.
saving & retrieving groups
of elements; directly
reading CATIA geometry;
Pro/
ENGINEER and
Unigraphics translators
available on PC
ExpertFit Batch-mode processing, ExpertFit will automatically & accurately

distribution viewer, determine which of 39 probability distributions
homogeneity testing of best represents a data set in seconds. It will
several data sets, then put the selected distribution into the
improved histograms with proper format for 33 simulation products.
a scroll bar for
interactively updating the
interval widths, support
for simulation software
products AutoSched AP,
SImPROCESS, SIMUL8 , &
SLX
Extend The acknowledged Other powerful features include unlimited layers

standard for dynamic of hierarchy, customizable animation, hot links
modeling and simulation to Microsoft Office, one-click output analysis,
now features animated automatic report generation, user-
online tutorials that show definable attributes, interactive model
you how to build & run execution.
Extend models, fine
control of block location,
optional connection line
animation, progressive
block improvements.
Extend & Make the most of new Provides an integrated financial & operational
BPR 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 The ultimate in simulation flexibility helps you
& standard for dynamic maximize your improvement efforts.This
Manufacturing modeling and simulation product can help managers reduce costs,
now features animated manufacturing professionals streamlining
online tutorials that show operations, and engineers designing new
you how to build & run components.
Extend models, fine
control of block location,
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 blocks for processing, batching, trans., routing
how to build and run & other industrial processes. Combines
Extend models, fine sophisticaed stat. anlysis with preemption,
control of block location, reneging & more.
animation, & numerous
new functions.
FACTOR/AIM 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.
GPSS/H Parameterized error Extremely powerful and scalable general-

messages purpose simulation language. Maintains
lightning-fast performance even on
large/complicated models. No limits" software."
GPSS/PC We plan to release a Windows version of GPSS

based on our GPSS World OS 2 version.
H/SCHED Improves Gantt, time line H/SCHED is a suite of process industry

and process flow displays; scheduling applications for refinery, crude oil
total integration with and product movement scheduling. H/SCHED
planning & crude assay helps to develop alternative plans through the
management use of simulation tools, interactive Gantt charts,
& decision tables.
IBM Supply Web-based client-server It's a solution, not a shrink-wrapped package.

Chain interface for running Must be combined with consulting services
Simulator multiple scenarios 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, Designed for the healthcare industry, MedModel

improved speed has the ability to improve healthcare processes
overnight. Typical applications include facility
redesign, capacity analysis, cost reduction &
staffing plans.
micro-GPSS WebGPSS, developed in Streamlined version of GPSS, cutting learning

Java, for doing simulations time in half. Described in Simulation Made
on the Web, with GUI Simple with micro-GPSS
allowing for building
programs by clicking on
block symbols with new
graphics, in June 1999
Micro Saint Micro Saint is the only software to include

optimization in the base price product.
MODSIM III Web-based simulation; MODSIM III is the most powerful, object-
database connectivity; oriented simulation language in the world. It is
distributed simulation designed for modeling complex and large
systems by software engineers.
NAG Fortran Mark 18 of the Fortran NAG provides a robust, reusable library of the
Library, Mark Library has extended the most sought-after numerical routines for
18 areas of ordinary successful math. modeling. Y2K compliant.
differential equations,
partial differential
equations, interpolation,
optimization, sparse linear
algebra and OR
NAG Fortran Two new chapters: Matrix The NAG Fortran f190 Library was designed to
90 Library & 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
norms of a matrix, Fortran 90 & Fortran 95. Also Y2K compliant.
constrained nonlinear
least squares, and more;
18 new documented
procedures
NAG Fortran Maximization of the This numerical library is optimized for use on
SMP Library processing potential of Symmetric Multi-Processor (SMP) computers &
SMP machines in the key contains the full functionality of the NAG Fortran
areas of linear algebra, Library. Y2K compliant.
FFTs & multivariate
statistics.
NAG Parallel Significant improvements The NAG Parallel Library is a collection of

Library 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
matrix operations & machines. Y2K compliant.
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, General purpose, Delphi-based simulation

completely Windows 95 systems. Supports queuing models, continuous,
ODE, bond graphs, signal flow, animation
ProcessModel New ProcessModel 3.0, ProcessModel is an easy-to-use simulation tool

improved interface, for improving business processes. This
guarantee and revolutionary technology allows virtually anyone
optimization 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; ProModel, a leader in the simulation software

built-in optimization 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.
Proof Real-time capability; AVI General purpose, Windows-based animation

Animation capture; WAV playback software which can be used with a wide variety
of discrete event simulation software.
PS-ENGINE PS-ENGINE is developed PS-ENGINE provides a powerful simulation tool

to be a powerful yet easy- for the manufacturing industry. With this
to-use simulation tool. product, simulation becomes - for the first time
Simulation models are - a valuable and easy-to-use everyday tool for
created by using drag and the manufacturing industry.
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 SIGMA was the first Windows simulation lang. &
flowcharting format, exclusively uses direct system API calls to
multiple sessions, optimize use of memory & execution speed.
simultaneous execution Fully interactive model development, animation,
and replication of models, & testing. SIGMA's completely general Event
development of reusable Graph method is easy to learn
simulation tools.
Automatic C code
generation to support
simple spreadsheet
interfaces for
experimentation.
Silk Java Beans modeling & Silk merges familiar process-oriented modeling
animation component; with the Java language for object-oriented,
Java Development Kit Internet-capable simulation. Animated
(JDK) 1.2; Java simulation models can be placed on a web site
Foundation classes & executed within standard browser software.
(JFK)/Swing support
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.
SIMNON 3.0 Dev. platform is Win 32; Faster handling by Block DDE and RPC - server;
Double precision built in color syntax; demo available on
calculation (64 bytes); www.sspa.se
external systems to be /simnon
connected to Simnon can
be written in Fortran
and/or C++.
SIMPLE++ 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 SIMPROCESS integrates process mapping,

Management tools, BPR hierarchical, event-driven simulation, and
tools activity-based costing into a single tool.
SIMUL8 Ability to convert Visio SIMUL8 offers you the latest in workflow
flow chart diagrams into modeling. Simply build your system by dragging
simulation models; objects (machines, buffers, conveyors, people,
enhanced user interface tools) onto the screen and connecting them.
for Visual Logic Editor, Learn why industry leaders like Ford are buying
Excel, VB/VBA; user- SIMUL8 in packs of 100.
configurable toolbars;
template facility with
password security; plug-
ins for modeling,
transportation object
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
Visual Fully & truly object- VSE's toolset includes Editor, Simulator, Output
Simulation oriented; model Analyzer & Teacher. VSE provides state-of-the-
Environment developement from art object-oriented technology with message
libraries of reusable passing, inheritance & encapsulation. Libraries
components without of reusable model components can be built.
programming; dynamic
object decomposition;
hierarchical model
architecture; graphical &
picture-based; input data
specification; multiple
animation viewers
WITNESS 9.0 Hierarchical model Virtual and easy to use, WITNESS Release 9
structure; easy-to-reuse offers a powerful and highly flexible engine to
components, power and handle the most complex scenarios. The product
free conveyors, part provides the capability to model virtually any
arrival schedules in working environment and inexpensively perform
spreadsheet format, what if" analyses."
reporting formats,
designer element sets,
tree style" element
selector and long names"
WorkFlow Interface to FileNet Visual

Analyzer Workflow, Plexus FloWare,
DST Systems AWD; model
repository and MetaWeb
ANNEXE B : 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
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
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
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.
F&H Simulations
http://www.taylorii.com/

Modelisation and Simulation Sur Ordinate PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Modelisation and Simulation Sur Ordinate PDF

Загружено:

Авторское право:

Доступные форматы

UNIVERSITE DE BATNA

Faculté des Sciences de l’Ingénieur

Modélisation & Simulation

Docteur Brahim BELATTAR

Doctorat Nouvelle thèse en informatique

Année universitaire 2003/2004

SIMULATION DES SYSTEMES : UNE INTRODUCTION

• Concevoir et analyser des systèmes industriels

• Concevoir des systèmes de communications et leurs protocoles

2. NOTIONS DE SYSTEME , MODELE et SIMULATION

2.1 NOTION DE SYSTEME

• Ensemble de composants reliés entre eux

 c’est un tout composé de parties ordonnées

Ces caractéristiques font ressortir qu’un système est défini par :

• la connaissance de ses parties ou composants

• la connaissance des lois d’interaction qui déterminent son but

2.1.1 Définition d'un système

La complexité d'un système provient du fait qu'il peut comporter beaucoup de

Chacune de ses parties a ses lois (règles de fonctionnement) et est partiellement

L’identification des frontières du système avec son environnement (milieu)

Fig1 : le systéme et son environnement

- élargir le système de façon à les inclure

2.2 MODELE ET MODELISATION

Exemple : Un projet de construction d’un avion comprend les étapes suivantes

en utilisant du bois et du contre-plaqué

Ce modèle va servir pour étudier (expliquer) certains aspects de l’avion (disposition

2) On construit des modèles réduits de l’avion en utilisant les vrais matériaux.

Les principaux avantages de manipuler un modèle plutôt que le système qu’il

2.2.2 Processus de modélisation

Fig2(a) : Processus de Modélisation

Un autre schéma distinguant entre modele conceptuel et modele programmé sur

      

Fig2(b) : Processus simplifié de Modélisation

Le modèle conceptuel est une représentation (mathématiques logique, verbale, etc

2.2.3 Construction d'un modèle

• Définition des frontières du modèle et donc des variables internes,

Deux méthodes complémentaires sont couramment employées pour la construction

- l'affinage progressif (descendante): Appelée aussi méthode de

- l'accumulation de sous-modèles (ascendante): Utilisée lorsque le

système en sous-systèmes distincts. La complexité du système est alors mieux maîtrisée

2.2.4 Classification des modèles

Les modèles symboliques : ou abstraits sont une abstraction mathématisée de la

Une troisième dichotomie sépare les modèles statiques et les modèles

Enfin, à l’intérieur des modèles dynamiques, on distingue les modèles discrets,

2.3 NOTION DE SIMULATION

• Décrire et analyser la dynamique d’un système

• Expérience conduite sur un calculateur à l’aide d’un modèle

" La simulation est l'étude du comportement dynamique d'un système, grâce à un

 Un élément fondamental qui est le modèle

La simulation peut aussi être vue comme la conduite d’une expérimentation

2.3.2 Expérimentation directe et indirecte

Fig 3(a) Expérimentation directe et indirecte

Fig3 (b): Expérimentation directe et indirecte

2.3.3 Quand simuler

Fig4(a) : approches pour étudier un système

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

b. En effectuant des mesures

Ces trois méthodes induisent les quatre questions suivantes :

1. Est-ce qu'on simule seulement quand on ne peut pas calculer?

Cette question a trait au probleme lui-meme et au choix d'une methode pour le

cette question a trait a un aspect tres important en simulation , à savoir celui de la

exemple : Supposons que le reservoir a comme caractéristique spéciale, le fait que le

c’est un tout composé de parties ordonnées

Un élément fondamental qui est le modèle

0pWKRGH j SDV FRQVWDQW

0pWKRGH j SDV YDULDEOH

$3352&+(6 '( 02'(/,6$7,21 '(6 6<67(0(6 $ (9(1(0(176 ',6&5(76