Modélisation du simulateur

Après avoir construit un observateur, nous avons développé une application d’aide à la décision permettant de valider notre approche. Nous avons choisi de traiter la première décision évoquée dans ce chapitre (paragraphe IV.2.1) sous Arena. Le principe est d’aider le

pilote de la production dans le paramétrage d’un ordre de fabrication. Notre application permettra, à la saisie d’un ordre, de calculer une date de fin estimée de tous les ordres en cours et en préparation (saisis mais pas encore lancés). Ainsi, l’opérateur pourra tester l’influence du nombre de palettes impliquées dans cet ordre sur la date de fin de l’ensemble des ordres.

Figure 53 Algorithme de sauvegarde de l’état de l’observateur

Nous avons construit un modèle dédié à cette application, et qui a donc besoin d’un nombre minimal de paramétrage extérieur pour fonctionner. De ce fait, dès qu’il reçoit une notification sous forme de socket de la part du MES (Figure 41), le modèle va directement lire au niveau de la base de donnée du MES par requêtes SQL la liste des ordres de fabrication en cours ou en préparation et toutes les données de production nécessaires à la simulation (répartition des opérations sur les postes, temps opératoires, temps de réglages, etc.). L’observateur met également à sa disposition une copie de son état sous forme de fichiers textuels, tels que définis au Chapitre II.

La première opération que fait Arena lorsqu’on lance un modèle « classique » est de le compiler. À partir de ce moment, aucun changement important ne pourra intervenir dans la structure du modèle. Or, la position initiale des transporteurs sur le circuit doit être lue

Création des fichiers de sauvegarde;

i:=1

Détection de l’entité contrôlant la palette n°i

Écriture des attributs de l’entité dans le fichier

« Entité » Écriture des attributs de

la palette dans le fichier « Transporteurs » i:=i+1 Entité existe? Dernière palette?

Listing des entités contenues dans la file

d’attente n° i

i:=1

Écriture des attributs de l’entité dans le fichier

« Entité » Écriture des numéros et rangs des entités dans le

fichier « Queues » i:=i+1 Dernière file? Écriture du nombre d’unités réservées de chaque ressource dans le

fichier « Ressources » oui oui oui non non non Fin de sauvegarde

depuis le fichier d’état de l’observateur, ce qui impose de modifier le module de définition des transporteurs après le début de l’exécution du modèle. Le VBA intégré à Arena nous offre la possibilité d’exécuter une routine entre le lancement du modèle et le début de la compilation grâce à l’évènement RunBegin. C’est donc ici que la position des transporteurs sera prise en compte. Cela impose que toutes les simulations commençant avec une position différente des transporteurs devront recommencer une compilation du modèle, ce qui augmente les temps de calcul. Toutefois, généralement, les réplications multiples pouvant survenir lors de la prise en compte d’évènements stochastiques, ou lors du test de plusieurs hypothèses partent avec un paramétrage différent mais avec le même état initial, et donc la même position initiale des transporteurs. Ce handicap n’intervient donc pas dans nos travaux.

Une seconde contrainte survient de la forme des fichiers d’état de l’observateur. En effet, l’état de l’observateur est connu sous forme chiffrée, n’ayant de sens que par rapport à la modélisation de l’observateur. Par exemple, on peut connaitre la position d’un transporteur sous la forme : Lien 5 – zone 3. Or, le lien 5 d’un modèle ne correspond pas obligatoirement au lien 5 d’un autre modèle. Il est donc préférable de conserver un circuit identique à la construction du simulateur à celui utilisé dans l’observateur. Ce constat est généralisable à toutes les déclarations de variables, ressources, files d’attente, etc. Les déclarations doivent être strictement identiques dans les deux simulateurs pour être capable d’identifier l’élément de l’observateur avec l’état duquel on cherche à initialiser l’élément du simulateur correspondant.

L’étape suivante est d’initialiser toutes les variables du modèle, ainsi que de régler la date à celle de l’envoi de la requête par l’observateur, date à laquelle celui-ci à enregistré son état. Cette mise à jour doit se faire après la compilation, mais être le premier évènement exécuté. Le VBA d’Arena nous permet d’exécuter une routine lors de l’évènement RunBeginSimulation ayant ces caractéristiques.

À partir de ce moment, il est possible de travailler sur les entités du modèle. Le but est de les replacer au même endroit et dans le même état où elles étaient dans l’observateur au moment de l’enregistrement. Pour les files d’attente, il n’y a pas de problèmes. Toujours dans le RunBeginSimulation, les entités sont créées, on leur assigne les valeurs des attributs correspondants et on les envoie dans les files d’attente correspondantes. Pour les ressources, on créé une entité à qui l’on demande de réserver toutes les unités de ressources réservées dans l’observateur. On détruit ensuite cette entité.

Lorsque les transporteurs sont en simple transport, il suffit de créer une entité, de lui assigner les attributs de l’entité qui pilotait le transporteur dans l’observateur, de réserver le transporteur, puis d’envoyer l’ordre de se déplacer à la destination prévue du transporteur. Le concept de stations d’Arena permet d’identifier la présence d’un transporteur à un endroit donné avec les actions que l’entité qui le pilote doit effectuer. Si le transporteur est à une station, alors l’entité qui le pilote est en train d’effectuer une opération. Le fonctionnement d’Arena permet de simplifier le problème. Ceci a déjà été évoqué au paragraphe II.2.2.2. Si l’entité est dans une file d’attente, on utilise la technique présentée ci-dessus en ajoutant la réservation du transporteur par l’entité. Si l’entité est dans un module d’attente (Delay), il est nécessaire de connaître sa position et la date à laquelle elle est censée en sortir. Cette information doit être obtenue depuis l’observateur. Nous proposons de la stocker dans un attribut dédié, qui sera nul lorsque l’entité n’est pas dans

un module d’attente. L’entité réserve tout de suite le transporteur et est réintroduite dans le module suivant le module Delay à la date de sortie prévue.

Le paragraphe II.2 détaille les mécanismes mis en jeu pour l’initialisation du simulateur. Cette initialisation requiert une modélisation proche de celle de l’observateur, ce qui poussera l’utilisateur final à concevoir son modèle de simulation à partir du modèle d’observation. L’initialisation est principalement conduite en VBA pour ce qui concerne l’intégration des informations au simulateur grâce aux fonctions avancées qu’il propose, et à son adaptation au traitement de données. Le VBA a ensuite pour objectif d’introduire à bon escient les entités permettant de faire vivre le modèle.