Système de dispatching collaboratif pont roulant et AGV

Lorsque plusieurs ponts roulants et plusieurs AGV/RGV opèrent simultanément dans une même zone de production, le défi central du système de dispatching consiste à répartir les tâches de Manutention de manière sûre et efficace dans un espace et un temps limités. La qualité de la décision d’arbitrage de trajectoires influence directement le rendement global de la ligne : sans algorithme de dispatching, le taux de conflits multi-équipements est d’environ 15 à 30 occurrences par heure ; après optimisation par arbitrage de trajectoires, ce taux peut être réduit à 0 à 2 occurrences par heure. Cet article analyse de manière complète la solution d’ingénierie du système de dispatching avec arbitrage de trajectoires pour ponts roulants et AGV/RGV, depuis le tri des files de tâches, le moteur d’arbitrage de trajectoires, l’algorithme de détection de conflits jusqu’à la re-planification dynamique.

File de tâches et algorithme de tri par priorité

Les tâches de Manutention émises par le MES/WMS sont stockées dans la file de tâches du PLC de dispatching (tampon circulaire d’une capacité de 128 entrées). Chaque tâche comprend l’identifiant du matériel, les coordonnées de départ et d’arrivée, la priorité (0 à 100, les tâches urgentes étant à 100), l’horodatage d’émission et l’exigence de délai. Le tri par priorité utilise une formule à trois poids : Priorité totale = priorité de la tâche × 0,4 + coefficient de temps d’attente × 0,3 + coefficient d’urgence de délai × 0,3. Le coefficient de temps d’attente = (heure actuelle − heure d’émission) / temps d’attente standard (normalisé de 0 à 100) ; le coefficient d’urgence de délai = temps écoulé / délai total (plus la valeur est proche de 1, plus la tâche est urgente). Cette pondération à trois poids garantit que les tâches urgentes sont traitées en priorité sans pour autant attendre indéfiniment (plus le temps d’attente est long, plus la tâche remonte dans le classement).

Lors de l’attribution des tâches, les 20 premières entrées de la file sont parcourues et les conditions d’attribution sont vérifiées séquentiellement : ① un pont roulant est-il disponible et situé à proximité du point de départ (distance ≤ 10 m dans la direction du pont roulant) ; ② un AGV est-il disponible et situé au poste de départ ; ③ aucun conflit de trajectoire avec les tâches déjà attribuées (aucun chevauchement de trajectoires). Les tâches satisfaisant ces trois conditions sont attribuées immédiatement ; les autres entrent dans la file d’attente et sont réévaluées au cycle suivant. Chaque cycle (100 ms) parcourt la file ; les tâches en attente depuis plus de 60 secondes sont attribuées de force (les tâches en conflit sont automatiquement déprioritisées et placées en file d’attente). Dans le système de dispatching Kelude, le temps d’attente moyen des tâches est ≤ 15 secondes, et ≤ 5 secondes pour les tâches urgentes.

Détection de conflits et re-planification dynamique

La difficulté centrale de la coordination multi-équipements réside dans la réactivité de la détection de conflits et l’efficacité de la stratégie d’arbitrage. La détection de conflits s’effectue en deux étapes : la détection de chevauchement de zones (vérification de l’intersection des zones de travail des deux équipements) et l’analyse de fenêtres temporelles (prédiction de l’intersection des trajectoires des deux équipements sur les 3 à 5 secondes à venir). La Fréquence de détection est de 100 ms, synchronisée avec le cycle de dispatching. Une fois un conflit détecté, la stratégie d’arbitrage correspondante est déclenchée selon les cinq scénarios suivants :

Implémentation de l'algorithme d'arbitrage de trajectoire

Le moteur d'arbitrage de trajectoire constitue le composant décisionnel central du système de dispatching. Il est déployé dans l'OB35 (cycle d'interruption de 100 ms) de l'API de dispatching (S7-1500). Le moteur exécute son traitement en trois étapes : d'abord l'appariement tâche-équipement (décrit à la section précédente), puis la planification de trajectoire, et enfin la vérification des conflits. Pour la planification de trajectoire, l'algorithme de recherche heuristique A* est recommandé — avec la position actuelle de l'équipement comme point de départ et le poste cible comme destination, la fonction de coût étant F = G + H (G représentant la distance déjà parcourue et H la distance de Manhattan jusqu'à la destination). L'espace de recherche est contraint au réseau de chemins accessibles issu de la rasterisation de la carte de l'usine (nœuds espacés de 2 m, l'S7-1500 pouvant stocker ≤ 200 nœuds). Une recherche de trajectoire unique s'exécute en 2 à 5 ms sur l'S7-1500 (selon la profondeur de recherche, avec un nombre maximal de nœuds explorés ≤ 50). Pour les trajectoires d'AGV, en tenant compte de la circulation bidirectionnelle et des contraintes de demi-tour en U, le coût de trajectoire intègre une pénalité pour changement de direction (chaque virage ajoute un coût supplémentaire de 3 m, favorisant ainsi les trajectoires longues et rectilignes).

La détection de conflits par fenêtres temporelles constitue la deuxième ligne de défense de l'arbitrage de trajectoire. Après l'attribution d'une trajectoire à chaque équipement, le système décompose celle-ci en une série de segments horodatés (segments de 2 m, chacun associé à une fenêtre de temps d'arrivée prévu de ± 0,5 seconde). Lors de l'attribution d'une trajectoire à une nouvelle tâche, le système vérifie segment par segment si les fenêtres temporelles de la trajectoire chevauchent celles des trajectoires déjà attribuées (c'est-à-dire si deux équipements présentent une intersection de leurs fenêtres temporelles sur un même segment). La condition de chevauchement est la suivante : |T_{équipement A} – T_{équipement B}| < intervalle de sécurité (3 secondes entre ponts roulants, 2 secondes entre pont roulant et AGV, 1,5 seconde entre AGV). En cas de chevauchement, l'attribution de la trajectoire est refusée, et le système recherche une trajectoire alternative ou attend le cycle suivant. Le tableau des fenêtres temporelles est stocké dans un bloc de données de l'S7-1500 (128 enregistrements de segments de trajectoire réservés par équipement, chaque enregistrement occupant 12 octets, soit environ 18 Ko pour 12 équipements).

La matrice de décision finale de l'arbitrage de trajectoire : le système de dispatching maintient une matrice d'interverrouillage N×N (N = nombre total d'équipements), où l'élément M[i][j] = 0 indique l'absence de conflit de trajectoire entre les équipements i et j, et M[i][j] = 1 indique la présence d'un conflit (renseigné par la détection par fenêtres temporelles). Lors de l'arbitrage, les paires d'équipements en conflit sont parcourues par ordre décroissant de priorité : l'équipement à priorité élevée conserve sa trajectoire inchangée, tandis que l'équipement à priorité inférieure se voit recalculer une trajectoire. Si l'équipement à priorité inférieure ne dispose d'aucune trajectoire alternative (toutes les trajectoires accessibles étant en conflit), il passe en attente et la raison de l'attente est consignée. La matrice est effacée et recalculée à chaque cycle de dispatching (100 ms). Dans un scénario à 12 équipements, le système de dispatching de Kelude Industries Lourdes exécute l'arbitrage de trajectoire en ≤ 8 ms (détection par fenêtres temporelles incluse), les 92 ms restantes étant allouées aux communications et à la logique de contrôle des équipements.

Architecture du système de répartition collaborative et déploiement

L'architecture matérielle du système de dispatching est structurée en trois niveaux : le niveau terrain (API de pont roulant, contrôleurs embarqués d'AGV, contrôleurs de RGV, connectés via Profinet IRT au commutateur réseau industriel), le niveau dispatching (API de dispatching S7-1500 ou PC industriel, exécutant le moteur d'arbitrage de trajectoire et la gestion des files de tâches), et le niveau gestion (serveurs MES/WMS, échangeant les ordres de fabrication et les données de tâches avec le niveau dispatching via OPC UA). Les cycles de communication entre les équipements terrain et l'API de dispatching sont les suivants : pont roulant ≤ 50 ms (Profinet IRT, gigue ± 1 μs), AGV ≤ 100 ms (Profinet RT), RGV ≤ 50 ms. La communication entre l'API de dispatching et le MES dépend de la fréquence d'émission des tâches ; la valeur typique est un échange par lots toutes les 100 ms (environ 2 Ko de données par échange, incluant la file de tâches et les rapports d'état).

Cas de déploiement dans un atelier de montage final automobile : 12 ponts roulants (dont 5 de type LD, 3 de type QD et 4 grues à flèche) + 24 AGV (16 à guidage au sol et 8 à fourche) + 8 RGV, soit 44 équipements opérant en collaboration sur un même site (environ 200 m × 80 m). Avant le déploiement, le taux de conflits en dispatching manuel était d'environ 20 occurrences/heure (pouvant atteindre 40 occurrences/heure en période de pointe), avec un temps d'attente moyen des tâches de 45 secondes. Après le déploiement du système de dispatching de Kelude Industries Lourdes (API de dispatching S7-1500 CPU 1516-3 PN/DP, équipé d'un CP1543-1 pour la communication OPC UA), le taux de conflits est tombé à 0–2 occurrences/heure, le temps d'attente moyen des tâches a été réduit à 15 secondes, et l'efficacité de la dispatching a augmenté de 42 % (mesurée en nombre de tâches de manutention exécutées par heure). Le projet, de l'étude initiale à la mise en service, a duré 8 semaines (dont 3 semaines de configuration logicielle, 2 semaines de mise en service sur site et 1 semaine d'essais de fonctionnement intégrés).

Conception extensible : le système de dispatching adopte une architecture modulaire. L'ajout d'un nouvel équipement nécessite simplement d'ajouter une entrée de configuration dans le bloc de données de l'API de dispatching (environ 50 octets par équipement) et de configurer le type d'équipement et l'adresse de communication sur l'IHM. Un seul S7-1500 peut gérer ≤ 12 équipements (limité par le cycle de balayage du programme et les ressources de communication). Au-delà de 12 équipements, un second API de dispatching est empilé pour une dispatching par zones — réparties selon les zones de l'usine (par exemple, l'API de dispatching de la zone A gère 6 ponts roulants + 10 AGV, tandis que la zone B gère 8 RGV + 14 AGV), les deux zones échangeant les données de tâches aux frontières via un coupleur PN/PN ou un réseau Ethernet industriel. Le système de dispatching de Kelude Industries Lourdes prend en charge l'extension jusqu'à 64 équipements dans une seule usine (mise en cascade de 4 API de dispatching).

Questions fréquentes sur le système de dispatching