Le défi
par Thomas J. Schriber (Université du Michigan), Daniel T. Brunner (Dan Brunner Associates) et Jeffrey S. Smith (Université d'Auburn)
Présenté lors de la Conférence d'hiver sur la simulation 2017
Cet article fournit aux praticiens de la simulation et aux consommateurs des bases sur le fonctionnement des logiciels de simulation à événements discrets. Les sujets abordés comprennent les systèmes à événements discrets, les entités, les ressources, les éléments de contrôle et les opérations, les cycles de simulation, les états des entités, les listes d'entités et leur gestion. Les implémentations de ces idées génériques dans AutoMod, SLX, ExtendSim et Simio sont décrites. Le document se termine par plusieurs exemples montrant "pourquoi il est important" pour les modélisateurs de savoir comment fonctionne leur logiciel de simulation, y compris une discussion sur AutoMod, SLX, ExtendSim, Simio, Arena, ProModel et GPSS/H.
1 Introduction
Une approche de type "boîte noire" est souvent adoptée dans l'enseignement des logiciels de simulation d'événements discrets. Les caractéristiques externes du logiciel sont étudiées, mais la base sur laquelle repose le logiciel n'est que brièvement abordée ou totalement ignorée (par manque de temps). Les choix effectués lors de la mise en œuvre de la base et l'impact de ces choix sur l'exécution du modèle étape par étape peuvent ne pas être étudiés du tout. Le modélisateur pourrait alors ne pas être en mesure de réfléchir à fond lorsqu'il est confronté au développement de bonnes approches pour modéliser des situations complexes, à l'utilisation d'outils interactifs pour parvenir à une compréhension des conditions d'erreur survenant au cours du développement du modèle, et à l'utilisation d'outils interactifs pour vérifier que la logique d'un système complexe a été modélisée correctement. L'objectif est donc ici de décrire les fondements logiques de la simulation à événements discrets et d'illustrer ce matériel en termes de diverses implémentations de logiciels de simulation à événements discrets.
Dans les sections 2, 3 et 4, nous commentons la nature de la simulation à événements discrets, les constructions de simulation de base telles que les entités, les ressources, les éléments de contrôle et les opérations, ainsi que l'exécution du modèle. La section 5 traite de quatre implémentations spécifiques des règles de gestion des entités. Enfin, la section 6 explore divers aspects du "pourquoi c'est important". Dans ce document, les termes que nous définissons sont en gras lors de leur première utilisation. Les termes spécifiques aux outils sont en majuscules ou, le cas échéant, en majuscules.
Ce document est une version révisée d'un document similaire initialement publié dans les actes de la conférence sur la simulation d'hiver de 1996 (Schriber et Brunner 1996). Une version de l'article de 1996 a été présentée à la conférence chaque année depuis 1996, avec des mises à jour occasionnelles, telles que la modification de l'ensemble des langues couvertes en détail. Par exemple, le document de 1996 traitait des règles de gestion des listes d'entités et de leur importance pour SIMAN (Arena), ProModel et GPSS/H. (Une version considérablement élargie du document de 1996 a été présentée à la conférence. (Une version considérablement élargie du document de 1996, contenant des figures, des organigrammes et des explications supplémentaires, se trouve dans Schriber et Brunner (1998)).
La solution
2 La simulation d'événements discrets dans la vision du monde du flux de transactions
La "vision du monde du flux de transactions" sert souvent de base à la simulation d'événements discrets. Dans cette vision, un système est visualisé comme étant constitué d'unités discrètes de trafic qui se déplacent (flux) d'un point à l'autre du système tout en étant en concurrence les unes avec les autres pour l'utilisation de ressources rares (à capacité limitée). Les unités de trafic sont parfois appelées "transactions", d'où l'expression "flux de transactions". De nombreux systèmes correspondent à la description précédente. Il s'agit notamment des systèmes de fabrication, de manutention, de services, de soins de santé, de communication et de traitement de l'information, ainsi que d'autres systèmes généraux de files d'attente.
Fondamentalement, une simulation à événements discrets est une simulation dans laquelle l'état d'un modèle ne change qu'à un ensemble discret, mais éventuellement aléatoire, de points temporels simulés, appelés temps d'événement. Deux ou plusieurs unités de trafic doivent souvent être manipulées à un seul et même moment. Ce mouvement "simultané" du trafic est obtenu en manipulant les unités de trafic en série à ce point dans le temps. Cela entraîne des complexités logiques car cela soulève des questions sur l'ordre spécifique en temps réel dans lequel deux ou plusieurs unités de trafic doivent être traitées à un moment donné de la simulation.
Les défis auxquels est confronté un modélisateur s'intensifient pour le concepteur d'un langage de modélisation. Le concepteur doit prendre en compte les exigences logiques de la simulation à événements discrets d'une manière généralisée. Il existe des choix et des compromis. Par conséquent, bien que les langages de simulation à événements discrets soient similaires dans les grandes lignes, ils peuvent différer sur des points subtils mais importants. Nous cherchons à développer cette notion et à fournir des exemples spécifiques dans le présent document. Mais avant cela, les sections suivantes présentent d'autres concepts généraux de simulation.
3 Entités, ressources, éléments de contrôle et opérations
Le terme entité est utilisé ici pour désigner une unité de trafic (une "transaction") au sein d'un modèle. Les entités déclenchent des événements et y répondent. Un événement est un phénomène instantané qui modifie l'état d'un modèle (ou d'un système). Dans un modèle de système de remplissage de commandes, par exemple, l'arrivée d'une commande (un événement) peut être simulée en introduisant une entité dans le modèle. Il existe deux types d'entités possibles, appelées ici entités externes et entités internes. Les entités externes sont celles dont la création et le mouvement sont explicitement organisés par le modélisateur (exemple : arrivée d'une commande à un point de traitement des commandes). En revanche, les entités internes sont créées et manipulées implicitement par le logiciel de simulation. Par exemple, les entités internes peuvent être utilisées dans certains langages pour déclencher des simulations de pannes de machines et mettre en œuvre des programmes de machines, alors que les entités externes peuvent être utilisées pour simuler l'utilisation de machines pour le traitement de pièces.
Le terme ressource désigne un élément du système qui fournit un service (tel qu'une foreuse, un véhicule guidé automatisé, un travailleur ou un espace dans un tampon d'entrée). Les entités utilisent généralement des ressources (par exemple, une entité de travail en cours réclame de l'espace dans un tampon d'entrée, puis capture un véhicule à guidage automatique pour déplacer l'entité vers le tampon d'entrée). Les ressources sont généralement limitées en capacité, de sorte que les entités sont en concurrence pour leur utilisation et doivent parfois attendre pour les utiliser, ce qui entraîne des retards (file d'attente). Le terme "élément de contrôle" désigne une construction qui prend en charge d'autres types de retard ou d'alternatives logiques basées sur l'état d'un système. Les éléments de contrôle peuvent prendre la forme de commutateurs, de compteurs, de valeurs de données utilisateur et de valeurs de données système intégrées dans l'outil de modélisation. Les conditions complexes peuvent être évaluées à l'aide d'expressions arithmétiques et/ou booléennes qui examinent l'état des éléments de contrôle pertinents.
Une opération est une étape (ou une série d'étapes) réalisée par ou sur une entité lorsqu'elle se déplace dans un système. Les opérations applicables à un navire dans un port peuvent être les suivantes : arriver au port ; demander un poste d'amarrage ; capturer un poste d'amarrage ; demander un remorqueur ; capturer un remorqueur ; se faire tirer dans le poste d'amarrage ; libérer le remorqueur ; charger la cargaison ; demander un remorqueur ; se faire tirer hors du poste d'amarrage ; libérer le poste d'amarrage ; se faire tirer en pleine mer ; libérer le remorqueur ; partir.
4 Aperçu de l'exécution du modèle
Un projet de simulation implique l'exécution d'expériences. Les expériences se distinguent par l'utilisation d'alternatives dans la logique d'un modèle et/ou dans les données d'entrée. Par exemple, d'autres règles de séquencement des pièces et/ou la variation du nombre de divers types de machines (ressources) peuvent être essayées dans le modèle d'un système de production. De même, le nombre de postes de chargement et de déchargement dans un port peut être modifié pour évaluer l'impact sur les performances du système. Chaque expérience consiste en une ou plusieurs réplications (essais). Une réplication est une simulation qui utilise la logique et les données du modèle de l'expérience, mais son propre ensemble de nombres aléatoires, et produit donc des résultats statistiques uniques qui peuvent être analysés dans le cadre d'un ensemble de telles réplications (qui sont toutes indépendantes). Une réplication consiste à initialiser le modèle, à l'exécuter jusqu'à ce qu'une condition de fin d'exécution soit remplie et à communiquer les résultats. Cette phase d'exécution est appelée "run".
Au cours d'une exécution, l'horloge de simulation (une valeur de données stockée et gérée en interne) suit le passage du temps simulé. L'horloge avance (automatiquement) par étapes discrètes (généralement de taille inégale) au cours de l'exécution. Lorsque toutes les actions possibles ont été entreprises à un moment donné de la simulation, l'horloge est avancée au moment de l'événement suivant le plus proche. Les actions appropriées sont alors exécutées à ce nouveau moment simulé, etc. En substance, l'exécution d'un run prend donc la forme d'une boucle à deux phases : "Ces deux phases sont répétées encore et encore jusqu'à ce qu'une condition de fin d'exécution (généralement un temps simulé spécifié par le modélisateur, un nombre d'entités traitées ou une autre condition) soit remplie. Ces deux phases sont respectivement appelées ici phase de mouvement des entités (EMP) et phase de mise à jour de l'horloge (CUP).
4.1 États des entités
Au cours de l'exécution de la simulation, les entités migrent d'un état à l'autre en se déplaçant dans un modèle. Les cinq états généralement utilisés sont les suivants
Actif - L'état de l'entité en mouvement est l'état actif. Par "entité en mouvement", nous entendons l'entité qui exécute actuellement la logique de décision dans le modèle. Une seule entité se déplace à chaque instant de l'horloge murale. Cette entité se déplace jusqu'à ce qu'elle rencontre un retard d'un type ou d'un autre. Elle migre alors vers un autre état.
Prêt - Au cours d'une phase de déplacement d'une entité, il peut y avoir plus d'une entité prête à se déplacer, mais les entités ne peuvent se déplacer (être dans l'état actif) que l'une après l'autre. L'état prêt est l'état des entités qui attendent d'entrer dans l'état actif pendant la phase de mouvement des entités en cours.
Temps différé - L'état différé est l'état des entités qui attendent qu'un temps simulé futur soit atteint pour pouvoir (re)passer à l'état prêt. Une entité "partie" est dans un état différé, par exemple, lorsqu'elle attend l'heure simulée future à laquelle une opération effectuée sur elle se terminera.
Condition retardée - L'état conditionné est l'état des entités retardées jusqu'à ce qu'une condition spécifiée se réalise, par exemple, une entité "pièce" peut attendre dans l'état conditionné jusqu'à ce que son tour vienne d'utiliser une machine. Les entités en état différé sont transférées automatiquement de l'état différé à l'état prêt lorsque les conditions spécifiées le permettent.
Dormant - Il est parfois souhaitable ou nécessaire de placer les entités dans un état dont aucune sortie ne sera déclenchée automatiquement par des changements dans les conditions du modèle. Nous appelons cet état l'état dormant. Les entités à l'état dormant s'appuient sur la logique fournie par le modélisateur pour les transférer de l'état dormant à l'état prêt. Les entités "job-ticket" peuvent être placées dans un état dormant, par exemple, jusqu'à ce qu'une entité "opérateur" décide quelle "job-ticket" tirer ensuite, avec pour conséquence le transfert de l'entité "job-ticket" à l'état "prêt". Dans ce cas, les conditions spécifiques en vigueur lors de la sélection de la fiche de poste peuvent ne pas être connues jusqu'à ce que l'entité opérateur sélectionne une fiche de poste.
4.2 Structures de gestion des entités
Dans notre modèle générique, nous gérons les entités en désignant une entité active et un certain nombre de listes d'entités. L'entité active (l'entité à l'état actif) se déplace sans arrêt jusqu'à ce qu'elle rencontre une étape (tentée) qui la fait migrer vers un autre état d'entité (la transfère vers une autre liste) ou la supprime du modèle. Une entité à l'état prêt devient alors la prochaine entité à l'état actif. Finalement, il n'y a plus d'entité prête à l'emploi à l'heure actuelle. Le PEM se termine alors et un PUC commence. Les listes suivantes sont utilisées pour organiser les entités. (La dynamique du mouvement des entités parmi ces listes sera illustrée dans une séquence de diapositives PowerPoint lors de la conférence de la Winter Simulation Conference qui sera donnée dans le cadre de ce tutoriel).
Liste des événements en cours - Les entités à l'état prêt sont conservées dans une seule liste que nous appelons la liste des événements en cours (CEL). Les entités migrent vers la CEL à partir de la liste des événements futurs, des listes de retard et des listes gérées par l'utilisateur (décrites ci-dessous). En outre, les entités clonées à partir de l'entité à l'état actif commencent généralement leur existence sur la CEL. Les entités de la CEL sont généralement classées dans l'ordre "premier entré, premier sorti" (FIFO). Certains outils logiciels fournissent un attribut Priority intégré qui permet de classer les entités de la CEL par ordre de priorité (les égalités étant résolues selon la méthode FIFO).
Liste des événements futurs - Les entités à l'état retardé appartiennent à une liste unique dans laquelle elles sont insérées au début de leur retard temporel. Cette liste, appelée ici liste des événements futurs (LEF), est généralement classée par ordre croissant de temps de déplacement des entités. Le temps de déplacement est le temps simulé auquel une entité est censée essayer de se déplacer à nouveau (la fin du temps de traitement d'un patient dans une clinique ou la fin du temps de traitement d'une pièce dans un système de fabrication, par exemple). Au moment de l'insertion de l'entité dans la FEL, le temps de déplacement de l'entité est calculé en ajoutant la valeur de l'horloge de simulation à la durée connue (échantillonnée) du délai basé sur le temps. Lorsqu'un PEM est terminé, le CUP règle (avance) la valeur de l'horloge sur le temps de déplacement de l'entité la mieux classée de la FEL (temps de déplacement le plus court). Cette entité est alors transférée de la FEL à la CEL, passant de l'état retardé à l'état prêt et préparant le terrain pour le début du prochain PEM. La déclaration précédente suppose qu'il n'y a pas d'autres entités sur la FEL dont l'heure de déplacement correspond à la valeur mise à jour de l'horloge. Dans le cas de liens de temps de déplacement, certains outils transfèrent toutes les entités liées au temps de la FEL à la CEL au cours d'un seul CUP, tandis que d'autres outils adoptent une approche "un seul transfert d'entité par CUP". Les langages qui fournissent des entités internes utilisent généralement la FEL pour prendre en charge les exigences temporelles de ces entités. (Le FEL comprend alors des entités internes et externes).
Listes de délais - Les listes (il peut y en avoir plusieurs) d'entités dans l'état de condition retardée sont appelées listes de délais. Ces entités attendent (par exemple, leur tour pour utiliser une machine) que leur retard soit résolu afin de pouvoir être transférées automatiquement dans l'état prêt sur la CEL. Les listes de retard, qui sont généralement créées automatiquement par le logiciel de simulation, sont gérées selon deux types d'attente. Si un retard peut être facilement relié aux événements du modèle susceptibles de le résorber, l'attente liée peut être utilisée pour gérer la liste des retards. Par exemple, supposons que l'état d'une machine passe d'occupée à inactive. En réponse, le logiciel peut automatiquement retirer l'entité en attente suivante de la liste de retards appropriée et la placer dans l'état prêt sur le CEL. L'attente liée est l'approche la plus répandue pour gérer les retards conditionnels. Si la condition de retard est trop complexe pour être facilement reliée aux événements susceptibles de la résoudre, il est possible d'utiliser l'attente par interrogation. Dans ce cas, le logiciel vérifie régulièrement si des entités peuvent être transférées d'une ou plusieurs listes de retards à l'état prêt. Les conditions de retard complexes pour lesquelles l'attente par interrogation peut être utile comprennent les combinaisons booléennes de changements d'état, par exemple, un poste d'amarrage est vide et un remorqueur est à l'arrêt.
Listes gérées par l'utilisateur Les listes(qui peuvent être nombreuses) d'entités à l'état dormant sont appelées listes gérées par l'utilisateur. Le modélisateur doit prendre des mesures pour établir ces listes et doit généralement fournir la logique nécessaire pour transférer des entités vers et depuis les listes. À l'exception des points de service très simples d'une ligne et d'un serveur dans un système, le logiciel sous-jacent n'a aucun moyen de savoir pourquoi les entités ont été placées dans les listes gérées par l'utilisateur en premier lieu, et n'a donc aucune base pour retirer automatiquement les entités de ces listes.
5 Mise en œuvre dans quatre outils
Les outils choisis ici pour commenter les particularités de la mise en œuvre sont AutoMod (Phillips 1997) ; SLX (Henriksen 2000 ; Schulze 2008) ; ExtendSim (Imagine That Incorporated 2015 ; Krahl 2012) ; et Simio (Kelton et al., 2014). Une version précédente de cet article (Schriber et Brunner 1996) couvrait SIMAN (Arena) (Kelton et al., 2014), ProModel (ProModel Corporation 2015), et GPSS/H (Henriksen et Crain 2000) de manière similaire. Nous pensons que ces outils sont représentatifs, mais ils ne sont évidemment pas exhaustifs (voir Swain 2015 pour une étude biennale des nombreux outils disponibles).
5.1 AutoMod
La liste des événements en cours est appelée Current Event List (CEL) dans AutoMod (voir Tableau 1). Les charges clonées, les charges quittant la FEL à la suite d'une mise à jour de l'horloge et les charges commandées à partir des listes de commande sont placées immédiatement sur la CEL. La règle d'insertion consiste à classer les charges par ordre de priorité (la priorité est un attribut intégré de chaque charge), puis par ordre de priorité (FIFO). Lorsque la CEL devient vide, la liste des délais de condition (voir ci-dessous) est vérifiée et les charges peuvent être transférées de cette liste à la CEL. Cette opération se poursuit jusqu'à ce que la CEL soit vide et qu'aucune charge ne puisse plus être transférée, auquel cas l'EMP est terminé et un CUP est lancé.
La liste des événements futurs (FEL) d'AutoMod est semblable aux listes d'événements futurs d'autres outils. Les charges arrivent sur la FEL en différé en exécutant une instruction WAIT FOR. AutoMod permet de spécifier des unités de temps (jour, heure, minute, seconde) dans une instruction WAIT FOR. Le CUP d'AutoMod retire plusieurs charges de la FEL si elles sont à égalité pour l'heure de déplacement la plus proche, en les insérant une par une à leur place appropriée sur la CEL. Il existe également des entités internes à AutoMod, appelées charges logiques, qui permettent notamment d'attendre sur la FEL le déclenchement des pauses programmées.
Les listes de retards (DL) sont des listes de charges en attente d'une capacité fournie par l'un des cinq éléments de capacité finie (ressource, file d'attente, bloc, compteur ou limite de trafic de processus ; voir le tableau 1). Chaque élément de capacité finie du modèle est associé à un DL. L'attente qui résulte de ces cinq cas est une attente liée. Chaque fois qu'une capacité est libérée, une charge de la tête du DL de l'élément est provisoirement placée sur la CEL (mais une place est laissée sur le DL). Lorsque cette charge est rencontrée pendant l'EMP, elle tente de réclamer la capacité demandée. Si elle échoue (par exemple parce qu'elle veut deux unités mais qu'une seule est libre), elle est renvoyée sur le DL à sa place initiale (il s'agit d'un comportement par défaut que le modélisateur peut outrepasser. Voir la section 6.2 pour une discussion plus générale). Immédiatement après cette évaluation, s'il reste de la capacité inutilisée, la charge suivante (s'il y en a) sur le DL concerné est placée sur le CEL. Le traitement de la charge active se poursuit alors, suivi de l'évaluation de la charge suivante placée provisoirement. Et ainsi de suite, provisoirement, pour chaque charge suivante (s'il y en a) pendant le PEM.
Pour l'attente conditionnelle en dehors des cinq cas décrits ci-dessus, AutoMod dispose d'une instruction WAIT UNTIL qui permet d'obtenir une attente par interrogation. Les conditions WAIT UNTIL peuvent être composées à l'aide d'opérateurs booléens. Si un chargement exécute une instruction WAIT UNTIL et que la condition est fausse, le chargement est placé sur une liste AutoMod globale unique appelée liste de temporisation des conditions (CDL). Après que la CEL a été vidée, mais avant que l'horloge de simulation ne soit mise à jour, toutes les charges de la CDL sont déplacées vers la CEL (en fait, la CDL "devient" la CEL) s'il y a eu un changement d'état pour au moins un élément du même type général (par exemple, une file d'attente) pour lequel une charge de la CDL est en attente (ce mécanisme est principalement "sondé", où le processus de sondage est déclenché par un changement d'état d'au moins un élément du même type général).
Si la CEL n'est plus vide, le PEM reprend. Si la condition pour laquelle une charge de la CEL est en attente n'est pas encore remplie, AutoMod déplace cette charge de la CEL vers la CDL. Dans certains cas, la CDL peut être vidée plusieurs fois au cours d'un EMP, jusqu'à ce que la CEL soit vidée sans qu'un changement d'état lié à une charge sur la CDL n'ait été déclenché. Un CUP se produit alors. En raison du risque de migration de listes répétitives avec WAIT UNTIL, le fournisseur d'AutoMod encourage l'utilisation de listes de commandes ou d'autres mécanismes de contrôle explicites pour gérer l'attente complexe.
AutoMod implémente l'état dormant avec des listes de commandes, qui sont des listes de charges gérées par l'utilisateur. Une fois qu'un chargement s'est inscrit sur une liste de commandes (en exécutant une action WAIT TO BE ORDERED), il ne peut être retiré que par un autre chargement (ou un autre élément actif du modèle, tel qu'un véhicule) qui exécute une action ORDER. Une action de commande peut spécifier une quantité de charges, ou une condition qui doit être remplie pour une charge donnée si cette charge doit être commandée, ou les deux. Les charges commandées avec succès sont placées immédiatement sur la CEL (une à la fois, selon la façon dont elles ont été choisies dans la liste de commandes, et classées sur la CEL par priorité, les égalités de priorité étant résolues selon la méthode FIFO). Les listes de commandes peuvent améliorer les performances par rapport à l'attente CDL, car les listes de commandes ne sont jamais analysées, sauf en cas de demande explicite. Les listes de commandes d'AutoMod présentent plusieurs particularités intéressantes, notamment : la possibilité pour un chargement de passer une commande ultérieure si la quantité commandée n'est pas satisfaite ; la possibilité pour un chargement d'une liste de commandes de passer à l'action suivante plutôt qu'à un processus (cette caractéristique est utile pour le transfert de contrôle) ; et la possibilité d'appeler une fonction pour chaque chargement de la liste de commandes (en utilisant l'action ORDER...SATISFYING).
AutoMod possède plusieurs structures de manutention qui sont intégrées au mouvement des charges. Pour les systèmes de véhicules, il existe trois autres types de listes (qui ne figurent pas dans le tableau 1). Les charges figurant sur les listes de charges prêtes (LRL) (une liste par système de véhicule) attendent d'être enlevées par un véhicule. Les charges réclamées (mais pas encore enlevées) par un véhicule résident sur la liste de réclamation du véhicule (VCL). Les charges réclamées qui ont été enlevées figurent sur la liste des véhicules embarqués (VOL) du véhicule. Le véhicule devient alors le "chargement" actif et se déplace parmi les listes d'AutoMod (FEL, CEL et éventuellement DL) plutôt que parmi les chargements eux-mêmes.
5.2 SLX
SLX est un langage hiérarchique dans lequel les primitives intégrées se situent à un niveau inférieur à celui de la plupart des autres langages de simulation, ce qui facilite la définition par l'utilisateur (ou le développeur) du comportement de nombreux éléments du système. Cette philosophie de conception permet à l'utilisateur (ou au développeur) de SLX de créer des outils de modélisation de niveau supérieur dont les constructions ont un comportement modifiable défini avec précision. Les équivalents des termes génériques pour les utilisateurs de SLX de bas niveau sont indiqués dans le tableau 2. Par exemple, SLX utilise des variables de contrôle pour agir comme des éléments de contrôle. Le modificateur "control" peut être attaché à une variable de n'importe quel type de données (entier, réel, chaîne, etc.). Une variable de contrôle peut être globale ou locale, déclarée dans la définition de la classe d'un objet. (Une variable déclarée dans une classe est un attribut dans d'autres outils).
SLX a deux types d'objets : Actifs et Passifs. Les deux se distinguent par la présence d'actions - déclarations exécutables - dans la définition de la classe d'un objet actif (même sans actions, les objets passifs sont utiles en eux-mêmes, fonctionnant comme des structures de données complexes définies par l'utilisateur). Le tableau 3 montre comment les outils de plus haut niveau basés sur SLX peuvent exploiter les capacités de définition de SLX.
La liste des événements d'actualité est appelée la chaîne des événements d'actualité (CEC) dans SLX. Les membres de la CEC portent le nom intéressant de Puck. Qu'est-ce qu'un Puck ? SLX dissocie le concept d'objet actif (avec ses données locales associées) d'un Puck, qui est l'"entité mobile" qui exécute les actions, transporte ses propres données d'ordonnancement d'entité et migre d'une liste à l'autre. Cette dissociation a pour effet qu'un seul objet peut "posséder" plus d'un Puck. Tous les Pucks appartenant à un seul Objet partagent les données locales de l'Objet (attributs). Par exemple, une application de cette caractéristique de "parallélisme local" (par rapport au "parallélisme global" offert par les actions "clone" ou "split" dans d'autres langages) est l'utilisation d'un deuxième Puck pour simuler un temps d'attente pendant que le Puck original attend une certaine condition. (Si la condition se réalise avant que le temps d'attente ne se soit écoulé, il n'y a pas d'attente ; dans le cas contraire, il y a une attente).
L'activation d'un nouvel objet crée un palet et le met en action. Dans de nombreux cas, aucun autre palet n'est jamais créé pour cet objet, et la combinaison d'un objet actif et de son palet forme l'équivalent d'une entité (les objets passifs n'ont pas d'actions et ne possèdent donc pas de palets). Les Pucks nouvellement activés, les Pucks quittant la FEC suite à une mise à jour de l'horloge et les Pucks réactivés (voir ci-dessous) sont placés sur la CEC, classés par ordre de priorité (FIFO). La CEC est vide lorsqu'un PEM se termine.
La chaîne d'événements futurs (FEC) du SLX est semblable aux listes d'événements futurs d'autres outils. Les palets arrivent sur la FEC en différé en exécutant une instruction ADVANCE. Le CUP SLX retire plusieurs palets de la FEC s'ils sont à égalité pour le temps de déplacement le plus précoce, et les insère un par un à la place qui leur revient sur la CEC. Étant donné que la fonctionnalité du noyau SLX n'inclut pas les temps d'arrêt ni même la génération répétitive de palets (arrivées programmées), toute l'activité sur la FEC SLX se déroule comme spécifié par le développeur du modèle SLX. Plus généralement, si un utilisateur utilise un modèle (ou un générateur de modèle) qui contient des primitives de niveau supérieur définies par un développeur, il y a de fortes chances que toutes sortes de choses se passent en coulisses, sans que l'utilisateur de niveau supérieur puisse les voir. Les listes de délais (DL) dans SLX sont des listes de palets qui attendent (via WAIT UNTIL) des changements d'état dans n'importe quelle combinaison de variables de contrôle et de la valeur de l'horloge de simulation. Un Puck en attente d'une condition composée impliquant deux variables de contrôle ou plus est répertorié sur plus d'une DL. Toutes les constructions de niveau supérieur définies par les développeurs peuvent utiliser ce mécanisme. Chaque variable de contrôle (qui peut être une variable locale, auquel cas il en existe une pour chaque objet de la classe) est associée à un DL distinct.
Un DL est classé par ordre d'insertion. Tous les palets d'un DL sont retirés chaque fois que la variable de contrôle associée change de valeur et sont insérés un par un dans la CEC. Les palets retirés qui attendent des conditions composées sont également provisoirement retirés de chacune des autres listes de délais auxquelles ils appartiennent. Au fur et à mesure que ces palets sont rencontrés sur la CCE pendant l'EMP, ceux qui ne passent pas leur WAIT UNTIL sont renvoyés à la (aux) liste(s) de délais pour les variables de contrôle qui contribuent encore à la fausseté de la condition. Pour les conditions qui incluent une référence d'horloge, le palet est inséré si nécessaire dans la FEC, sous réserve d'un retrait anticipé de la FEC si la condition devient vraie en raison d'autres changements de variables de contrôle. Ce mécanisme d'attente connexe de bas niveau basé sur les variables de contrôle est l'approche SLX par défaut pour modéliser tous les types d'états retardés de conditions simples ou composées.
SLX gère l'état dormant d'une manière unique. Au lieu de déplacer le Palet de l'état actif vers une liste gérée par l'utilisateur et de le suspendre, le tout en une seule opération, SLX décompose cette opération en deux parties. Tout d'abord, le Puck rejoint généralement un ensemble. Mais le fait de rejoindre un ensemble ne suspend pas automatiquement le Puck. Un Puck peut appartenir à n'importe quel nombre d'ensembles. L'appartenance à un ensemble permet simplement à tout autre Puck d'accéder aux Pucks membres. Pour passer à l'état dormant, un Puck exécute une instruction WAIT. Il est alors suspendu indéfiniment, en dehors de toute liste particulière, jusqu'à ce qu'un autre Puck identifie le Puck en attente et exécute une instruction REACTIVATE pour lui. Souvent, cet autre Puck scanne un ensemble pour trouver le Puck à RÉACTIVER, mais un ensemble n'est pas exactement la même chose qu'une liste gérée par l'utilisateur dans notre terminologie. Un Puck à l'état dormant peut n'être membre d'aucun ensemble (à condition qu'un pointeur vers lui ait été stocké quelque part) ou d'un ou plusieurs ensembles. Un développeur SLX peut facilement définir une construction de liste gérée par l'utilisateur, en utilisant les ensembles, WAIT et REACTIVATE comme blocs de construction, qui imite ceux d'autres langages ou offre ses propres caractéristiques uniques.
5.3 ExtendSim
ExtendSim (initialement appelé Extend) utilise une architecture basée sur les messages pour la simulation d'événements discrets. Différents types de messages sont utilisés pour programmer des événements, propulser des éléments (entités) dans un modèle, appliquer la logique incorporée dans un modèle et forcer le calcul. Les émetteurs et les récepteurs de messages sont des blocs (opérations), y compris le bloc exécutif (contrôleur principal). Dans ExtendSim, c'est l'exécution des blocs qui est programmée (lorsqu'un bloc s'exécute, par exemple, cela peut déclencher l'envoi de messages dans les deux sens entre les blocs, ce qui a pour effet de déplacer un élément le long de son chemin basé sur les blocs dans un modèle). Le tableau 4 résume les équivalents ExtendSim des termes introduits dans la discussion générique précédente.
Un bloc est la construction de base de la modélisation dans ExtendSim. Chaque bloc possède une icône, des connecteurs de transmission de messages, une capacité de dialogue et un code définissant le comportement. Les blocs de résidence peuvent contenir des éléments pendant que le temps simulé s'écoule, alors que les blocs de passage ne le peuvent pas (les éléments passent par les blocs de passage en un temps simulé nul). Les modèles peuvent être construits en sélectionnant des blocs préprogrammés dans les bibliothèques de blocs d'ExtendSim. Le modélisateur peut également modifier le code source donné pour les blocs de la bibliothèque (tous les blocs de la version de base d'ExtendSim sont open source). Enfin, le modélisateur peut créer des blocs personnalisés à partir de zéro (blocs programmés par l'utilisateur) en utilisant les outils de développement fournis par ExtendSim.
ExtendSim utilise un tableau de temps pour planifier les futures exécutions de blocs. Pour un modèle donné, le tableau des temps contient un ou plusieurs éléments pour chaque bloc. Un élément de la matrice de temps enregistre l'heure future à laquelle l'exécution de ce bloc a été programmée. La possibilité pour un bloc d'avoir plus d'un élément de la grille de temps est une amélioration de la version 7 du langage (la version 8 est la version actuelle). Cette fonctionnalité peut s'avérer utile lorsqu'un bloc comporte plusieurs événements différents, comme par exemple dans la modélisation de convoyeurs.
Les blocs dont l'exécution future n'est pas encore programmée sont temporairement "occultés" par l'enregistrement de valeurs temporelles arbitrairement élevées dans le tableau des temps. Les blocs de résidence qui peuvent contenir plusieurs éléments gèrent les temps d'événement correspondants en interne, seul le temps d'événement le plus précoce du bloc étant conservé dans le tableau des temps. Il s'agit d'une liste d'événements en deux étapes, car les blocs peuvent contenir des listes chaînées optimisées qui servent de listes d'événements futurs. L'exécution d'un bloc peut entraîner la programmation de l'exécution de blocs ultérieurs. Par exemple, si des messages sont transmis et qu'un élément entre dans un bloc de résidence de capacité unitaire conçu pour conserver l'élément jusqu'à ce qu'un certain temps simulé se soit écoulé, la valeur de l'entrée du tableau des temps pour ce bloc sera définie en conséquence.
Le nombre d'îlots dans un modèle donné est constant, ce qui signifie que le tableau des temps est de taille fixe et relativement petite. En raison de sa petite taille, le tableau des temps est parcouru pour trouver l'heure de l'événement imminent ; il n'est pas conservé dans un ordre trié. Il est donc facile pour un bloc de modifier l'heure de l'événement, car il n'est pas nécessaire d'effectuer une recherche dans la liste des événements. Le tableau des heures suivantes est utilisé pour gérer l'exécution des blocs dont l'exécution a été programmée via le tableau des heures. Le tableau des heures suivantes est rempli juste avant une phase d'exécution de bloc (l'équivalent d'un PEM dans ExtendSim) de la manière suivante. À chaque CUP, le tableau des temps est consulté pour trouver l'heure future la plus proche à laquelle l'exécution d'un bloc a été programmée. Les identifiants du bloc correspondant (ou des blocs, en cas d'égalité de temps) sont alors placés dans le tableau des temps suivants. La phase d'exécution du bloc (BEP) commence alors, avec l'envoi par l'exécutif de la messagerie du bloc le plus qualifié dans le tableau des temps suivants pour commencer son exécution.
Le tableau des événements en cours est utilisé pour gérer la reprise de l'exécution des blocs dont l'exécution a été temporairement suspendue au cours d'une phase d'exécution de bloc. Par exemple, supposons qu'un bloc envoie un message et que le bloc récepteur réponde (retourne le contrôle) immédiatement au bloc émetteur (même si le bloc récepteur doit encore effectuer un traitement supplémentaire à l'instant simulé en question). Dans ce cas, l'identifiant du bloc récepteur est ajouté au tableau des événements en cours. Lorsque l'exécution de la séquence d'envoi est terminée, l'exécutif envoie un message à la séquence la plus qualifiée du tableau des événements en cours pour qu'elle reprenne son exécution. Le tableau des événements en cours finit par se vider. L'exécutif se tourne alors à nouveau vers le tableau des événements suivants et envoie un message au bloc le plus qualifié pour qu'il commence à s'exécuter.
Au cours d'une phase d'exécution de bloc, les blocs peuvent se programmer pour être exécutés à l'heure simulée actuelle (c'est-à-dire pendant la MPE en cours). Le tableau des événements en cours entre également en jeu pour gérer l'exécution des blocs dans de tels cas. Par exemple, si un bloc à capacité limitée devient incomplet à la suite de l'exécution d'un autre bloc, le bloc incomplet inscrit son identifiant dans le tableau des événements en cours. L'exécutif enverra plus tard (mais au même moment simulé) un message au bloc pour qu'il commence à s'exécuter. Le bloc essaiera alors d'attirer à lui les éléments (s'il y en a) qui attendaient d'entrer dans le bloc (dans ExtendSim, les éléments peuvent être à la fois tirés et poussés à travers un modèle). Lorsque le tableau des événements en cours et le tableau des temps suivants sont tous deux vides, la phase d'exécution du bloc d'ExtendSim prend fin. La CUP et la BEP suivantes ont alors lieu, et se répètent jusqu'à ce qu'une condition de fin de simulation soit remplie. Les listes de retard sont constituées d'éléments retardés dans les blocs de résidence, qui attendent leur tour pour être tirés ou poussés dans le(s) bloc(s) suivant(s). La transmission de messages est utilisée pour effectuer les opérations de traction et de poussée lorsque les conditions du modèle le permettent. ExtendSim assure la gestion de l'attente de ces éléments en fonction des critères suivants : premier entré, premier sorti (FIFO), dernier entré, premier sorti (LIFO), priorité, attribut, renégociation, correspondance et équation. L'attente de la résolution des conditions composées est normalement réalisée dans ExtendSim en combinant de manière appropriée les blocs et en exploitant l'architecture basée sur les messages d'ExtendSim. Nous considérons qu'il s'agit d'une forme d'attente liée, car c'est un changement dans une valeur sous-jacente qui déclenche une réévaluation de la condition qui a provoqué l'attente en premier lieu.
En raison de l'architecture de messagerie d'ExtendSim, l'attente par interrogation n'est généralement pas nécessaire. Un message est envoyé lorsqu'une valeur change et toutes les conditions sont évaluées à ce moment-là. L'attente d'un événement basé sur l'horloge peut être réalisée en utilisant un bloc qui planifie des événements, par exemple, Shift ; Lookup Table ; Equation. Ces blocs envoient un message à des heures programmées. L'attente par interrogation est toutefois possible en utilisant le bloc Gate et en sélectionnant l'option "Check demand at each event" (vérifier la demande à chaque événement).
Le modélisateur peut utiliser des blocs programmés par l'utilisateur pour créer et gérer des listes de sa propre conception. Le code des blocs personnalisés peut être écrit pour atteindre les objectifs du modélisateur à cet égard, tout comme le code des blocs préprogrammés d'ExtendSim a été écrit pour spécifier le comportement de ces blocs. ExtendSim fournit des fonctions qui peuvent être utilisées par les blocs pour partager des listes (tableaux) avec d'autres blocs, ce qui permet une gestion personnalisée des listes dans les modèles.
5.4 Simio
Simio est un langage orienté objet dans lequel toutes les constructions de modèles sont des objets Simio dérivés du même objet de base. La plupart des utilisateurs de Simio utiliseront principalement des objets de la bibliothèque standard de Simio pour construire des modèles. Les entités, les ressources, les serveurs, les stations de travail, les sources, les puits, les nœuds et les connecteurs sont des objets couramment utilisés dans la bibliothèque standard. Simio est basé sur des processus composés d'étapes individuelles exécutées par des jetons. Les comportements des objets de la bibliothèque standard sont implémentés (par le concepteur de l'objet) à l'aide de processus. Bien que la plupart des modèles soient construits à l'aide de ces objets de haut niveau, les utilisateurs (et les développeurs) ont un accès complet aux processus Simio et peuvent développer des modèles complets ainsi que des objets réutilisables à l'aide des processus Simio. De plus, les utilisateurs peuvent augmenter le comportement des Objets existants en utilisant les processus Add-on et/ou en sous-classant les Objets existants. Les modèles Simio eux-mêmes sont en fait des Objets qui peuvent être intégrés dans d'autres modèles. La structure objet de Simio facilite le développement de bibliothèques d'objets personnalisées qui peuvent simplifier le processus de modélisation dans différents domaines d'application.
Les équivalents des termes génériques pour les utilisateurs de Simio sont présentés dans le tableau 5. Notez que tout objet Simio peut agir en tant que ressource en définissant la propriété "Objet Ressource" à True. L'objet Ressource de la bibliothèque standard est analogue à une ressource dans le contexte de ce document. La relation entre les objets entités Simio et les jetons est similaire à la relation entre l'objet actif et les palets dans SLX. En particulier, lorsque les objets interagissent (par exemple, un objet Entité se déplaçant à travers un objet Serveur pour faire la queue et accéder à une ressource à capacité finie), un ou plusieurs jetons associés à ces objets exécutent les processus (séquences d'étapes) qui comprennent le comportement des objets. La possibilité d'avoir plusieurs jetons exécutant différents processus pour le compte d'un même objet offre une grande souplesse de modélisation.
Les propriétés et les états des objets servent d'éléments de contrôle Simio. Les propriétés et les états sont tous deux des attributs des objets. Les propriétés sont définies au début d'une exécution et ne changent pas pendant l'exécution, tandis que les états peuvent être définis et modifiés à tout moment pendant l'exécution d'un modèle. Les propriétés sont généralement utilisées lors de la construction du modèle et de l'expérimentation, tandis que les états sont généralement utilisés lors de l'exécution du modèle pour contrôler le flux et/ou suivre et rapporter les statistiques. Les événements sont un peu plus abstraits dans Simio que dans d'autres logiciels. Dans Simio, les événements sont caractérisés par un temps d'exécution (le temps de simulation lorsque l'événement se produit), une référence à un appel de procédure (à exécuter lorsque l'événement se produit), et une référence à un Objet (qui fournit des données supplémentaires à la procédure, si nécessaire). L'objet référencé d'un événement peut être ou non une entité visible par l'utilisateur ou un jeton associé. Pour les événements associés à un mouvement d'entité, l'objet de l'événement fait référence à un jeton associé à l'entité et la procédure de l'événement exécute une étape du processus (appelée événement "jeton arrivé à une étape"). La plupart des événements qui se produisent au cours de l'exécution d'un modèle sont de ce type. Les exemples d'autres événements internes incluent les événements de fin d'exécution, les événements de franchissement d'un seuil d'état, les événements de collision d'entités, etc. Simio prend également en charge les événements définis par l'utilisateur qui peuvent être déclenchés, attendus et utilisés pour déclencher des processus.
Pendant l'exécution du modèle, une fois que le CUP se produit et que Simio entre dans l'EMP, tous les événements programmés pour le temps de simulation en cours sont retirés du tas d'événements futurs (FEH) et sont placés dans la liste des événements en cours (CEL). La structure de données du tas est utilisée pour les événements futurs en raison de son efficacité informatique. Simio exécute tous les événements de la CEL (de manière séquentielle) avant d'avancer le temps de simulation jusqu'à l'événement suivant. Les événements de la CEL sont classés par ordre de priorité selon le type d'événement (normal, précoce et tardif). Les procédures d'événement peuvent créer d'autres événements (des événements futurs ainsi que des événements programmés pour le temps de simulation actuel), mettre à jour l'état du système, déclencher l'enregistrement de statistiques et mettre fin à l'exécution du modèle. Les files d'attente d'allocation sont des listes d'entités en attente de ressources. Lorsqu'une ressource devient disponible, Simio met en œuvre un processus de réaffectation standard selon lequel la "première" entité de la file d'attente d'allocation (déterminée par la règle de classement de la file d'attente) est placée en tête de la CEL et l'entité qui a libéré la ressource est traitée par étapes jusqu'à ce qu'elle atteigne un délai (soit un délai temporel, soit un délai de condition, soit un stockage spécifié par l'utilisateur). Dans le cadre de ce processus, la dernière entité qui a libéré la ressource est traitée jusqu'à ce qu'elle atteigne un délai et la dernière entité à laquelle la capacité de la ressource a été allouée est la première à commencer le traitement (au même moment de la simulation). Simio implémente l'état dormant à l'aide d'éléments Storage ou Station. Un élément Storage implémente une file d'attente logique où les objets peuvent être "placés" par l'utilisateur en vue d'un retrait ultérieur. Les éléments de stockage n'ont pas d'emplacement physique et un objet donné peut résider simultanément dans plusieurs éléments de stockage. Un élément Station, quant à lui, définit un emplacement physique à capacité limitée où des objets d'entité peuvent être stockés en vue de leur retrait et de leur traitement ultérieurs.
6 Importance de l'élément
Dans les sections 6.1 à 6.5, nous décrivons des situations qui révèlent certaines différences pratiques dans les particularités de mise en œuvre entre Arena (qui utilise le langage et le processeur SIMAN), ProModel, GPSS/H, AutoMod, SLX, ExtendSim et Simio. Aucune des approches alternatives mentionnées n'est intrinsèquement "bonne" ou "mauvaise". Le modélisateur doit simplement être conscient de l'alternative en vigueur dans le logiciel de simulation utilisé et travailler avec elle pour produire le résultat souhaité. Dans le cas contraire, il est possible de mal modéliser une situation sans s'en rendre compte. Dans la section 6.6, nous expliquons comment la connaissance des éléments internes du logiciel est nécessaire pour utiliser efficacement les outils de vérification des modèles. Enfin, à la section 6.7, nous soulignons que la connaissance des éléments internes aide à comprendre le contrôle des performances.
6.1 Essayer de recapturer une ressource immédiatement
Supposons qu'un travail dans un atelier flexible libère une machine (pour laquelle d'autres travaux sont en attente), puis, dans le cadre de sa prochaine étape, décide de recapturer cette machine. Le travailleur va-t-il reprendre la machine immédiatement ou un travailleur en attente (même s'il est moins qualifié ou tout aussi qualifié) va-t-il s'emparer de la machine à la place ? Ce qui est intéressant ici, c'est l'ordre des événements qui suivent la libération d'une ressource. Il existe au moins trois possibilités : (1) l'événement de libération de la ressource s'accompagne du choix immédiat du prochain utilisateur de la ressource, sans que l'entité qui libère la ressource n'ait encore effectué sa prochaine étape ; (2) le choix du prochain utilisateur de la ressource est différé jusqu'à ce que l'entité qui libère la ressource soit potentiellement devenue un concurrent ; et (3) sans tenir compte des autres concurrents, l'entité qui libère la ressource récupère immédiatement la ressource inutilisée. Arena, ExtendSim et Simio (le comportement par défaut) implémentent (1). ProModel met en œuvre (2). GPSS/H et AutoMod implémentent (3) par défaut. Dans SLX, en utilisant une variable de contrôle comme état de ressource, le résultat est également (3). (Dans certains outils, les modélisateurs peuvent mettre en œuvre des constructions de ressources de niveau supérieur ou utiliser des instructions supplémentaires afin que les modèles se comportent selon le choix du modélisateur à cet égard).
6.2 Le premier de la file est toujours retardé
Supposons que deux entités retardées par une condition attendent dans une liste de retard parce qu'aucune unité d'une ressource particulière n'est inactive. Supposons que la première entité ait besoin de deux unités de la ressource, alors que la seconde n'en a besoin que d'une. Supposons maintenant qu'une unité de la ressource devienne inactive. Les besoins de la première entité de la liste ne peuvent pas encore être satisfaits, mais ceux de la seconde entité peuvent l'être. Que se passera-t-il ? Il y a au moins trois possibilités : (1) aucune entité ne réclame l'unité de ressource inactive ; (2) la première entité réclame l'unité de ressource inactive et attend une deuxième unité ; et (3) la deuxième entité réclame l'unité de ressource inactive et passe à l'état prêt. Comme dans la section 6.1, chacune de ces alternatives entre en jeu dans les outils considérés ici. Arena (SEIZE) et ProModel (GET ou USE) implémentent respectivement (1) et (2) par défaut. AutoMod (GET ou USE), GPSS/H (ENTER ou TEST) et SLX (WAIT UNTIL sur une variable de contrôle) implémentent (3) par défaut. ExtendSim implémente également (3) par défaut. Mais ExtendSim donne au modélisateur le choix d'implémenter localement (1) pour les ressources spécifiées par le modélisateur. Pour ce faire, le modélisateur coche l'option "N'allouer le pool de ressources qu'à l'élément le mieux classé" pour chacune de ces ressources. Simio permet au modélisateur de sélectionner l'option (1) ou (2) en utilisant la propriété Nombre d'objets et l'option "répétition des saisies de ressources" avec l'étape Saisir.
6.3 Céder le contrôle temporairement
Supposons que l'entité active veuille céder le contrôle à une ou plusieurs entités en état prêt, mais qu'elle doive ensuite redevenir l'entité active avant que l'horloge de la simulation ne soit avancée. Ce scénario peut se produire, par exemple, si l'entité active a ouvert un interrupteur permettant à un ensemble d'autres entités de se déplacer au-delà d'un point du modèle, et qu'elle doit ensuite refermer l'interrupteur une fois que le mouvement vers l'avant des autres entités a été accompli. Prenons l'exemple d'un groupe de cartons de crème glacée au parfum identique qui doit être transféré d'un point d'accumulation à un convoyeur menant à une opération d'emballage d'un parfum par carton.
Dans Arena, l'effet peut être obtenu approximativement avec un DELAY qui place l'entité active dans un état temporisé pendant un temps simulé arbitrairement court mais non nul. Dans ProModel, "WAIT 0" peut être utilisé pour remettre l'entité active sur le FEC. L'entité sera ramenée plus tard (à l'heure de l'horloge murale, mais à la même heure simulée) par le CUP à l'état actif. Dans le GPSS/H, le Xact actif (transaction) peut exécuter un bloc YIELD pour passer immédiatement de l'état actif à l'état prêt (positionné en dernier dans sa classe de priorité) et forcer un redémarrage du balayage de la CEC. Les Xact CEC de rang supérieur ont alors une chance de devenir actifs avant que le Xact cédant ne redevienne actif au même moment simulé. SLX (YIELD), AutoMod (Wait For 0) et Simio (Delay step with Math.Epsilon) fournissent tous des solutions dans lesquelles le Puck (SLX), le Load (AutoMod) ou le Token (Simio) actif est déplacé à l'arrière de sa classe de priorité sur la CEC, où il attend de redevenir l'entité active avant que l'horloge n'ait été avancée. Dans ExtendSim, "céder et éventuellement reprendre" fait partie de l'architecture. Un message est envoyé par le connecteur de bloc approprié lorsqu'un élément entre ou sort d'un bloc. Ce message se propage à d'autres blocs connectés, modifiant éventuellement l'état du système ou déplaçant des éléments d'un bloc à l'autre. Lorsque le bloc d'origine reçoit la réponse, il continue à traiter l'élément d'origine.
6.4 Conditions relatives à l'horloge
Chaque langue offre une capacité de temporisation pour l'attente FEL. Cela fonctionne bien lorsqu'une entité doit attendre qu'une valeur d'horloge connue soit atteinte. Mais qu'en est-il si une entité doit attendre une condition composée impliquant l'horloge, telle que "attendre jusqu'à ce qu'un tampon d'entrée spécifié soit vide ou qu'il soit exactement 17h00" ? Une approche classique consiste à cloner une entité fictive ("shadow") pour effectuer l'attente basée sur le temps. La gestion de ces entités fictives peut être lourde, en particulier pour les règles très complexes. Le ProModel n'utilise pas l'attente par interrogation, de sorte qu'une entité fictive serait la meilleure approche disponible. (Sinon, la condition ne serait pas vérifiée tant que l'autre composant de la condition composée n'aurait pas changé de valeur). ExtendSim n'utilise pas non plus l'attente par interrogation, de sorte qu'une situation similaire s'applique à ExtendSim et que tout bloc capable de planifier des événements peut être utilisé. Avec Simio, les objets entités peuvent avoir plusieurs jetons associés, chacun attendant un composant différent de la condition composée. Le concept est similaire à l'utilisation d'une entité fictive, mais ne nécessite pas d'entité supplémentaire.
En présence d'un mécanisme d'attente par interrogation, si une seule entité tente d'attendre une condition composée impliquant l'horloge, un problème intéressant peut se poser. En effet, l'heure d'interrogation suivante peut ne pas correspondre à l'heure de l'horloge cible. Arena et AutoMod détectent la véracité des conditions composées par le biais de leurs mécanismes d'interrogation de fin d'EMP. GPSS/H détecte également la vérité via sa version de l'attente par interrogation (refusalmode TEST). Mais en l'absence de quelque chose qui attend sur la FEL jusqu'à exactement 17h00 (c'est-à-dire l'approche recommandée ci-dessus pour ProModel, ExtendSim et Simio), ces trois outils sont soumis à la possibilité que le premier PEM qui trouve la condition vraie se produise lorsque l'horloge a une valeur supérieure à 17h00. Cela peut être problématique si l'exactitude de 17 heures est importante.
SLX reconnaît l'horloge comme une cible d'attente connexe. Un délai d'attente utilisant une valeur d'horloge future d'une manière qui contribue à la fausseté de la condition entraînera la programmation du palet sur la FEL pour forcer un EMP à l'heure précise référencée. Cela résout le problème de l'heure supérieure à l'heure souhaitée. Notez que ce Puck peut également être en attente sur une ou plusieurs listes de retard.
6.5 Attente en mode mixte
Supposons que de nombreuses entités attendent de capturer une ressource particulière, tandis qu'une entité contrôleur créée par l'utilisateur attend que la condition composée "l'état de l'équipe est 'off-shift' et le nombre d'attente est inférieur à six et la ressource n'est pas en cours d'utilisation" prenne une certaine mesure (telle que la fermeture de la ressource, dans les langages qui permettent aux entités définies par l'utilisateur de fermer des ressources ; ou l'affichage d'un message d'état). Comment pouvons-nous garantir que l'entité contrôleur sera en mesure de "couper devant" les entités en attente au moment simulé approprié (avant que la ressource inactive ne soit recapturée) ?
Une façon de gérer ce problème serait d'utiliser les priorités des entités dans les langages qui offrent cette fonctionnalité. Cependant, comme décrit ci-dessous, cela pourrait ne pas fonctionner même si le contrôleur a une priorité relativement élevée. La question clé est la méthode utilisée pour mettre en œuvre l'attente. Si elle est "liée" pour les entités qui attendent de capturer la ressource et "interrogée" pour l'entité du contrôleur qui attend la condition composée (c'est ce que nous entendons par le terme "attente en mode mixte"), les choses peuvent se compliquer. Chaque fois que la ressource se libère, une nouvelle entité est sélectionnée à partir d'une liste de délais immédiatement dans Arena et via le CEL dans AutoMod, dans les deux cas avant la vérification de la fin de l'EMP pour les conditions d'attente interrogées (et donc en ignorant la priorité de l'entité du contrôleur). Il existe des moyens de contourner ce problème, par exemple en utilisant un type d'opération différent pour forcer les entités souhaitant utiliser la ressource à attendre.
Dans le système GPSS/H, avec un contrôleur Xact à priorité élevée dans un bloc TEST en mode refus, le contrôleur attend à l'avant de la CEC. La facilité RELEASE déclenche un redémarrage du balayage et le contrôleur fait son travail. Dans le ProModel, il n'y a pas d'attente par sondage, mais il peut y avoir une attente liée à des conditions composées impliquant des variables. Les variables doivent être définies et manipulées pour chaque élément de la condition booléenne et, pour assurer une concurrence égale, les entités qui attendent de capturer la ressource peuvent également devoir utiliser WAIT UNTIL au lieu de GET ou USE. Une autre possibilité avec ProModel serait de faire en sorte que l'entité qui libère la ressource effectue immédiatement une vérification de l'état (devenant ainsi un substitut du contrôleur). Cela est possible grâce à la méthode de sélection différée utilisée par ProModel (voir section 6.2).
Dans l'attente connexe de SLX, un palet en attente d'une condition composée sera enregistré sur les listes de retard des variables de contrôle (et seulement de celles-là) qui contribuent à la fausseté de la condition. L'architecture SLX (dans laquelle seules les variables de contrôle globales ou locales et l'horloge peuvent être référencées dans toute sorte d'attente conditionnelle au niveau le plus bas) garantit qu'il y aura déjà des variables sous-jacentes aux changements d'état surveillés. Le modélisateur les définit comme des variables de contrôle.
Comme avec ProModel et SLX, ExtendSim utiliserait l'attente liée pour détecter et répondre immédiatement à un changement dans la condition composée. Comme le changement d'état de la ressource est immédiatement diffusé sous forme de message avant que la ressource ne soit réaffectée, ce message peut être utilisé pour contrôler la séquence et la logique de la sélection des éléments. Une ressource n'est pas allouée s'il n'y a pas de place en aval pour un élément et si la ressource n'est pas disponible, de sorte que le blocage du chemin de sortie d'une file d'attente empêchera l'allocation de la ressource.
Dans Simio, les objets ressources peuvent avoir leur propre logique implémentée en utilisant des processus complémentaires, il n'est donc pas nécessaire d'utiliser des "entités contrôleurs" pour implémenter le mécanisme de contrôle. Dans ce cas, les processus complémentaires "Hors équipe" et "Libéré" peuvent être utilisés pour vérifier la condition complexe impliquant l'état de l'équipe, la taille de la file d'attente et l'état de la ressource. Il est à noter que cela équivaut à une attente connexe dans la mesure où la condition n'est vérifiée que lorsque la ressource n'est plus en service et/ou lorsqu'une unité de capacité est libérée.
6.6 Vérification du modèle interactif
Nous allons maintenant expliquer brièvement pourquoi une compréhension détaillée du "fonctionnement des logiciels de simulation" permet de vérifier de manière interactive le comportement du modèle de simulation. En général, les modèles de simulation peuvent être exécutés de manière interactive ou en mode batch. Les exécutions interactives sont utiles pour contrôler (vérifier) la logique du modèle pendant la construction du modèle et pour dépanner un modèle en cas d'erreurs d'exécution. Le mode batch est ensuite utilisé pour effectuer des exécutions de production.
Les exécutions interactives placent une loupe sur une simulation pendant qu'elle s'exécute. Le modélisateur peut suivre l'entité active pas à pas et afficher les listes d'événements actuels et futurs, les listes de retards et les listes gérées par l'utilisateur, ainsi que d'autres aspects du modèle. Ces activités fournissent des informations précieuses sur le comportement du modèle au modélisateur qui connaît les concepts sous-jacents. Sans ces connaissances, le modélisateur risque de ne pas tirer pleinement parti des outils interactifs du logiciel ou, pire encore, de ne pas les utiliser.
6.7 Questions de performance
Les expériences de simulation peuvent consommer beaucoup de temps d'ordinateur. Toutes choses égales par ailleurs (y compris les compétences du modélisateur), les besoins en temps d'ordinateur dépendent de la conception et de la mise en œuvre du logiciel utilisé pour construire les modèles. La performance est une question suffisamment importante pour motiver certains logiciels de simulation (par exemple, ExtendSim, SLX et Simio) à fournir des profileurs de performance qui, par exemple, peuvent produire des histogrammes montrant où le temps de l'unité centrale est passé pendant l'exécution du modèle.
Remerciements
La plupart des informations contenues dans ce document ont été fournies par le personnel des fournisseurs. Les auteurs remercient Deb Sadowski, Vivek Bapat, Charles Harrell (ProModel), Kenneth Farnsworth et Tyler Phillips (AutoMod), Robert C. Crain et James O. Henriksen (GPSS/H et SLX), David Krahl (ExtendSim), ainsi que David T. Sturrock et C. Dennis Pegden (tous deux à l'origine chez Arena/SIMAN, et maintenant chez Simio) pour leur soutien.