Vers une politique de prise en compte du long terme

Les algorithmes définis ci-dessus permettent d’optimiser la performance d’une seule réaf- fectation, mais ne prennent pas en compte l’état du stock après cette occurrence. Considérant que les réaffectations ont lieu avec une fréquence non négligeable par rapport aux déstockages, il est nécessaire d’appliquer une politique qui ne réduit pas les possibilités de réaffectations trop rapidement.

3.4.4.1 Boxes shifting

Lorsqu’une solution a été trouvée en utilisant les propriétés énoncées ci-dessus, on peut espérer l’améliorer en optimisant les boîtes concernées pour laisser la possibilité d’effectuer des réorganisations à plus long terme. Dans ce cas, il est intéressant d’utiliser, si possible, des boîtes dont le taux de remplissage est supérieur à celui de la solution initiale, afin de maximiser le potentiel des prochaines occurrences de l’activité de réaffectation. L’importance de remplacer des boîtes sélectionnées pour d’autres plus remplies est relative au contexte dans lequel on lance le processus de réaffectation, et de l’objectif associé.

Le cas où l’on cherche à dispatcher rapidement le contenu d’une boîte afin de libérer un em- placement de rack, ce que nous avons appelé "déclencheur d’urgence", semble peu compatible avec le fait d’allonger consciemment la durée du processus. Une alternative relativement peu

contraignante a été imaginée et implémentée. Elle consiste à autoriser tout décalage des boîtes (l’origine ou les cibles) à condition que ce décalage n’implique pas la nécessité de manipuler des boîtes additionnelles. Cette règle a pour intérêt de ne pas trop allonger le temps de réaffec- tation dans le cas où on décale la boîte origine, et de maximiser le taux de remplissage final des boîtes cible. L’algorithme mis en place commençant par décaler les boîtes cibles, le nombre de décalages de la boîte origine ne sera important que dans certains cas particuliers car les déca- lages préalables auraient dû rapprocher le nombre d’emplacements libres des boîtes cibles du nombre de tubes à réaffecter.

Dans le cas où l’opération a comme objectif de vider un maximum de boîtes, l’algorithme se déroule comme suit :

1: nbOrigiBoxesMax ← Le nombre de boîtes que l’on peut vider 2: while nbOrigiBoxesMax boîtes ne sont pas marquées do

3: if on peut remplacer la plus vide des boîtes à vider par une boîte plus remplie then

4: le faire

5: else

6: marquer la boîte

7: end if

8: end while

9: while toutes les boîtes cibles ne sont pas marquées do

10: if on peut remplacer la cible la moins remplie pour une ou plusieurs plus pleines then

11: le faire

12: else

13: marquer la boîte

14: end if

15: end while

Algorithm 1: Algo de Re-Wa

3.4.4.2 Utilisation de la "Moyenne Cible"

La "Moyenne Cible" a été définie pour améliorer l’algorithme de décalage de boîtes, créant une solution initiale améliorée. Pour un nombre donné de boîtes cibles, connaissant le nombre de cryotubes à réaffecter, on calcule la moyenne du nombre d’emplacements libres nécessaire dans chaque boîte cible. Les boîtes cibles sont ensuite choisies parmi celles se situant autour de ce taux de remplissage. L’évolution du contenu des boîtes entre deux re-warehousings est difficilement prévisible ; on ne peut par conséquent pas décider de conserver des boîtes ayant un contenu particulier.

3.4.4.3 Définition d’une "Limite Critique"

La limite critique correspond au taux de remplissage au dessus duquel on sait qu’il sera impossible, vu le scénario des manipulations, de vider une boîte en une seule occurrence de re- warehousing (considérant que l’on ne vide des boîtes que dans d’autres boîtes au moins aussi pleines).

Le calcul de cette borne a comme composantes le nombre d’échantillons par boîte (nbCt), les temps de manipulation des boîtes et tubes (TBoxet TTube), ainsi que le temps d’inventoriage d’une boîte (TInv). Elle dépend donc à la fois du scénario matériel, de la qualification du personnel et des paramètres de la contrainte StayFrozen.

Essayons de définir le temps nécessaire pour vider une boîte contenant X tubes. Posons Y = nbCt − X .

D’après la propriété 4, de laquelle découle le fait que les boîtes cibles sont au moins au- tant remplies que les boîtes origines (boîtes que l’on va vider) ; il faut utiliser au moins dX_Ye boîtes pour vider une boîte contenant X tubes. Il faudra donc sortir au moins M = 1 + dX_Ye boîtes des tanks. Ainsi, le temps nécessaire avant de remettre la première boîte dans le stock est de M.TBox+ (M − 1).TInv+ X .TTube. Ce temps doit être inférieur à la limite imposée par la contrainte StayFrozen ; on a donc M.TBox+ (M − 1).TInv+ X .TTube ≤ TMAX, soit (TBox+ TInv).dX_Ye + X.TTube≤ TMAX− TBox.

A partir de cette inégalité, nous avons implémenté une fonction itérative de recherche de la limite critique. Elle consiste en une recherche dichotomique de la limite critique, appliquée d’abord aux valeurs palier de dX_Ye, puis basée sur la vérification de la contrainte StayFrozen en incrémentant la valeur de X . La limite critique est la dernière valeur pour laquelle la contrainte est respectée.

Cette inégalité permet d’aider à décider de certains paramètres. L’acquisition de régulateurs de chaleur dans la zone de manipulation des boîtes peut par exemple impacter TMAX, et les dif- férents modes d’inventoriages TInv, TBox et TTube. La figure3.7illustre la relation entre TMAX et le contenu maximal d’une boîte pouvant être vidée. Une amélioration pertinente consisterait en l’interconnexion entre ce graphique et le rapport entre TMAX et la température ambiante dans la zone de manipulations. Dans l’éventualité d’une généralisation de l’activité de re-warehousing, ce simple outil pourrait devenir un outil d’aide à la décision à faible coût, permettant d’estimer la pertinence d’acquérir un dispositif ou de décider d’un mode opératoire réduisant les durées des différentes manipulations, impactant nbCt ou augmentant TMAX.

Evolution du Critical Gap en fonction de Tmax

0 10 20 30 40 50 60 70 80 90 100 3 6 0 0 0 3 4 5 0 0 3 3 0 0 0 3 1 5 0 0 3 0 0 0 0 2 8 5 0 0 2 7 0 0 0 2 5 5 0 0 2 4 0 0 0 2 2 5 0 0 2 1 0 0 0 1 9 5 0 0 1 8 0 0 0 1 6 5 0 0 1 5 0 0 0 1 3 5 0 0 1 2 0 0 0 1 0 5 0 0 9 0 0 0 7 5 0 0 6 0 0 0 4 5 0 0 3 0 0 0 1 5 0 0

Temps d'exposition max (s.)

C ri ti c a l G a p

Deux usages de cette valeur sont pressenties une fois les paramètres connus : afin de rapi- dement savoir qu’il n’existera pas de re-warehousing réalisable mais également en amont du décalage de boîtes cibles (boxes shifting). Dans le cas où un déclencheur périodique est mis en place, une politique à long terme peut être de choisir les boîtes cibles préférablement parmi les boîtes contenant plus de tubes que la Limite Critique.

3.5

Modélisation et Simulation

Cette section décrit plus précisément la manière dont ont été implémentés le modèle et les fonctions de réaffectation. Nous avons utilisé le logiciel distribué par Rockwell™ : Arena, version 11. Ce logiciel est décrit par Law and Kelton [2000b] comme généraliste, permettant de créer des modules et fiches d’indicateurs de performance. Sa capacité d’interfaçage avec des programmes externes est également un atout, souligné notamment parSeppanen [2000] et

Torres and Glynn [1995]. Nous fournirons dans cette section quelques captures d’écran pour

illustrer certains détails d’implémentation de la simulation.

Nous avons fait le choix d’utiliser des routines Visual Basic for Applications (VBA) au- tant que possible, que ce soit lors d’évènements au cours du déroulement d’une réplication ou des évènements ayant lieu entre les réplications d’un scénario ou entre les scénarios. La dé- nomination de "blocs VBA" signifie que les évènements déclenchés lorsqu’une entité atteint cette étape de la simulation ont été implémentées directement en VBA. Le choix d’implémenter manuellement des routines a été motivé par plusieurs points :

– La volonté de pouvoir facilement extraire les parties décisionnelles du modèle afin d’éven- tuellement les réutiliser dans un contexte réel ;

– La possibilité pour le modèle de devenir un outil ouvert et libre nécessite d’autant moins de travail d’adaptation que peu de modules Arena sont utilisés ;

– La lecture des stocks étant gourmande en ressources, et donc en temps d’exécution, nous avons souhaité inverser la priorité entre les réplications et les scénarios. Autrement dit, chaque réplication s’effectue pour tous les scénarios, ce qui nécessite une procédure par- ticulière redéfinissant notamment les évènements de début de réplication et de simulation, mais qui permet de ne lire ou générer une instance de stock initial qu’une fois pour l’en- semble des scénarios.