A time window is the period between a start and end time in which a network location, such as a stop in a route analysis, will be visited by a route. Time windows are frequently used to model appointment or delivery times.
Note:
A time window describes when a vehicle can arrive at location; it doesn't describe the time period during which all business at the location must be completed.Time windows can be configured for a specific date, a generic weekday, or the current date.
Learn more about dates an times in a network analysis
Two network analysis types incorporate time windows: route and vehicle routing problem.
Time windows in a route analysis
The route solver attempts to find the least-cost route through a series of stops while respecting chosen restrictions on the network and honoring all time windows. If time window violations are inevitable, the solver attempts to minimize the total violation time.
Time windows in a route analysis are defined using fields in the Stops input class:
| Network analysis class | Time window field |
|---|---|
Stops |
TimeWindowStart—The beginning of the time window when the stop can be visited. |
|
TimeWindowEnd—The end of the time window when the stop can be visited. |
Time windows are automatically used in the analysis when any of the time window fields are populated.
The time specified for each time window can be interpreted using the local time zone of each input location or in Coordinated Universal Time (UTC). When using a Route analysis layer, the time zone for time window fields can be specified using the Time Zone for Time Fields parameter on the Make Route Analysis Layer geoprocessing tool dialog box or the Reference Time Zone drop-down list on the Route Layer ribbon. When using a Route solver object in the arcpy.nax Python module, use the timeZoneForTimeWindows property.
When time windows are in use, it is not necessary to specify an analysis time of day, as the time window of the first stop will be used to determine when the route begins. However, if you specify an analysis time of day that represents, for example, the start of a driver's shift, this will be factored into the arrival and departure times at all stops. If the route begins before the first stop's time window, a wait time may will be added at the first stop. If the route begins after a stop's time window has passed, a violation time penalty may be incurred. The time window date should match the date specified for the time of day for the route analysis.
Any wait time or violation time incurred by the route is included in the output. The total wait time and violation time for each route can be found in the Routes output class in fields prefixed with TotalWait_ and TotalViolation_, respectively. The wait time and violation time incurred at each stop along a route can be found in the Stops output class in fields prefixed with Wait_ and Violation_, respectively. The fields in the output Stops class prefixed with CumulWait_ and CumulViolation_ represent the cumulative wait time and violation time up to that point along the route.
Time windows in a vehicle routing problem analysis
The vehicle routing problem solver attempts to find the least-cost route to service orders, making necessary depot visits, and taking necessary breaks while respecting chosen restrictions on the network and honoring all time windows. If time window violations are inevitable, the solver attempts to minimize the total violation time.
Time windows in a vehicle routing problem analysis can be defined for Orders, Depots, and Breaks classes using the following fields:
| Network analysis class | Time window field |
|---|---|
Orders |
TimeWindowStart—The beginning of the first time window when the order can be visited |
TimeWindowEnd—The end of the first time window when the order can be visited | |
TimeWindowStart2—The beginning of the second time window when the order can be visited | |
TimeWindowEnd2—The end of the second time window when the order can be visited | |
Depots | TimeWindowStart—The beginning of the first time window when the depot can be visited |
TimeWindowEnd—The end of the time first window when the depot can be visited | |
TimeWindowStart2—The beginning of the second time window when the depot can be visited | |
TimeWindowEnd2—The end of the second time window when the depot can be visited | |
Breaks | TimeWindowStart—The beginning of the time window when the break can occur |
TimeWindowEnd—The end of the time window when the break can occur |
Legacy:
When using a VehicleRoutingProblem solver object with schema version One in the arcpy.nax Python module, the first time window in the Orders and Depots classes is defined using fields called TimeWindowStart1 and TimeWindowEnd1 instead of TimeWindowStart and TimeWindowEnd.
The input Routes class also have time window fields that are used to specify the period in which a route can begin its journey:
| Network analysis class | Time window field |
|---|---|
Routes |
EarliestStartTime—The beginning of the time window in which the route can begin its journey |
LatestStartTime—The end of the time window in which the route can begin its journey |
Time windows are automatically used in the analysis when the time window fields are populated. The time window date must match the default date configured for the analysis.
The time specified for each time window can be interpreted using the local time zone of each input location or in Coordinated Universal Time (UTC). When using a Vehicle Routing Problem analysis layer, the time zone for time window fields can be specified using the Time Zone for Time Fields parameter on the Make Vehicle Routing Problem Analysis Layer geoprocessing tool dialog box or the Reference Time Zone drop-down list on the VRP Layer ribbon. When using a VehicleRoutingProblem solver object in the arcpy.nax Python module, use the timeZoneForTimeWindows property.
Any wait time or violation time incurred by the route is included in the output. The total wait time and violation time for each route can be found in the Routes output class in the TotalWaitTime and TotalViolationTime fields, respectively. The wait time and violation time incurred at each order, break, or depot along a route can be found the WaitTime and ViolationTime fields, respectively. The CumulWaitTime and CumulViolationTime fields for an order, depot, or break represent the cumulative wait time and violation time, respectively, up to that point along the route.
You can set the MaxViolationTime and MaxViolationTime2 fields in the input orders and the MaxViolationTime field in the input breaks to control how much time window violation is acceptable for your analysis. To model time windows as a hard constraint, in which time window violations are not permitted, set the corresponding MaxViolationTime and MaxViolationTime2 fields to zero.
Legacy:
When using a VehicleRoutingProblem solver object with schema version One in the arcpy.nax Python module, the MaxViolationTime field in the Orders class is called MaxViolationTime1.
Time window example
The following example illustrates time windows used with a route analysis used to find the optimal route to visit three stops—a, b, and c. The time window for each stop is given by its TimeWindowStart and TimeWindowEnd fields.
The route can begin from point a at any time between 8:00 and 9:00 a.m. However, it should not reach point b before 9:15 a.m. As shown below, the route reaches b at 9:08:24 a.m.
Since b should be visited only between 9:15 and 9:30 a.m., the route waits at b for 6 minutes and 36 seconds and departs at 9:15 a.m. This wait time is stored in the Wait_TravelTime field of stop b as 6.6 minutes and is added to the total time taken for the route. The Cumul_TraveTime field for a stop stores the total time taken to reach it. The cumulative travel time of b is 15 minutes (8 minutes and 24 seconds of travel and 6 minutes and 36 seconds of waiting to honor the time window of stop b).
The route departs from stop b at 9:15 a.m. and reaches stop c at 9:35:34 a.m. However, stop c has a time window of 9:15 to 9:30 a.m. Because the route is unable to honor the time window of stop c, a violation time of 5 minutes and 34 seconds is incurred and is stored in the Violation_TravelTime field as 5.58 minutes.
