État d’un simulateur

Les modèles de simulation, quel que soit le progiciel utilisé, utilisent à peu près les mêmes éléments de base (à la terminologie près) :

- Entités : ce sont les objets circulant du modèle – chaque entité a une identification unique ;

- Attributs : chaque entité possède un nombre fini identique d’attributs. Chaque attribut a un identifiant unique, et possède une valeur (entier, réel, chaine de caractères, etc.) ;

- Files d’attente : elles permettent de stocker les entités dans un certain ordre – elles possèdent un identifiant unique, une règle de gestion (FIFO, LIFO, etc.) et une liste ordonnée des identifiants des entités contenues dans cette file ;

- Transporteurs : permettent de modéliser des transports d’entité par unités indépendantes – ils possèdent un identifiant unique, un statut (occupé, libre, etc.), une position sur le réseau, une destination et éventuellement un identifiant d’entité contrôlante s’il est actuellement piloté ;

- Convoyeurs : permettent de modéliser un transport d’entités à vitesse constante sur un chemin prédéfini – ils possèdent un identifiant unique, un statut (arrêté, démarré, etc.), une longueur et une liste de toutes les entités qu’ils transportent avec la distance restant à parcourir associée ;

- Variables : sont des données globales au modèle. A l’inverse des attributs, elles possèdent à un instant donné une valeur unique. Chaque variable a un identifiant unique, et possède une valeur (entier, réel, chaine de caractères, etc.) ;

- Ressources : sont des objets pouvant être réservées par les entités. Elles ne sont dépendantes des entités que par le fait que ce sont elles qui les réservent ou les libèrent – sans que ce soit obligatoirement la même qui fasse les deux.

La Figure 17 résume tout ceci et présente une modélisation des liens entre ces éléments sous la forme d’un diagramme de classe UML. Il est important de noter que ce méta-modèle ne prend pas en compte la partie « statistiques » inhérente à tout modèle de simulation, partie qui n’a pas encore été complètement étudiée dans ces travaux. En effet, il semble que les statistiques soient reconstructibles à partir de leurs valeurs initiales et de leur valeur en fin de simulation. Prenons l’exemple d’un taux d’utilisation de ressource. S’il vaut T1 à la date D1 d’initialisation de la simulation, et qu’à la fin de cette simulation, on relève un taux T2 sur une durée de simulation D2. La durée globale de fonctionnement de la ressource est bien et le taux global peut s’écrire . On pourrait faire un raisonnement analogue pour la mesure d’un MFT (Mean Flow Time). N’ayant pas étudié cette possibilité à l’ensemble des statistiques envisageables dans une simulation, nous ne développerons pas plus cette partie qui n’entrera donc pas en ligne de compte dans le reste de nos travaux.

Pour assigner l’état d’un simulateur à une date donnée, il faut donc forcer (assigner à une valeur donnée) l’état de l’instance de la classe Modèle correspondante. Pour cela, il faudra forcer l’état des instances de toutes les classes qui lui sont reliées : pour chaque modèle, l’état sera donc décomposé en six parties distinctes.

La Figure 18 présente l’état obtenu en arrêtant un modèle comportant 3 variables, 3 ressources, 2 files d’attente, 2 convoyeurs et 3 transporteurs à une date aléatoire.

Si ceci était le modèle de simulation en ligne, il est nécessaire de pouvoir complètement reconstruire ces données à partir de celles de l’atelier. Nous proposons de formater ces données en autant de fichiers de données intermédiaires qui seront lus par le simulateur au moment de son utilisation. Ce choix est guidé par le fait que tous les logiciels actuels savent lire et écrire de façon relativement identique dans des fichiers texte. Chaque fichier contiendra les informations relatives à une classe définie ci-dessus.

Figure 17 Méta-modélisation UML d'un modèle de simulation

Lorsque le simulateur est arrêté pour nous permettre d’enregistrer son état (Figure 18), les entités ne peuvent être que : dans une file d’attente, assignées à un transporteur, sur un convoyeur, dans une machine (caractérisé par la réservation d’une ressource) ou dans une partie logique de la programmation. Cette dernière catégorie est représentée par le fichier Entités. Des points d’interrogation ont été mis dans ce fichier, car il est en général impossible d’obtenir simplement toutes les informations nécessaires au traitement de ces entités. Par exemple, sur Arena, une entité de ce type est dans un bloc Delay, et va bientôt sortir. On peut savoir quand elle va sortir, mais il ne nous a pas été possible de développer une méthode générique permettant de connaitre, à coups sûr, sa prochaine destination. Au contraire, des progiciels tels Quest ou Witness ont une structure qui ne laisse pas cette ambiguïté : les « parts » ou « articles », qui jouent le rôle d’entités, sont toujours dans des endroits identifiables du modèle (stocks, machines, etc.).

De plus, ces entités n’ont en général pas leur équivalent dans l’atelier, ce qui rend impossible leur connexion avec le système réel. De ce fait, il est impossible de prendre en compte de telles structures de modèles et de les initialiser avec les données de l’atelier.

Modèle Identifiant Variables Identifiant Valeur Ressources Identifiant Quantité libre Quantité réservée Entités Identifiant Transporteurs Identifiant Statut Position Destination Entité contrôlante Convoyeurs Identifiant Statut Longueur Liste 1 Attributs Identifiant Valeur n 0..1 0..1 0..m 0..1 0..k * * * * Files d’attente Identifiant Classement 0..1 * * 1 1 1 1 1 1

Figure 18 L'état d'un simulateur II.2.2.3 Les informations dans l’atelier

Reprenons l’exemple décrit Figure 18 et remontons jusqu’à l’atelier. Si ces fichiers sont l’état initial de la simulation, alors les informations qu’ils contiennent représentent l’état de l’atelier réel. Ainsi, il y a un produit sur le convoyeur n°2, à une distance de 31 unités de

Variables