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 concrets sur 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 dans un lieu 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 de transition et aux coûts 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 à un autre.

Un emplacement fait référence à l'un des points suivants du parcours d'un véhicule:

  • Point de départ de l'itinéraire.
  • Arrêt où une collecte 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 et est mis en correspondance avec les transitions des itinéraires à l'aide de balises sur l'emplacement de départ et l'emplacement 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.

Heure de réservation du parking

Dans ce scénario, le conducteur doit garer le véhicule avant de pouvoir se rendre à l'emplacement A. Le lieu B est à proximité, et le conducteur peut utiliser le même emplacement 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 la regagner. Dans l'API Route Optimization, vous pouvez utiliser des attributs de transition pour ajouter un temps supplémentaire pour garer le véhicule uniquement lorsque le conducteur passe d'un emplacement de stationnement à un autre.

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

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

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

  2. Pour chaque emplacement de stationnement distinct utilisé dans le modèle, utilisez une nouvelle balise qui n'est utilisée pour rien d'autre dans le modèle, par exemple PARKING_123.

  3. Ajoutez cette balise à ce qui suit:

    1. VisitRequest.tags dans toutes les requêtes 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 ou termine son trajet à cet emplacement 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'un autre emplacement de stationnement 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 du trajet

Dans ce scénario, le véhicule doit être nettoyé à la fin du trajet, 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 installation de nettoyage en fonction de son emplacement et des emplacements 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écompté des heures de travail du conducteur et doit s'inscrire dans la durée maximale du trajet.

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 à partir de n'importe quel emplacement, sauf depuis l'établissement de nettoyage ou depuis 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. Le premier est destiné aux emplacements où le véhicule est ou devient propre, et le second à la fin du trajet.
  2. Pour chaque véhicule, ajoutez un envoi de livraison uniquement qui représente la visite dans un centre de nettoyage avec les attributs suivants :
    1. Chaque emplacement d'installation de nettoyage doit être représenté sous la forme d'une demande de livraison pour cet envoi.
    2. Ajoutez CLEANED à VisitRequest.tags pour chaque demande de visite de l'envoi de l'établissement de nettoyage. Indique qu'un véhicule quittant cet emplacement est propre. Les autres requêtes de visite du 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 valeur 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 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 dans la 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 repère de fin du 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 le délai sur une valeur supérieure à 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 temporelle du modèle est d'une journée ouvrée, vous pouvez utiliser un délai de 24 heures (86 400 secondes) pour interdire la transition vers la fin de l'itinéraire à partir de n'importe quel endroit, sauf d'une installation de nettoyage et du 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 retards 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é lorsque vous implémentez des préférences souples ou des compromis exprimés en tant que coût supplémentaire. Vous pouvez combiner les retards et les coûts de manière arbitraire lorsque le temps passé et les coûts 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 du parcours 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 de ne pas effectuer le nettoyage s'il trouve un moyen de compenser le coût ailleurs, par exemple en effectuant plus d'expéditions pendant le temps "économisé" 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 les coûts en plus 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 correspondant à des emplacements associés à une balise donnée ou à des emplacements qui ne le sont pas. 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 toutes les balises en définissant TransitionAttributes.excluded_src_tag ou TransitionAttributes.excluded_dst_tag sur une balise qui n'est utilisée nulle part dans le modèle. Cette valeur correspond à tous les établissements qui ne disposent pas de cette balise. Toutefois, comme vous avez choisi intentionnellement une balise qui n'est utilisée par aucun établissement, ces attributs de transition correspondent à tous les établissements.

Documentation complémentaire