Voici l'essentiel : l'allocation des tâches d'un RCS n'est pas « envoyer le robot le plus proche ». Les quatre variables qui décident réellement de la qualité de l'allocation sont la distance, la batterie, le type de tâche et la congestion, pondérées ensemble. J'ai vu la politique par défaut du plus proche d'abord échouer trois fois, toujours avec le même scénario. Avec une bonne logique d'allocation, une flotte de 20 robots AMR peut faire passer son taux de trajets à vide d'environ 40% à moins de 25%, et les blocages d'allées aux heures de pointe disparaissent quasiment.
Pourquoi l'allocation au plus proche ne cesse d'échouer
Septembre 2023, un entrepôt de vêtements d'un 3PL dans l'est de la Chine, 18 AMR de type élévateur en mise en service. Le RCS appliquait la politique par défaut du fournisseur : une allocation purement au plus proche. Le jour du lancement, en pleine promotion, six tâches entrantes sont tombées d'un coup. Le RCS a envoyé les six robots les plus proches, et tous les six ont convergé vers la même allée principale. Les robots de tête attendaient que ceux de derrière cèdent le passage ; ceux de derrière étaient bloqués par ceux de devant. Onze minutes d'immobilité totale. Pendant ce temps, quatre tâches sortantes à l'autre bout restaient sans robot disponible : les plus proches étaient tous coincés dans l'embouteillage. J'ai vu exactement cet échec trois fois.
L'allocation au plus proche optimise la distance à vide d'un seul envoi et ignore l'état de la flotte après l'envoi. Envoyer six robots dans la même direction en même temps, c'est fabriquer son propre embouteillage.
Les quatre variables réellement utilisées par l'allocation d'un RCS
Sur ma liste de contrôle de la veille de mise en service, l'allocation des tâches compte quatre points, vérifiés un par un :
- Distance : pas la distance à vol d'oiseau, mais la longueur du trajet à vide : la distance réelle parcourue du robot à la tâche, y compris les allées à sens unique et les détours. Beaucoup de tâches sont à 30 mètres à vol d'oiseau et à 120 mètres de conduite réelle.
- Batterie : les robots sous 30% de charge doivent être automatiquement relégués aux trajets courts uniquement ; sous 20%, exclus des nouvelles tâches et envoyés en charge. J'ai vu un projet où le RCS a confié un long transport interzones à un robot à 12%. Il est tombé en panne au milieu d'une allée, bloquant une artère principale jusqu'à ce que quelqu'un le pousse à la main.
- Type de tâche : tous les robots ne peuvent pas faire tous les travaux. Les types élévateur et fourche ne se mélangent pas, et les palettes lourdes (plus d'une tonne, par exemple) ne vont qu'aux modèles lourds. Le vivier de tâches du RCS doit être filtré par les étiquettes de capacité des véhicules avant toute allocation.
- Congestion : un autre robot entrera-t-il dans l'allée cible dans les deux prochaines minutes ? Le RCS doit allouer par réservation : à l'envoi, réserver le trajet et plafonner les entrées dans le même sens par allée (généralement deux ou trois, selon la largeur de l'allée).
Mon ordre de priorité recommandé : type de tâche (filtre strict d'abord) → batterie (contrainte stricte) → congestion (pénalité dynamique) → distance (critère de départage). La plupart des paramètres par défaut des RCS mettent la distance en premier. C'est la cause profonde des échecs.
Stratégies d'allocation des tâches robotiques comparées : choisir parmi quatre
| Stratégie | Logique | Atouts | Faiblesses | Idéal pour |
|---|---|---|---|---|
| Plus proche d'abord | Le trajet à vide le plus court gagne | Simple, réponse rapide | Embouteillages, ignore la batterie | Flottes de moins de 10 robots, hors pointe |
| Affectation par zones | Entrepôt divisé en zones, robots fixes par zone | Zéro trajet à vide interzones, facile à raisonner | Déséquilibre de charge ; une zone chaude s'effondre | Entrepôts à distribution de tâches stable |
| Basée sur les enchères | Tâches diffusées ; chaque robot enchérit son coût ; l'enchère la plus basse gagne | Quasi-optimum global, tient naturellement compte de la batterie et de la distance | Complexe ; exige une puissance de calcul RCS sérieuse | Flottes de plus de 30 robots |
| Pré-affectation + replanification dynamique | Planifie 5 minutes à l'avance, replanifie en direct en cas de congestion | La plus stable en pointe, le moins d'embouteillages | Nécessite des prévisions de commandes du WCS | Entrepôts e-commerce à pics marqués |
Comment choisir ? Trois questions : ① La flotte dépasse-t-elle 20 robots ? Si oui, abandonnez le plus proche d'abord. ② Y a-t-il des pics évidents ? Si oui, utilisez la pré-affectation. ③ Votre matériel RCS peut-il faire tourner des enchères ? Sinon, revenez aux zones avec un réglage manuel. Ne vénérez pas l'algorithme le plus sophistiqué : celui qui tourne de façon stable gagne.
Liste de contrôle de la veille de mise en service : édition allocation des tâches du RCS
- Seuils de verrouillage pour batterie faible définis ? J'utilise 20% pour le verrouillage, 30% pour la relégation.
- Étiquettes de capacité des véhicules appariées aux types de tâches ? Faites un test négatif : émettez délibérément une tâche incompatible et confirmez que le RCS la rejette.
- Plafonds de concurrence par allée définis ? Définissez séparément les artères principales et les allées secondaires.
- Base de référence des trajets à vide mesurée ? Semaine un : suivez chaque jour le kilométrage à vide divisé par le kilométrage total. Au-dessus de 35%, réajustez.
- Responsabilités RCS contre WCS documentées ? Qui découpe les tâches, qui affecte les robots, qui gère le repli quand l'interface expire : tout par écrit.
Trois modes de défaillance coûteux
Échec 1 : embouteillages de robots dans une allée. Mai 2024, un entrepôt e-commerce de cosmétiques dans le sud de la Chine, 24 AMR. Lors de la promotion de minuit, 40 tâches sortantes sont tombées en 10 secondes. Le plus proche d'abord a envoyé 14 robots dans la même allée principale vers le quai sortant. Embouteillage total. La correction : ajouter la réservation d'allée au RCS : quand les entrées dans le même sens dépassent trois, les tâches suivantes sont automatiquement redirigées ou retardent l'envoi de 30 secondes. Après le changement, le temps de traversée de l'allée principale, à tailles de vagues égales, est passé d'une moyenne de 9 minutes à moins de 3.
Échec 2 : frontières floues entre RCS, WCS et PLC. La cause profonde la plus fréquente des projets voués à l'échec. La répartition du travail doit être : le WCS décompose les commandes en tâches de déplacement (déplacer quoi de A à B) ; le RCS affecte les tâches à des robots précis, planifie les trajets, gère le trafic et programme la charge ; le PLC ne gère que le matériel bas niveau (rouleaux, élévateurs). J'ai vu un projet où le WCS et le RCS planifiaient tous deux les trajets, et les deux plans d'itinéraires se combattaient : des robots tournant sur place aux intersections. Le remède : écrire le contrat d'interface dans le marbre. Le WCS émet des tâches, jamais des itinéraires. Les itinéraires relèvent à 100% du RCS.
Échec 3 : envoyer sans vérifier la batterie. Couvert ci-dessus : un robot à batterie faible sur un long transport est une bombe à retardement. Un détail supplémentaire : les emplacements des chargeurs appartiennent au modèle d'allocation. À l'envoi, confiez aux robots à batterie faible des tâches qui se terminent près d'un chargeur, pour qu'ils finissent le travail et passent directement en charge. Deux oiseaux d'une pierre.
Un choix contre-intuitif : ne pas faire tourner la flotte à pleine charge
Beaucoup de propriétaires d'entrepôts pensent qu'un robot à l'arrêt est de l'argent gaspillé. Faux. Ma règle : garder toujours 15–20% de la flotte en capacité flexible. Les tâches arrivent par vagues ; une flotte à pleine charge frappée par une vague n'a plus de robots à envoyer, donc tout s'empile, et les files d'attente retardent toutes les tâches ensemble. Avec 20% en réserve, la vague est absorbée et le temps d'attente moyen des tâches baisse réellement. Dans cet entrepôt de cosmétiques, nous avons gardé 4 robots sur 24 en flex (tâches d'urgence uniquement), et le temps d'attente moyen des tâches pendant la promotion a chuté d'environ un tiers par rapport à l'exploitation des 24. Le compromis : quatre robots semblent oisifs localement, mais l'ensemble du système tourne plus vite globalement. C'est la leçon la plus difficile de l'allocation des tâches d'un RCS : l'affectation optimale n'est pas celle qui occupe chaque robot ; c'est celle qui garde le système débloqué.
Par Lin Xiao, Consultant en mise en œuvre WMS
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
