Fenêtres horaires

Une fenêtre horaire correspond à la période entre une heure de début et une heure de fin, au cours de laquelle une localisation réseau, telle qu'un arrêt dans une analyse des itinéraires, est visitée par un itinéraire. Les fenêtres horaires sont fréquemment utilisées pour modéliser les heures des rendez-vous ou des livraisons.

Remarque :

Une fenêtre horaire décrit l’heure à laquelle un véhicule peut arriver à une localisation ; elle ne décrit pas la période au cours de laquelle toutes les activités doivent être terminées à cette localisation.

Route (Itinéraire), Vehicle Routing Problem (Tournée de véhicules) et Last Mile Delivery (Livraison sur le dernier kilomètre) sont les trois types d’analyses de réseau qui incorporent des fenêtres horaires. Pour les analyses Route (Itinéraire) et Vehicle Routing Problem (Tournée de véhicules), les fenêtres horaires peuvent être configurées pour une date spécifique, un jour de la semaine générique ou la date du jour. Toutefois, pour une livraison sur le dernier kilomètre, les fenêtres horaires ne peuvent être configurées que pour une date spécifique.

En savoir plus sur les dates et heures dans une analyse de réseau

Fenêtres horaires dans une analyse d'itinéraires

Le solveur d’itinéraire tente de rechercher l’itinéraire de moindre coût à travers une série d’arrêts tout en respectant les restrictions sélectionnées sur le réseau, ainsi que toutes les fenêtres horaires. Si les infractions de fenêtres horaires sont inévitables, le calculateur essaie de réduire l'infraction horaire totale.

Les fenêtres horaires d'une analyse d'itinéraire sont définies à l'aide de champs dans la classe Stops en entrée :

Classe d'analyse de réseau	Champ de fenêtre horaire
Stops	TimeWindowStart—Début de la fenêtre horaire pendant laquelle l'arrêt peut être visité.
	TimeWindowEnd—Fin de la fenêtre horaire pendant laquelle l'arrêt peut être visité.

Les fenêtres horaires sont utilisées automatiquement dans l'analyse si l’un des champs des fenêtres horaires est renseigné.

L'heure spécifiée pour chaque fenêtre temporelle peut être interprétée à l'aide du fuseau horaire local de chaque localisation en entrée ou en temps universel coordonné (UTC). Si vous utilisez une couche d'analyse d'itinéraires, le fuseau horaire des champs de fenêtre horaire peut être spécifié à l'aide du paramètre Time Zone for Time Fields (Fuseau horaire des champs horaires) de la boîte de dialogue de l'outil de géotraitement Make Route Analysis Layer (Créer une couche d’analyse d’itinéraire) ou de la liste déroulante Reference Time Zone (Fuseau horaire de référence) sur le ruban Route Layer (Couche d’itinéraires). Si vous utilisez un objet de solveur Route dans le module arcpy.nax Python, utilisez la propriété timeZoneForTimeWindows.

Si les fenêtres horaires sont utilisées, il n'est pas nécessaire de spécifier une heure du jour d'analyse car la fenêtre horaire du premier arrêt est utilisée pour déterminer l'heure de début de l'itinéraire. Toutefois, si vous spécifiez une heure du jour d'analyse qui représente, par exemple, le début du quart d'un chauffeur, cette dernière est prise en compte dans les heures d'arrivée et de départ de tous les arrêts. Si l’itinéraire commence avant la fenêtre horaire du premier arrêt, un délai d’attente est ajouté au premier arrêt. Si l’itinéraire commence une fois que la fenêtre horaire d’un arrêt est passée, une pénalité de temps d’infraction est supportée. La date de la fenêtre horaire doit correspondre à la date spécifiée pour l’heure du jour de l'analyse d’itinéraires.

Tout délai d'attente ou temps d'infraction supporté par l'itinéraire est inclus dans la sortie. Vous trouverez le total du délai d'attente et du temps d'infraction de chaque itinéraire dans la classe Routes en sortie, dans les champs préfixés de TotalWait_ et TotalViolation_, respectivement. Vous trouverez le délai d'attente et le temps d'infraction supportés à chaque arrêt le long d'un itinéraire dans la classe Stops en sortie, dans les champs préfixés de Wait_ et Violation_, respectivement. Les champs de la classe Stops en sortie préfixés de CumulWait_ et CumulViolation_ représentent le cumul du délai d'attente et du temps d'infraction jusqu'à ce point le long de l'itinéraire.

Fenêtres horaires dans une optimisation des tournées de véhicules

Le solveur d'optimisation des tournées de véhicules tente de rechercher l’itinéraire de moindre coût vers les ordres de service, en effectuant les visites de dépôt requises et en prenant les pauses nécessaires, tout en respectant les restrictions sélectionnées sur le réseau, ainsi que toutes les fenêtres horaires. Si les infractions de fenêtres horaires sont autorisées et inévitables, le solveur essaie de minimiser l’infraction horaire totale.

Dans une optimisation des tournées de véhicules, les fenêtres horaires peuvent être définies pour les classes Orders, Depots et Breaks à l'aide des champs suivants :

Classe d'analyse de réseau	Champ de fenêtre horaire
Orders	TimeWindowStart—Début de la première fenêtre horaire pendant laquelle l'ordre peut être visité.
	TimeWindowEnd—Fin de la première fenêtre horaire pendant laquelle l'ordre peut être visité.
	TimeWindowStart2—Début de la deuxième fenêtre horaire pendant laquelle l'ordre peut être visité.
	TimeWindowEnd2—Fin de la deuxième fenêtre horaire pendant laquelle l'ordre peut être visité.
Depots	TimeWindowStart—Début de la première fenêtre horaire pendant laquelle le dépôt peut être visité.
	TimeWindowEnd—Fin de la première fenêtre horaire pendant laquelle le dépôt peut être visité.
	TimeWindowStart2—Début de la deuxième fenêtre horaire pendant laquelle le dépôt peut être visité.
	TimeWindowEnd2—Fin de la deuxième fenêtre horaire pendant laquelle le dépôt peut être visité.
Breaks	TimeWindowStart—Début de la fenêtre horaire pendant laquelle la pause peut avoir lieu.
	TimeWindowEnd—Fin de la fenêtre horaire pendant laquelle la pause peut avoir lieu.

Héritage :

Si vous utilisez un objet de solveur VehicleRoutingProblem avec la version de structure Un dans le module arcpy.nax Python, la première fenêtre horaire dans les classes Orders et Depots est définie à l'aide des champs intitulés TimeWindowStart1 et TimeWindowEnd1 et non des champs TimeWindowStart et TimeWindowEnd.

La classe Routes en entrée contient également des champs de fenêtres horaires permettant de spécifier la période au cours de laquelle un itinéraire peut commencer son trajet :

Classe d'analyse de réseau	Champ de fenêtre horaire
Routes	EarliestStartTime—Début de la fenêtre horaire pendant laquelle l'itinéraire peut commencer son trajet.
	LatestStartTime—Fin de la fenêtre horaire pendant laquelle l'itinéraire peut commencer son trajet.

Les fenêtres horaires sont utilisées automatiquement dans l'analyse si les champs des fenêtres horaires sont renseignés. La date de la fenêtre horaire doit correspondre à la date par défaut configurée pour l'analyse.

L'heure spécifiée pour chaque fenêtre temporelle peut être interprétée à l'aide du fuseau horaire local de chaque localisation en entrée ou en temps universel coordonné (UTC). Si vous utilisez une couche d'analyse Vehicle Routing Problem (Optimisation des tournées de véhicules), le fuseau horaire des champs de fenêtre horaire peut être spécifié à l'aide du paramètre Time Zone for Time Fields (Fuseau horaire des champs horaires) de la boîte de dialogue de l’outil de géotraitement Make Vehicle Routing Problem Analysis Layer (Créer une couche d’analyse de tournée de véhicules) ou de la liste déroulante Reference Time Zone (Fuseau horaire de référence) sur le ruban VRP Layer (Couche VRP). Si vous utilisez un objet de solveur VehicleRoutingProblem dans le module arcpy.nax Python, utilisez la propriété timeZoneForTimeWindows.

Tout délai d'attente ou temps d'infraction supporté par l'itinéraire est inclus dans la sortie. Vous trouverez le total du délai d'attente et du temps d'infraction de chaque itinéraire dans la classe Routes en sortie, dans les champs TotalWaitTime et TotalViolationTime, respectivement. Vous trouverez le délai d’attente et le temps d’infraction supportés à chaque ordre, pause ou dépôt le long d’un itinéraire dans les champs WaitTime et ViolationTime, respectivement. Les champs CumulWaitTime et CumulViolationTime d'un ordre, d'un dépôt ou d'une pause représentent le cumul du délai d'attente et du temps d'infraction, respectivement, jusqu'à ce point le long de l'itinéraire.

Vous pouvez définir les champs MaxViolationTime et MaxViolationTime2 dans les ordres en sortie et le champ MaxViolationTime dans les pauses en entrée pour contrôler le temps d'infraction acceptable pour votre analyse. Pour modéliser les fenêtres horaires sous forme de contrainte stricte, où les violations de fenêtre horaire ne sont pas autorisées, définissez les champs MaxViolationTime et MaxViolationTime2 correspondants sur zéro.

Héritage :

Si vous utilisez un objet de solveur VehicleRoutingProblem avec la version de structure Un dans le module arcpy.nax Python, le champ MaxViolationTime de la classe Orders s'intitule MaxViolationTime1.

Fenêtres horaires dans une analyse Last Mile Delivery (Livraison sur le dernier kilomètre)

Le solveur Last Mile Delivery (Livraison sur le dernier kilomètre) tente de rechercher un ensemble d’itinéraires bien regroupés et à faible coût pour livrer les commandes tout en respectant les restrictions sélectionnées sur le réseau et les contraintes de la tournée, telles que les fenêtres horaires. Si les infractions de fenêtres horaires sont autorisées et inévitables, le solveur essaie de minimiser l’infraction horaire totale.

Les fenêtres horaires dans l’analyse Last Mile Delivery (Livraison sur le dernier kilomètre) sont définies sur la classe Orders (Ordes) à l’aide des champs suivants :

Classe d'analyse de réseau	Champ de fenêtre horaire
Orders	TimeWindowStart—Début de la fenêtre horaire pendant laquelle l’ordre peut être visité.
	TimeWindowEnd—Fin de la fenêtre horaire pendant laquelle l’ordre peut être visité.

La classe Routes (Itinéraires) en entrée contient également des champs de fenêtres horaires permettant de spécifier la période au cours de laquelle un itinéraire peut commencer son trajet :

Classe d'analyse de réseau	Champ de fenêtre horaire
Routes	EarliestStartDate—Fonctionne conjointement avec EarliestStartTime pour définir le début de la fenêtre horaire pendant laquelle l’itinéraire peut commencer son trajet, en en spécifiant la portion date.
	EarliestStartTime—Fonctionne conjointement avec EarliestStartDate pour définir le début de la fenêtre horaire pendant laquelle l’itinéraire peut commencer son trajet, en en spécifiant la portion heure.
	StartFlexibility—Indique combien de temps après l’heure de début au plus tôt de l’itinéraire autorisée, l’itinéraire peut commencer. Utilise les unités désignées par le paramètre TimeFieldUnits.

Les champs EarliestStartDate et EarliestStartTime peuvent être désignés pour chaque entité dans la classe Routes (Itinéraires) ou pour toutes les entités à l’aide des paramètres EarliestRouteStartDate et EarliestRouteStartTime.

Les fenêtres horaires sont utilisées automatiquement dans l'analyse si les champs des fenêtres horaires sont renseignés. Les dates des fenêtres horaires des classes Orders (Ordres) et Routes (Itinéraires) doivent toutes être des dates spécifiques espacées de moins d’un an les unes des autres.

L’heure spécifiée pour chaque fenêtre horaire peut être interprétée à l’aide du fuseau horaire local de chaque localisation en entrée ou en temps universel coordonné (UTC). Si vous utilisez une couche d’analyse Last Mile Delivery (Livraison sur le dernier kilomètre), le fuseau horaire des champs de fenêtre horaire peut être spécifié à l’aide du paramètre Time Zone for Time Fields (Fuseau horaire des champs horaires) de la boîte de dialogue de l’outil de géotraitement Make Last Mile Delivery Analysis Layer (Créer une couche d’analyse Livraison sur le dernier kilomètre) ou de la liste déroulante Reference Time Zone (Fuseau horaire de référence) sur le ruban Last Mile Delivery Layer (Couche Livraison sur le dernier kilomètre). Si vous utilisez un objet de solveur LastMileDelivery dans le module Python arcpy.nax, utilisez la propriété timeZoneForTimeFields.

Tout délai d'attente ou temps d'infraction supporté par l'itinéraire est inclus dans la sortie. Vous trouverez le total du délai d’attente et du temps d’infraction de chaque itinéraire dans la classe Routes (Itinéraires) en sortie, dans les champs TotalWaitTime et TotalViolationTime, respectivement. Vous trouverez le délai d’attente et le temps d’infraction supportés à chaque ordre le long d’un itinéraire dans les champs WaitTime et ViolationTime, respectivement.

Vous pouvez définir le champ MaxViolationTime dans les ordres en entrée pour contrôler le temps d’infraction acceptable pour votre analyse. Pour modéliser les fenêtres horaires sous forme de contrainte stricte, où les violations de fenêtre horaire ne sont pas autorisées, définissez le champ MaxViolationTime sur zéro.

Exemple de fenêtre horaire

L'exemple ci-après illustre les fenêtres horaires utilisées avec une analyse d’itinéraires permettant de rechercher l'itinéraire optimal pour visiter trois arrêts : a, b et c. La fenêtre horaire de chaque arrêt est fournie par ses champs TimeWindowStart et TimeWindowEnd.

L’itinéraire peut commencer au point a à tout moment entre 8h00 et 9h00. Le point b ne doit toutefois pas être atteint avant 9h15. Comme indiqué ci-dessous, l’itinéraire atteint le point b à 9h05'08''.

Le point b pouvant uniquement être visité entre 9h15 et 9h30, l’itinéraire effectue une pause de six minutes et 36 secondes au point b, puis se poursuit à 9h15. Ce temps d’attente est stocké dans le champ Wait_TravelTime de l’arrêt b sous la forme 6,6 minutes, puis ajouté au temps total de l’itinéraire. Le champ Cumul_TravelTime pour un arrêt stocke le temps total nécessaire pour l’atteindre. Le temps de déplacement cumulé au point b est de 15 minutes (huit minutes et 24 secondes de trajet et six minutes et 36 secondes d’attente pour tenir compte de la fenêtre horaire de l’arrêt b).

L’itinéraire part de l’arrêt b à 9h15 et atteint l'arrêt c à 9h35'34''. Toutefois, la fenêtre horaire de l'arrêt c se situe entre 9h15 et 9h30. L'itinéraire ne pouvant pas respecter la fenêtre horaire de l'arrêt c, un temps d'infraction de cinq minutes et 34 secondes est supporté et stocké dans le champ Violation_TravelTime sous la forme 5,58 minutes.