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

Ce guide présente les utilisations possibles des attributs de transition. Il vous explique comment modéliser des scénarios concrets à l'aide de deux exemples : intégrer le temps de stationnement du 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 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 emplacement au suivant.

Un emplacement 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ù 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 pour le modèle en les ajoutant à la liste ShipmentModel.transition_attributes. Chaque élément de la liste définit un ensemble d'attributs de transition, qui est mis en correspondance avec les transitions dans les itinéraires à l'aide de tags sur l'emplacement de départ et l'emplacement d'arrivée de la transition. Pour en savoir plus sur les attributs de transition, consultez la documentation de référence pour TransitionAttributes.

Modéliser des scénarios concrets

Cette section présente deux petits exemples d'implémentation de contraintes commerciales concrètes à l'aide d'attributs de transition.

Réserver du temps pour le stationnement

Dans ce scénario, le conducteur doit garer le véhicule avant de pouvoir se rendre à l'emplacement A. L'emplacement B se trouve à proximité, et le conducteur peut utiliser la même place de parking pour les deux visites. Si le conducteur se rend à l'emplacement B juste après l'emplacement 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 des durées de visite, vous créez des itinéraires où les visites qui utilisent le même parking sont regroupées et 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 pour le temps nécessaire à 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 utilisé pour rien d'autre dans le modèle, par exemple PARKING_123.

  3. Ajoutez ce tag 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 termine son itinéraire à cette place de parking.

  4. Pour chaque nouveau tag 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 de retourner au dépôt de véhicules. L'itinéraire optimisé utilise le meilleur centre de nettoyage en fonction de son emplacement et des lieux de prise en charge et de livraison effectués par le véhicule.
  • Après le nettoyage, le véhicule ne doit effectuer aucune prise en charge ni livraison supplémentaire.
  • 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 d'itinéraire depuis n'importe quel emplacement, à l'exception du centre 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 concerne les 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 nouvel envoi réservé à la livraison qui représente la visite d'un centre de nettoyage avec les attributs suivants :
    1. Chaque emplacement de centre 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 du centre de nettoyage. Cela 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 prises en charge 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 cheminement de départ au point de cheminement de fin. 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 nouvelle 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. Lorsque 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'une journée de travail, 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 implémentées. Définir 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é pour implémenter des préférences ou des 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 et 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 d'ignorer le nettoyage s'il trouve un moyen de compenser le coût ailleurs, par exemple en livrant plus d'envois dans 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 des coûts en combinaison avec des délais si le conducteur s'arrête sur un parking payant.

Comment ajouter un attribut de transition qui correspond à toutes les demandes de visite

Les exemples ci-dessus utilisent des attributs de transition qui correspondent à des emplacements ayant un tag donné ou à des emplacements qui n'ont 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 tags, car chaque TransitionAttributes message doit comporter l'un des éléments TransitionAttributes.src_tag et TransitionAttributes.excluded_src_tag , ainsi que 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