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

Ce guide présente les utilisations possibles des attributs de transition. Vous apprendrez à modéliser des scénarios concrets à l'aide de deux exemples : l'intégration du temps de stationnement du véhicule dans les itinéraires optimisés et la garantie que chaque itinéraire se termine par une visite à un endroit 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 délais 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 sur l'itinéraire d'un véhicule :

  • Point de départ de l'itinéraire.
  • Arrêt où une prise en charge ou une livraison est effectuée.
  • 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. Il est associé aux transitions dans les itinéraires à l'aide de tags sur les lieux de début et de fin 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 commerciales 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. Le lieu B est à proximité, et le chauffeur peut utiliser la même place de parking pour les deux visites. Si le conducteur se rend à B juste après 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 de stationnement uniquement lorsque le conducteur se déplace d'une place de parking à une autre.

Lorsque vous modélisez le temps de stationnement séparément des durées de visite, les itinéraires où les visites utilisent le même parking prennent moins de temps. Vous rendez le modèle plus précis et vous faites en sorte que l'optimiseur préfère les itinéraires où les visites sont regroupées.

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

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

  2. Pour chaque place de parking distincte utilisée dans le modèle, utilisez un nouveau tag qui n'est pas utilisé pour autre chose 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 trajet à cette place de parking.

    3. Vehicle.end_tags si le véhicule commence et termine son trajet à cette place de parking.

  4. Pour chaque nouvelle balise de stationnement, 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 la durée nécessaire pour garer le véhicule.

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

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

Nettoyage obligatoire à la fin de la course

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 la meilleure blanchisserie en fonction de son emplacement et de ceux des collectes et des livraisons effectuées par le véhicule.
  • Après le nettoyage, le véhicule ne doit effectuer aucune autre collecte ni livraison.
  • Le temps de trajet et de nettoyage du 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 lieu, sauf depuis l'établissement de nettoyage ou le 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. La première est destinée aux lieux où le véhicule est ou devient propre, et la seconde à la fin de l'itinéraire.
  2. Pour chaque véhicule, ajoutez une expédition "Livraison uniquement" représentant la visite dans un centre de lavage, avec les attributs suivants :
    1. Chaque emplacement de nettoyage doit être représenté comme une demande de visite de livraison pour cet envoi.
    2. Ajoutez CLEANED à VisitRequest.tags de chaque demande de visite pour l'expédition de l'établissement de nettoyage. Elle indique qu'un véhicule quittant cet emplacement est propre. Les autres demandes de visite dans le modèle ne doivent pas utiliser cette balise afin que le véhicule soit considéré comme "non propre " lorsqu'il les quitte.
    3. Autorisez l'optimiseur à ignorer cette expédition 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. Cette option permet de marquer le véhicule comme propre avant qu'il effectue des collectes ou des livraisons, en supposant qu'il a été nettoyé à la fin de la journée de travail précédente, et de lui permettre de passer directement du point de départ au point d'arrivée. 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 ouvrable, 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, sauf un centre de nettoyage et le début de l'itinéraire :

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

Choisir entre les retards 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 implémentées. Le paramètre TransitionAttributes.delay est idéal pour implémenter des contraintes strictes ou pour exprimer un compromis en termes de temps passé. TransitionAttributes.cost est plus adapté à l'implémentation de préférences ou de compromis souples exprimés sous forme de coût supplémentaire. Vous pouvez combiner les délais et les coûts de manière arbitraire lorsque le temps passé et le coût sont concernés.

L'exemple de nettoyage de 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. Le long délai empêche l'optimiseur d'ignorer cette exigence. Si vous ne définissez qu'un coût, l'optimiseur peut choisir de ne pas nettoyer le véhicule 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 délai court 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 chauffeur s'arrête dans un parking payant.

Ajouter un attribut de transition qui correspond à toutes les demandes de visite

Les exemples ci-dessus utilisent des attributs de transition qui correspondent à des lieux ayant un tag donné ou à des lieux n'ayant pas le 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'une des balises TransitionAttributes.src_tag et TransitionAttributes.excluded_src_tag, ainsi que l'une des balises 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. Cette opération correspondra à tous les lieux qui ne comportent pas cette balise. Toutefois, comme vous avez intentionnellement choisi une balise qui n'est utilisée par aucun lieu, ces attributs de transition correspondront à tous les lieux.

Documentation complémentaire