Modéliser la logique métier avec des attributs de transition

Ce guide présente les utilisations possibles des attributs de transition. Il vous apprendra à modéliser des scénarios réels à l'aide de deux exemples : intégrer le temps nécessaire pour garer le véhicule dans les itinéraires optimisés et s'assurer que chaque itinéraire se termine par une visite à un emplacement spécifique.

Avant de commencer

Vous utilisez des attributs de transition pour ajouter des coûts et des retards spécifiques au modèle à certaines transitions dans les itinéraires optimisés. Ces coûts et retards s'ajoutent aux durées et aux coûts de transition calculés à partir des données cartographiques en fonction des paramètres du véhicule utilisé.

Une transition est le segment de l'itinéraire qui relie un lieu au suivant.

Un lieu fait référence à l'un des points suivants de l'itinéraire d'un véhicule :

  • Point de départ de l'itinéraire.
  • Arrêt où un retrait ou une livraison sont effectués.
  • Point d'arrivée de l'itinéraire.

Vous définissez tous les attributs de transition du modèle en les ajoutant à la liste ShipmentModel.transition_attributes. Chaque élément de la liste définit un ensemble d'attributs de transition, et il est mis en correspondance avec les transitions des itinéraires à l'aide de tags sur le lieu de départ et le lieu d'arrivée de la transition. Pour en savoir plus sur les attributs de transition, consultez la documentation de référence sur TransitionAttributes.

Modéliser des scénarios concrets

Cette section présente deux petits exemples d'implémentation de contraintes métier réelles à l'aide d'attributs de transition.

Réserver une place de parking

Dans ce scénario, le conducteur doit garer le véhicule avant de pouvoir se rendre au point A. L'emplacement B est à proximité, et le conducteur peut utiliser la même place de parking pour les deux visites. Si le conducteur se rend au point B juste après le point A, il gagne du temps, car il n'a pas besoin de quitter la place de parking et de garer à nouveau le véhicule. Dans l'API Route Optimization, vous pouvez utiliser des attributs de transition pour ajouter du temps supplémentaire pour garer le véhicule uniquement lorsque le conducteur passe d'une place de parking à une autre.

Lorsque vous modélisez le temps de stationnement séparément de la durée des visites, vous réduisez la durée des itinéraires où les visites utilisant le même parking sont regroupées. Vous rendez le modèle plus précis et vous faites en sorte que l'optimiseur privilégie les itinéraires où les visites sont regroupées.

Pour ce faire, procédez comme suit dans une requête API Route Optimization :

  1. N'utilisez VisitRequest.duration que pendant la durée nécessaire à la visite. Par exemple, pour remettre le colis et obtenir la signature du client.

  2. Pour chaque place de parking distincte utilisée dans le modèle, utilisez un nouveau tag qui n'est utilisé pour rien d'autre dans le modèle, par exemple PARKING_123.

  3. Ajoutez cette balise aux éléments suivants :

    1. VisitRequest.tags dans toutes les demandes de visite qui utilisent cette place de parking.

    2. Vehicle.start_tags si le véhicule commence son itinéraire à cette place de parking.

    3. Vehicle.end_tags si le véhicule commence ou termine son itinéraire à cette place de parking.

  4. Pour chaque nouvelle balise de parking, ajoutez une entrée à ShipmentModel.transition_attributes qui ajoute un délai de stationnement lorsque vous venez d'une autre place de parking en procédant comme suit :

    1. Définissez TransitionAttributes.excluded_src_tag et TransitionAttributes.dst_tag sur PARKING_123.

    2. Définissez TransitionAttributes.delay sur le temps nécessaire pour garer le véhicule.

    Par exemple, lorsque le tag d'un emplacement est PARKING_123 et qu'il faut 150 secondes pour garer le véhicule, vous ajoutez l'entrée suivante à ShipmentModel.transition_attributes :

    {
  "excluded_src_tag": "PARKING_123",
  "dst_tag": "PARKING_123",
  "delay": "150s"
}

Nettoyage obligatoire à la fin de l'itinéraire

Dans ce scénario, le véhicule doit être nettoyé à la fin de l'itinéraire, avec les contraintes supplémentaires suivantes :

  • Le nettoyage est effectué dans un centre de nettoyage spécialisé avant le retour au dépôt de véhicules. L'itinéraire optimisé utilise le meilleur centre de nettoyage en fonction de son emplacement et de ceux des prises en charge et des livraisons effectuées par le véhicule.
  • Après le nettoyage, le véhicule ne doit pas effectuer d'autres collectes ou livraisons.
  • Le temps nécessaire pour s'y rendre et nettoyer le véhicule est déduit des heures de travail du conducteur et doit s'inscrire dans la durée maximale de l'itinéraire.

Vous modélisez cette exigence en n'autorisant que les itinéraires vides ou dont la dernière visite est un centre de nettoyage. Dans l'API Route Optimization, vous pouvez le faire en interdisant les transitions vers le point de cheminement de fin de l'itinéraire depuis n'importe quel emplacement, à l'exception de l'installation de nettoyage ou du point de départ de l'itinéraire :

  1. Choisissez deux nouveaux tags qui ne sont utilisés nulle part dans le modèle, par exemple CLEANED et ROUTE_END. Le premier est destiné aux emplacements où le véhicule est ou devient propre, et le second à la fin de l'itinéraire.
  2. Pour chaque véhicule, ajoutez un envoi de livraison uniquement qui représente la visite d'un centre de nettoyage avec les attributs suivants :
    1. Chaque emplacement d'installation de nettoyage doit être représenté comme une demande de visite de livraison de cet envoi.
    2. Ajoutez CLEANED à VisitRequest.tags de chaque demande de visite de l'envoi de l'établissement de nettoyage. Il indique qu'un véhicule quittant cet emplacement est propre. Les autres demandes de visite du modèle ne doivent pas utiliser ce tag, afin que le véhicule soit considéré comme "non propre " lorsqu'il les quitte.
    3. Autorisez l'optimiseur à ignorer cet envoi lorsque le véhicule n'est pas utilisé en définissant son penalty_cost sur un petit nombre.

  3. Pour chaque véhicule, ajoutez CLEANED à Vehicle.start_tags. Cela permet de marquer le véhicule comme propre avant qu'il n'effectue des collectes ou des livraisons, en supposant qu'il a été nettoyé à la fin du jour ouvré précédent, et de lui permettre de passer directement du point de départ au point de destination. Même si de tels itinéraires ne se produisent pas en pratique, autoriser ce scénario aide l'optimiseur à rechercher des itinéraires optimisés plus efficacement.

  4. Pour chaque véhicule, ajoutez ROUTE_END à Vehicle.end_tags.

  5. Ajoutez une entrée à ShipmentModel.transition_attributes qui interdit aux véhicules d'arriver au point de cheminement de fin de véhicule lorsqu'ils ne sont pas propres, avec les propriétés suivantes :

    1. Définissez TransitionAttributes.excluded_src_tag sur CLEANED.

    2. Définissez TransitionAttributes.dst_tag sur ROUTE_END.

    3. Définissez TransitionAttributes.delay sur une valeur élevée. Si vous définissez un délai supérieur à la durée maximale de l'itinéraire, vous empêchez l'optimiseur d'utiliser cette transition dans un itinéraire.

    Par exemple, lorsque l'échelle de temps du modèle est d'un jour ouvré, vous pouvez utiliser un délai de 24 heures (86 400 secondes) pour interdire la transition vers la fin de l'itinéraire depuis n'importe quel endroit, à l'exception d'un centre de nettoyage et du début de l'itinéraire :

    {
  "excluded_src_tag": "CLEANED",
  "dst_tag": "ROUTE_END",
  "delay": "86400s"
}

Comment choisir entre les délais et les coûts

Le choix entre les délais et les coûts dépend de la nature de la logique métier et des contraintes mises en œuvre. La définition de TransitionAttributes.delay est idéale pour implémenter des contraintes strictes ou pour exprimer un compromis en termes de temps passé. TransitionAttributes.cost est plus adapté lorsque vous implémentez des préférences souples ou des compromis exprimés sous forme de coût supplémentaire. Vous pouvez combiner arbitrairement les délais et les coûts lorsque le temps passé et le coût sont tous deux concernés.

L'exemple de nettoyage du véhicule utilise un délai très long, car le nettoyage du véhicule à la fin de l'itinéraire est une exigence stricte, et le long délai empêche l'optimiseur d'ignorer l'exigence. Si vous ne définissez qu'un coût, l'optimiseur peut choisir d'ignorer le nettoyage s'il trouve un moyen de compenser le coût ailleurs, par exemple en effectuant plus de livraisons pendant le temps "gagné" en ne nettoyant pas le véhicule.

L'exemple de stationnement utilise un court délai qui correspond au temps supplémentaire nécessaire pour garer le véhicule. Vous pouvez également utiliser costs en combinaison avec des retards, si le conducteur s'arrête sur un parking payant.

Ajouter un attribut de transition correspondant à toutes les requêtes de visite

Les exemples ci-dessus utilisent des attributs de transition qui correspondent aux emplacements associés à un tag donné ou aux emplacements qui ne sont pas associés au tag. Mais que faire si vous devez ajouter des attributs de transition qui s'appliquent à toutes les transitions ?

Vous ne pouvez pas simplement omettre les balises, car chaque message TransitionAttributes doit comporter l'un des éléments TransitionAttributes.src_tag et TransitionAttributes.excluded_src_tag, et l'un des éléments TransitionAttributes.dst_tag et TransitionAttributes.excluded_dst_tag.

Toutefois, vous pouvez faire correspondre tous les tags en définissant TransitionAttributes.excluded_src_tag ou TransitionAttributes.excluded_dst_tag sur un tag qui n'est utilisé nulle part dans le modèle. Cela correspondra à tous les emplacements qui n'ont pas ce tag, mais comme vous avez intentionnellement choisi un tag qui n'est utilisé par aucun emplacement, ces attributs de transition correspondront à tous les emplacements.

Documentation complémentaire