Vehicle routing problem analysis

Available with Network Analyst license.

Various organizations service orders with a fleet of vehicles. For example, a large furniture store might use several trucks to deliver furniture to homes. A specialized grease recycling company might route trucks from a facility to pick up used grease from restaurants. A health department might schedule daily inspection visits for each of its health inspectors.

The problem that is common to the examples listed above is the vehicle routing problem (VRP). Each organization needs to determine which orders (homes, restaurants, or inspection sites) should be serviced by each route (truck or inspector) and in what sequence the orders should be visited. The primary goal is to best service the orders and minimize the overall operating cost for the fleet of vehicles. Thus, while the ArcGIS Network Analyst extension route solver finds the best route for a single vehicle to visit many stops, the VRP solver finds the best routes for a fleet of vehicles to service many orders. In addition, the VRP solver can solve more specific problems because numerous options are available, such as matching vehicle capacities with order quantities, giving breaks to drivers, and pairing orders so they are serviced by the same route.

Solving a vehicle routing problem follows the same workflow as other network analyses.

Learn more about the network analysis workflow

Vehicle routing problem analysis layer

The vehicle routing problem analysis layer stores the inputs, parameters, and results for a given vehicle routing problem.

Creating a vehicle routing problem analysis layer

You can create the vehicle routing problem analysis layer from the Network Analyst toolbar by clicking Network Analyst > New Vehicle Routing Problem.

When you create a vehicle routing problem analysis layer, it appears in the Network Analyst window along with its 13 network analysis classes: Orders, Depots, Routes, Depot Visits, Breaks, Route Zones, Route Seed Points, Route Renewals, Specialties, Order Pairs, Point Barriers, Line Barriers, and Polygon Barriers.

The vehicle routing problem analysis layer also appears in the Table Of Contents window as a composite layer, which is named Vehicle Routing Problem or, if a vehicle routing problem with the same name already exists in the map document, Vehicle Routing Problem 1, Vehicle Routing Problem 2, and so on. There are nine feature layers: Orders, Depot Visits, Depots, Route Seed Points, Routes, Route Zones, Point Barriers, Line Barriers, and Polygon Barriers. Each of the nine feature layers has default symbology that can be modified on its Layer Properties dialog box.

Note:

Since the breaks, specialties, order pairs, and route renewals are tables, they don't appear in the table of contents.

Vehicle routing problem analysis classes

The vehicle routing problem analysis layer is made up of 13 network analysis classes, which are either feature layers or tables stored within the analysis layer. They contain the network analysis objects used when solving the vehicle routing problem. The relationships between various network analysis classes are shown in the following document:

Relationships between network analysis classes in the vehicle routing problem

An overview of each class and descriptions of their properties are provided in the following sections.

Learn more about network analysis classes

Orders feature layer

This feature layer stores the orders that are part of a given vehicle routing problem analysis layer. An order can be a delivery to a customer, a pickup from a customer, or some other type of work. Examples include a furniture delivery, a grease pickup from a restaurant, or an inspection visit.

If orders have items to be picked up or delivered, the items can have one or many capacities, which can be based on any form or combination of measurements you want, such as weight, volume, or number of units. Some orders, such as inspection visits, may not have any deliveries or pickups associated with them.

An order can have a service time, which is the time needed to complete the work at the order. For example, a delivery truck may require a 20-minute service time to unload a piece of furniture and move it inside a home. The service time can be the same for all orders, or it can be unique for each order.

An order can have one or two time windows, which indicate when a vehicle is allowed to visit the order. For example, a wholesale foods delivery truck is only permitted to arrive at a restaurant between 8:00 and 10:00 a.m. or between 2:00 and 4:00 p.m., because arriving at any other time would disrupt the restaurant's business.

The VRP solver is not designed to solve problems over one year in duration. Therefore, all service times and time windows need to be less than a year.

Specialties can be associated with an order. That is, an order may require a technician with a certain skill set (for example, an electrician) or a vehicle with certain capabilities (a power lift). Only a route that has the same specialty will be assigned to the order.

Order properties

Input fields of Orders

Input field	Description
ObjectID	The system-managed ID field.
Shape	The geometry field indicating the geographic location of the network analysis object.
Name	The name of the network analysis object. The name must be unique. This field acts as a primary key and is used as a foreign key to refer to orders in the OrderPairs table. Order names are case insensitive and cannot be empty, even if the order is excluded from the solve operation.
Description	The descriptive information about the order. This can contain any textual information for the order and has no restrictions for uniqueness. You may want to store a client's ID number in the Name field and the client's actual name or address in the Description field.
ServiceTime	This property specifies how much time will be spent at the network location when the route visits it; that is, it stores the impedance value for the network location. A zero or null value indicates the network location requires no service time. The unit for this field value is specified by the Time Field Units property of the analysis layer.
TimeWindowStart1	The beginning time of the first time window for the network location. This field can contain a null value; a null value indicates no beginning time. (See the note below this table of properties for more information.)
TimeWindowEnd1	The ending time of the first window for the network location. This field can contain a null value; a null value indicates no ending time. (See the note below this table of properties for more information.)
TimeWindowStart2	The beginning time of the second time window for the network location. This field can contain a null value; a null value indicates that there is no second time window. If the first time window is null as specified by the TimeWindowStart1 and TimeWindowEnd1 fields, the second time window must also be null. If both time windows are nonnull, they can't overlap. Also, the second time window must occur after the first. (See the note below this table of properties for more information.)
TimeWindowEnd2	The ending time of the second time window for the network location. This field can contain a null value. When TimeWindowStart2 and TimeWindowEnd2 are both null, there is no second time window. When TimeWindowStart2 is not null but TimeWindowEnd2 is null, there is a second time window that has a starting time but no ending time. This is valid. (See the note below this table of properties for more information.)
MaxViolationTime1	A time window is considered violated if the arrival time occurs after the time window has ended. This field specifies the maximum allowable violation time for the first time window of the order. It can contain a zero value but can't contain negative values. A zero value indicates that a time window violation at the first time window of the order is unacceptable; that is, the first time window is hard. On the other hand, a null value indicates that there is no limit on the allowable violation time. A nonzero value specifies the maximum amount of lateness; for example, a route can arrive at an order up to 30 minutes beyond the end of its first time window. The unit for this field value is specified by the Time Field Units property of the analysis layer. Time window violations can be tracked and weighted by the solver. Because of this, you can direct the VRP solver to take one of three approaches: Minimize the overall violation time, regardless of the increase in travel cost for the fleet. Find a solution that balances overall violation time and travel cost. Ignore the overall violation time; instead, minimize the travel cost for the fleet. By assigning an importance level for the Time Window Violation setting of the analysis layer, you are essentially choosing one of these three approaches. In any case, however, the solver will return an error if the value set for MaxViolationTime1 is surpassed.
MaxViolationTime2	The maximum allowable violation time for the second time window of the order. This field is analogous to the MaxViolationTime1 field.
InboundArriveTime	Defines when the item to be delivered to the order will be ready at the starting depot. The order can be assigned to a route only if the inbound arrive time precedes the route's latest start time value; this way, the route cannot leave the depot before the item is ready to be loaded onto it. This field can help model scenarios involving inbound-wave transshipments. For example, a job at an order requires special materials that are not currently available at the depot. The materials are being shipped from another location and will arrive at the depot at 11:00 a.m. To ensure a route that leaves before the shipment arrives isn't assigned to the order, the order's inbound arrive time is set to 11:00 a.m. The special materials arrive at 11:00 a.m., they are loaded onto the vehicle, and the vehicle departs from the depot to visit its assigned orders. Notes: The route's start time, which includes service times, must occur after the inbound arrive time. If a route begins before an order's inbound arrive time, the order cannot be assigned to the route. The assignment is invalid even if the route has a start-depot service time that lasts until after the inbound arrive time. This time field can contain a time-only value or a date and time value. If a time-only value is set (for example, 11:00 AM), the date is assumed to be the date specified by the Default Date property of the analysis layer. The default date is ignored, however, when any time field in Depots, Routes, Orders, or Breaks includes a date with the time. In that case, specify all such fields with a date and time (for example, 7/11/2015 11:00 AM). The VRP solver honors InboundArriveTime regardless of the DeliveryQuantities value. If an outbound depart time is also specified, its time value must occur after the inbound arrive time.
OutboundDepartTime	Defines when the item to be picked up at the order must arrive at the ending depot. The order can be assigned to a route only if the route can visit the order and reach its end depot before the specified outbound depart time. This field can help model scenarios involving outbound-wave transshipments. For instance, a shipping company sends out delivery trucks to pick up packages from orders and bring them into a depot where they are forwarded on to other facilities, en route to their final destination. At 3:00 p.m. every day, a semitrailer stops at the depot to pick up the high-priority packages and take them directly to a central processing station. To avoid delaying the high-priority packages until the next day's 3:00 p.m. trip, the shipping company tries to have delivery trucks pick up the high-priority packages from orders and bring them to the depot before the 3:00 p.m. deadline. This is done by setting the outbound depart time to 3:00 p.m. Notes: The route's end time, including service times, must occur before the outbound depart time. If a route reaches a depot but doesn't complete its end-depot service time prior to the order's outbound depart time, the order cannot be assigned to the route. This time field can contain a time-only value or a date and time value. If a time-only value is set (for example, 11:00 AM), the date is assumed to be the date specified by the Default Date property of the analysis layer. The default date is ignored, however, when any time field in Depots, Routes, Orders, or Breaks includes a date with the time. In that case, specify all such fields with a date and time (for example, 7/11/2015 11:00 AM). The VRP solver honors OutboundDepartTime regardless of the PickupQuantities value. If an inbound arrive time is also specified, its time value must occur before the outbound depart time.
DeliveryQuantities	The size of the delivery. You can specify size in any dimension you want, such as weight, volume, or quantity. You can even specify multiple dimensions, for example, weight and volume. If the order requires 2,000 pounds of goods, the Capacity Count parameter in the analysis layer's Layer Properties dialog box should be set to 1, and DeliveryQuantities should be set to 2000. If there are multiple capacities, as specified by the Capacity Count property of the analysis layer, the DeliveryQuantities values are separated by a space. For instance, when both weight and volume are known, the Capacity Count in the analysis layer's Layer Properties dialog box should be set to 2. If the order requires 2,000 pounds of goods, which occupy 100 cubic feet, DeliveryQuantities should be set to 2000 100. An empty string or null value is equivalent to all dimensions being zero. If the string has an insufficient number of values in relation to the capacity count, or dimensions being tracked, the remaining values are treated as zeros. Delivery quantities can't be negative.
PickupQuantities	The size of the pickup. You can specify size in any dimension you want, such as weight, volume, or quantity. You can even specify multiple dimensions, for example, weight and volume. You cannot, however, use negative values. This field is analogous to the DeliveryQuantities field of Orders. Note: In the case of an exchange visit, an order can have both delivery and pickup quantities.
Revenue	The income generated if the order is included in a solution. This field can contain a null value—a null value indicates zero revenue—but it can't have a negative value. Revenue is included in optimizing the objective function value but is not part of the solution's operating cost. That is, the TotalCost field in the route class never includes revenue in its output; however, revenue weights the relative importance of servicing orders.
SpecialtyNames	A space-separated string containing the names of the specialties required by the order. A null value indicates that the order doesn't require specialties. This field is a foreign key to the Name field in the Specialties table. Specialty objects must exist before they will appear in the SpecialtyNames drop-down list. For instance, a lawn care company may need to service an order with a pesticide that requires an applicator license. The company could create a Specialty object named License and set this property to License.
AssignmentRule	This field specifies the rule for assigning the order to a route. It is constrained by a domain of values, which are listed below (their coded values are shown in parentheses). Exclude (0)—The order is to be excluded from the subsequent solve operation. Preserve route and relative sequence (1)—The solver must always assign the order to the preassigned route and at the preassigned relative sequence during the solve operation. If this assignment rule can't be followed, it results in an order violation. With this setting, only the relative sequence is maintained, not the absolute sequence. To illustrate what this means, imagine there are two orders: A and B. They have sequence values of 2 and 3, respectively. If you set their AssignmentRule field values to Preserve route and relative sequence, A's and B's actual sequence values may change after solving because other orders, breaks, and depot visits could still be sequenced before, between, or after A and B. However, B cannot be sequenced before A. Preserve route (2)—The solver must always assign the order to the preassigned route during the solve operation. A valid sequence must also be set even though the sequence may or may not be preserved. If the order can't be assigned to the specified route, it results in an order violation. Override (3)— The solver ignores the route and sequence preassignment (if any) for the order during the solve operation. It assigns a route and sequence to the order so as to minimize the overall value of the objective function. This is the default value. Anchor first (4)— The solver ignores the route and sequence preassignment (if any) for the order during the solve operation. It assigns a route to the order, and makes it the first order on that route, so as to minimize the overall value of the objective function. Anchor last (5)— The solver ignores the route and sequence preassignment (if any) for the order during the solve operation. It assigns a route to the order, and makes it the last order on that route, so as to minimize the overall value of the objective function. This field can't contain a null value.
Network location fields SourceID SourceOID PosAlong SideOfEdge	Together, these four properties describe the point on the network where the object is located. Learn more about network location fields
CurbApproach	The CurbApproach property specifies the direction a vehicle may arrive at and depart from the network location. There are four choices (their coded values are shown in parentheses): Either side of vehicle (0)—The vehicle can approach and depart the network location in either direction. U-turns are allowed. You should choose this setting if your vehicle can make a U-turn at the stop or if it can pull into a driveway or parking lot and turn around. Right side of vehicle (1)—When the vehicle approaches and departs the network location, the curb must be on the right side of the vehicle. A U-turn is prohibited. Left side of vehicle (2)—When the vehicle approaches and departs the network location, the curb must be on the left side of the vehicle. A U-turn is prohibited. No U-Turn (3)—When the vehicle approaches the network location, the curb can be on either side of the vehicle; however, the vehicle must depart without turning around. Learn more about U-turn policies

Note:

• A time window only states when a vehicle can arrive at an order; it doesn't state when the service time must be completed. To account for service time and leave before the time window is over, subtract ServiceTime from the TimeWindowEnd1 field.

• The time window fields can contain a time-only value or a date and time value. If a time field such as TimeWindowStart1 has a time-only value (for example, 8:00 AM), the date is assumed to be the date specified by the Default Date property of the analysis layer. Using date and time values (for example, 7/11/2010 8:00 AM) allows you to set time windows that span multiple days.

• The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time.

• If you're using traffic data, the time-of-day fields for the network location always reference the same time zone as the edge on which the network location is located.

Input/Output fields of Orders

Input/Output field	Description
RouteName	The name of the route to which the order is assigned. As an input field, this field is used to preassign an order to a specific route. It can contain a null value, indicating that the order is not preassigned to any route, and the solver determines the best possible route assignment for the order. If this is set to null, the sequence field must also be set to null. The RouteName field is a foreign key to the Name field in the Routes class. Route objects must exist before they will appear in the RouteName list. After a solve operation, if the order is routed, the RouteName field contains the name of the route that the order is assigned to.
Sequence	This indicates the sequence of the order on its assigned route. As an input field, this field is used to specify the relative sequence for an order on the route. This field can contain a null value specifying that the order can be placed anywhere along the route. A null value can only occur together with a null RouteName value. The input sequence values are non-negative and unique for each route (shared across depot visits, orders, and breaks), but do not need to start from 0 or be contiguous. After a solve operation, the Sequence field contains the sequence value of the order on its assigned route. Output sequence values for a route are shared across depot visits, orders, and breaks; start from 1 (at the starting depot); and are consecutive. So the smallest possible output sequence value for a routed order is 2, since a route always begins at a depot.
Status	This field is constrained by a domain of values, which are listed below (their coded values are shown in parentheses). OK (0)—The network location is valid. Not located (1)—The location on the network can't be determined. Network element not located (2)—The network element that the network location is supposed to be on can't be found. This can occur when a network edge is deleted and the network location is not recalculated. After a solve operation, the status can be modified using one of the following status values: OK (0)—The network location was successfully evaluated. Element not traversable (3)—The network element that the network location is on is not traversable. This can occur when the network element is restricted by a restriction attribute. Invalid field values (4)—The field values of the network location fall outside the analysis layer's coded or range domains. For example, a negative number may exist where positive numbers are required. Not reached (5)—The network location can't be arrived at by the solver. If time windows are used and the route arrives early or late, the value changes to Time window violation (6).

Note:

If the order has an AssignmentRule field value of Exclude, the input values for the Status, RouteName, and Sequence fields are not changed during the solve operation.

Output fields of Orders

Output field	Description
ViolatedConstraints	This field contains a summary of violated constraints and is set after a solve operation. A combination of one or more of the violations listed below could be assigned to the field if assigning the order to any of the routes would cause a constraint to be violated. Dive-in: The coded value that represents the text description is shown in the list below in parentheses. Notice that the coded values are part of a geometric sequence that increases by doubling the last value. This allows various combinations of violations to be coded. For instance, the combination of Capacities exceeded (2) and Hard route zone (128) is coded as 130 (2 +128). MaxOrderCount exceeded (1)—The order can't be assigned to a route since the assignment would exceed the route's MaxOrderCount field value. If the maximum order count is exceeded, the solution is still generated, but it will leave some orders unserviced. In this case, the VRP solver includes the largest number of orders possible given the constraints. Capacities exceeded (2)—The order can't be assigned to a route since assigning the order would exceed the route's Capacities field value. MaxTotalTime exceeded (4)—The order can't be assigned to a route since assigning the order would exceed the route's MaxTotalTime field value. MaxTotalTravelTime exceeded (8)—The order can't be assigned to a route since assigning the order would exceed the route's MaxTotalTravelTime field value. MaxTotalDistance exceeded (16)—The order can't be assigned to a route since assigning the order would exceed the route's MaxTotalDistance field value. Hard time window (32)—The order has a hard time window and can't be assigned to a route without encountering a time window violation. (A hard time window is specified by assigning a value of 0 to the MaxViolationTime1 or MaxViolationTime2 field.) Unmatched specialty (64)—The specialties required by the order are not found on the target route. Hard route zone (128)—The order does not fall within a hard route zone. If all the routes have hard route zones and an order falls outside a zone, the order is assigned this violated constraint. Order pair MaxTransitTime exceeded (256)—The order belongs to an order pair, and assigning the order would exceed the maximum transit time as specified by the order pair's MaxTransitTime field value. Order pair violation (512)—An order belongs to an order pair and can't be assigned to a route because the other order has some violation. For example, suppose orders O1 and O2 are paired, and order O1 is located on a network element with negative impedances, but there are no violation issues with order O2. The solver returns Unreachable for order O1 and Order pair violation for O2, since both orders can't be assigned to a route. Unreachable (1024)—The order is located on a network element that cannot be reached by any routes. This is often caused by an order being located on a disjoint portion of the network. Cannot insert required break (2048)—A break for the route has a null sequence value in the presence of preassigned orders, and the break can't be inserted anywhere without introducing other violations. Cannot insert required renewal (4096)—A route exceeds its capacity and needs to visit a route renewal; however, the associated route renewal has a null sequence value in the presence of preassigned orders and can't be inserted anywhere without introducing other violations. MaxTravelTimeBetweenBreaks exceeded (8192)—The solver was unable to insert a break within the time specified by the break's MaxTravelTimeBetweenBreaks field. This is often caused by preassigning a sequence to a break such that it can't be reached within the maximum travel time. Break MaxCumulWorkTime exceeded (16384)—The solver was unable to insert a break within the time specified by the break's MaxCumulWorkTime field. This is often caused by preassigning a sequence to a break such that it can't be reached within the maximum work time. InboundArriveTime or OutboundDepartTime order violation (32768)—The order couldn't be serviced within the inbound arrive time or output depart time constraints. This violation occurs when all the routes' LatestStartTime field values precede the InboundArriveTime values or none of the routes can reach a depot before the order's OutboundDepartTime value. Cannot anchor first/last (65536)— The order has an Anchor first or Anchor last assignment rule, but the solver was not able to honor this constraint. This violation occurs when the number of Anchor first orders or the number of Anchor last orders is greater than the number of available routes. Learn more about troubleshooting network analyses Note: The ViolatedConstraints value of an unrouted order may or may not describe all its violations. If the violation is severe enough to immediately exclude the order from further consideration, the solver does so, which prevents any other violations from being discovered for that order. If a violation is encountered that doesn't automatically stop a solution from being generated, the violation is noted in ViolatedConstraints, and the solver continues to consider the order. Any further violations like these are added to the ViolatedConstraints field until either (a) the solver finds a violation that prematurely stops the solve process for that particular order, or (b) the solver finds an overall solution to the problem.
FromPrevTravelTime	The travel time from the preceding visit on the route to the order. The unit for this field value is specified by the Time Field Units property of the analysis layer.
FromPrevDistance	The travel distance from the preceding visit on the route to the order. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters.
CumulTravelTime	The cumulative travel time for the route up to arrival at the order. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulDistance	The cumulative travel distance for the route up to arrival at the order. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters.
CumulTime	The cumulative route duration up to and including the order. The cumulative duration includes travel times as well as service and wait times at orders. The unit for this field value is specified by the Time Field Units property of the analysis layer.
ArriveCurbApproach	Indicates which side of the vehicle the curb is on when the vehicle approaches the network location. If the network location's CurbApproach value is set to Right side of vehicle, the ArriveCurbApproach after solving is Right side of vehicle. However, if the CurbApproach value is set to Either side of vehicle or No U-Turn, the ArriveCurbApproach could be on the right or left side depending on which produces the overall shortest path.
DepartCurbApproach	Indicates which side of the vehicle the curb is on when the vehicle departs the network location. If the network location's CurbApproach value is set to Right side of vehicle, the DepartCurbApproach after solving is Right side of vehicle. However, if the CurbApproach value is set to Either side of vehicle or No U-Turn, the DepartCurbApproach could be on the right or left side depending on which produces the overall shortest path.
ArriveTime	The date and time value indicating the arrival time at the order. The route may arrive at the order before the beginning of one of the order's time windows, in which case there is a wait time at the order. For an order with soft time windows, the route may also arrive at the order after the end of one of the time windows, in which case there is a violation time at the order. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is taken from the network element on which the order is located.
DepartTime	The date and time value indicating the departure time from the order. The route departs from the order upon completion of service. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is taken from the network element on which the order is located.
ArriveTimeUTC	The date and time value indicating the arrival time in Coordinated Universal Time (UTC) at the order.
DepartTimeUTC	The date and time value indicating the departure time in Coordinated Universal Time (UTC) from the order. The route departs from the order upon completion of service.
WaitTime	The wait time or layover at the order. For example, you get a wait time value if a route must wait at the order for a time window to open. The unit for this field value is specified by the Time Field Units property of the analysis layer.
ViolationTime	The amount of time elapsed between the end of the order's time window and the arrival of the route vehicle. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulWaitTime	The cumulative wait time from the beginning of the route up to and including the order. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulViolationTime	The cumulative violation time from the beginning of the route up to and including the order. The unit for this field value is specified by the Time Field Units property of the analysis layer.

Depots class

This network analysis class stores the depots that are part of a given vehicle routing problem analysis layer. A depot is a location that a vehicle departs from at the beginning of its workday and returns to at the end of the workday. Depots are locations where the vehicles are loaded (for deliveries) or unloaded (for pickups). In some cases, a depot can also act as a renewal location whereby the vehicle can unload or reload and continue performing deliveries and pickups. A depot has open and close times, as specified by a hard time window. Vehicles can't arrive at a depot outside this time window.

Depot properties

Input fields of Depots

Input field	Description
ObjectID	The system-managed ID field.
Shape	The geometry field indicating the geographic location of the network analysis object.
Name	The name of the network analysis object. This field is a primary key and is used as a foreign key in the Routes feature layer, RouteRenewals table, and Depot Visits feature layer to refer to depots. Depot names are case insensitive and have to be nonempty and unique.
Description	The descriptive information about the network analysis object. This can contain any textual information and has no restrictions for uniqueness. Perhaps you want to note what region a depot is in or the depot's address and telephone number; you could enter this information here rather than in the Name field.
TimeWindowStart1	The beginning time of the first time window for the network location. This field can contain a null value; a null value indicates no beginning time. (See the note below this table of properties for more information.)
TimeWindowEnd1	The ending time of the first window for the network location. This field can contain a null value; a null value indicates no ending time. (See the note below this table of properties for more information.)
TimeWindowStart2	The beginning time of the second time window for the network location. This field can contain a null value; a null value indicates that there is no second time window. If the first time window is null as specified by the TimeWindowStart1 and TimeWindowEnd1 fields, the second time window must also be null. If both time windows are nonnull, they can't overlap. Also, the second time window must occur after the first. (See the note below this table of properties for more information.)
TimeWindowEnd2	The ending time of the second time window for the network location. This field can contain a null value. When TimeWindowStart2 and TimeWindowEnd2 are both null, there is no second time window. When TimeWindowStart2 is not null but TimeWindowEnd2 is null, there is a second time window that has a starting time but no ending time. This is valid. (See the note below this table of properties for more information.)
Network location fields SourceID SourceOID PosAlong SideOfEdge	Together, these four properties describe the point on the network where the object is located. Learn more about network location fields
CurbApproach	The CurbApproach property specifies the direction from which a vehicle may arrive at and depart from the depot. It is useful for vehicles that need to approach and depart a depot from a specific direction or avoid making U-turns. You can accommodate these requirements by choosing one of the following four values for CurbApproach: Either side of vehicle (0)—The vehicle can approach and depart the network location in either direction. U-turns are allowed. You should choose this setting if your vehicle can make a U-turn at the stop or if it can pull into a driveway or parking lot and turn around. Right side of vehicle (1)—When the vehicle approaches and departs the network location, the curb must be on the right side of the vehicle. A U-turn is prohibited. Left side of vehicle (2)—When the vehicle approaches and departs the network location, the curb must be on the left side of the vehicle. A U-turn is prohibited. No U-Turn (3)—This option is not allowed with depots. An error message is returned during the solve process if No U-Turn is used. Nonetheless, U-turns can still be avoided by choosing Right or Left side of vehicle. Learn more about U-turn policies

Note:

• The time window fields can contain a time-only value or a date and time value. If a time field such as TimeWindowStart1 has a time-only value (for example, 8:00 AM), the date is assumed to be the date specified by the Default Date property of the analysis layer. Using date and time values (for example, 7/11/2010 8:00 AM) allows you to set time windows that span multiple days.

• The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time.

• If you're using traffic data, the time-of-day fields for the network location always reference the same time zone as the edge on which the network location is located.

Input/Output fields of Depots

Input/Output field

Description

Status

This field is constrained by a domain of values, which are listed below (their coded values are shown in parentheses). OK (0)—The network location is valid. Not located (1)—The location on the network can't be determined. Network element not located (2)—The network element that the network location is supposed to be on can't be found. This can occur when a network edge is deleted and the network location is not recalculated. After a solve operation, the status can be modified using one of the following status values: OK (0)—The network location was successfully evaluated. Element not traversable (3)—The network element that the network location is on is not traversable. This can occur when the network element is restricted by a restriction attribute. Invalid field values (4)—The field values of the network location fall outside the analysis layer's coded or range domains. For example, a negative number may exist where positive numbers are required. Not reached (5)—The network location can't be arrived at by the solver. If time windows are used and the routed vehicle arrives early or late, the value changes to Time window violation (6).

Routes class

This network analysis class stores the routes that are part of a given vehicle routing problem analysis layer. A route specifies the vehicle and driver characteristics, and it represents the traversal between depots and orders. In Network Analyst, vehicles, routes, and drivers are synonymous, and the term route is used to encompass all three.

Note:

The VRP solver is not designed to consider the same vehicle being used across workday shifts in a single routing solution or the changing of drivers within a workday.

A route may spend time loading or unloading at start or end depots. The amount of time spent at a depot is fixed for the route and is specified as start and end depot service times.

A route may start at a fixed time, or it may have a flexible start time; that is, it may have an earliest-to-latest start time range. The start time range and the time window of the starting depot are taken into account when determining the actual start time of the route.

The operating cost for an individual route can be made up of time-based costs, distance-based costs, and/or fixed costs that are independent of the amount of time worked or the distance driven. For example, there may be a fixed cost associated with using a vehicle if additional vehicles are to be rented to handle high-workload days. Similarly, the driver may be paid for the number of hours worked, inclusive or exclusive of overtime and lunch breaks. Such costs may be used to specify time-based costs. The fuel costs may be used to specify distance costs.

The vehicle operating on a given route may also have a capacity, which limits how much it can carry.

There may be constraints on a driver's workday such as the total distance driven or the number of hours a driver can work or drive due to state regulations or labor union agreements.

The route may include work breaks. The driver may or may not be paid for these breaks.

A vehicle may have certain capabilities, for example, a power lift or special shielding, or technicians may have different skill sets. The orders that have these specialties defined on them must be assigned to the appropriate routes.

A route may be associated with a zone if the route is restricted to work in a predefined geographic region.

Routes are line features. They can be imported from existing routes in other vehicle routing problem analysis layers, other linear features, or tables. They can also be created using the Add Item command.

Route properties

Input fields of Routes

Input field	Description
ObjectID	The system-managed ID field.
Name	The name of the network analysis object. This field is the primary key and is used as a foreign key in the Orders feature layer, Breaks table, Route Zones feature layer, Route Seed Points feature layer, Route Renewals table, and Depot Visits feature layer. Route names are case insensitive and cannot be empty, even if the route is not part of the solve operation. The name must be unique.
Description	The descriptive information about the network analysis object. This can contain any textual information and has no restrictions for uniqueness.
StartDepotName	The name of the starting depot for the route. This field is a foreign key to the Name field in the Depots class. Depot objects must exist before they will appear in the StartDepotName drop-down list. If the StartDepotName value is null, the route will begin from the first order assigned. Omitting the start depot is useful when the vehicle's starting location is unknown or irrelevant to your problem. However, when StartDepotName is null, EndDepotName cannot also be null. Virtual start depots are not allowed if orders/depots are in multiple time zones If the route is making deliveries and StartDepotName is null, it is assumed the cargo is loaded on the vehicle at a virtual depot before the route begins. For a route that has no renewal visits, its delivery orders (those with nonzero DeliveryQuantities values in the Orders class) are loaded at the start depot or virtual depot. For a route that has renewal visits, only the delivery orders before the first renewal visit are loaded at the start depot or virtual depot.
EndDepotName	The name of the ending depot for the route. This field is a foreign key to the Name field in the Depots class. Depot objects must exist before they will appear in the EndDepotName drop-down list.
StartDepotServiceTime	The service time at the starting depot. This can be used to model the time spent for loading the vehicle. This field can contain a null value; a null value indicates zero service time. The unit for this field value is specified by the Time Field Units property of the analysis layer. Note: The service times at the start and end depots are fixed values (given by the StartDepotServiceTime and EndDepotServiceTime field values) and do not take into account the actual load for a route. For example, the time taken to load a vehicle at the starting depot may depend on the size of the orders. As such, the depot service times could be given values corresponding to a full truckload or an average truckload, or you could make your own time estimate.
EndDepotServiceTime	The service time at the ending depot. This can be used to model the time spent for unloading the vehicle. This field can contain a null value; a null value indicates zero service time. The unit for this field value is specified by the Time Field Units property of the analysis layer. Note: The service times at the start and end depots are fixed values (given by the StartDepotServiceTime and EndDepotServiceTime field values) and do not take into account the actual load for a route. For example, the time taken to load a vehicle at the starting depot may depend on the size of the orders. As such, the depot service times could be given values corresponding to a full truckload or an average truckload, or you could make your own time estimate.
EarliestStartTime	The earliest allowable starting time for the route. This is used by the solver in conjunction with the time window of the starting depot for determining feasible route start times. This field can't contain null values and has a default time-only value of 8:00 AM; the default value is interpreted as 8:00 a.m. on the date given by the Default Date property of the analysis layer. The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time. When using network datasets with traffic data across multiple time zones, the time zone for EarliestStartTime is the same as the time zone of the edge or junction on which the starting depot is located.
LatestStartTime	The latest allowable starting time for the route. This field can't contain null values and has a default time-only value of 10:00 AM; the default value is interpreted as 10:00 a.m. on the date given by the Default Date property of the analysis layer. The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time. When using network datasets with traffic data across multiple time zones, the time zone for LatestStartTime is the same as the time zone of the edge or junction on which the starting depot is located.
ArriveDepartDelay	This field stores the amount of travel time needed to accelerate the vehicle to normal travel speeds, decelerate it to a stop, and move it off and on the network (for example, in and out of parking). By including an ArriveDepartDelay value, the VRP solver is deterred from sending many routes to service physically coincident orders. The cost for this property is incurred between visits to noncoincident orders, depots, and route renewals. For example, when a route starts from a depot and visits the first order, the total arrive/depart delay is added to the travel time. The same is true when traveling from the first order to the second order. If the second and third orders are coincident, the ArriveDepartDelay value is not added between them since the vehicle doesn't need to move. If the route travels to a route renewal, the value is added to the travel time again. Although a vehicle needs to slow down and stop for a break and accelerate afterwards, the VRP solver cannot add the ArriveDepartDelay value for breaks. This means that if a route leaves an order, stops for a break, and continues to the next order, the arrive/depart delay is added only once, not twice. Say there are five coincident orders in a high-rise building, and they are serviced by three different routes. This means three arrive/depart delays would be incurred; that is, three drivers would need to find parking places and enter the same building. However, if the orders could be serviced by just one route instead, only one driver would need to park and enter the building—only one arrive/depart delay would be incurred. Since the VRP solver tries to minimize cost, it will try to limit the arrive/depart delays and thus choose the single-route option. (Note that multiple routes may need to be sent when other constraints—such as specialties, time windows, or capacities—require it.) The unit for this field value is specified by the Time Field Units property of the analysis layer.
Capacities	The maximum amount (for instance, volume, weight, quantity) that can be carried by the vehicle. If a vehicle can carry a maximum of 40,000 pounds, Capacity Count on the Layer Properties dialog box of the analysis layer should be set to 1, and Capacities should be set to 40000. Similarly, if a vehicle can carry 1,000 cubic feet, Capacity Count should be set to 1, and Capacities should be set to 1000. Caution: The VRP solver only performs a simple Boolean test to determine whether capacities are exceeded. If a route's capacity value is greater than or equal to the total quantity being carried, the VRP solver will assume the cargo fits in the vehicle. This could be incorrect, depending on the actual shape of the cargo and the vehicle. For example, the VRP solver allows you to fit a 1,000-cubic-foot sphere into a 1,000-cubic-foot truck that is 8 feet wide. In reality, however, since the sphere is 12.6 feet in diameter, it won't fit in the 8-foot wide truck. If there are multiple capacities, as specified by the Capacity Count parameter of the analysis layer, the values of Capacities are separated by a space. For instance, when both the maximum weight and volume of the vehicle are used, Capacity Count on the Layer Properties dialog box of the analysis layer should be set to 2; if the vehicle can carry a weight of 40,000 pounds and a volume of 2,000 cubic feet, Capacities should be set to 40000 2000. An empty string or null value is equivalent to all values being zero. Capacity values can't be negative. If the Capacities string has an insufficient number of values in relation to the capacity count, the remaining values are treated as zero.
FixedCost	A fixed monetary cost that is incurred only if the route is used in a solution (that is, it has orders assigned to it). This field can contain null values; a null value indicates zero fixed cost. This cost is part of the total route operating cost.
CostPerUnitTime	The monetary cost incurred—per unit of work time—for the total route duration, including travel times as well as service times and wait times at orders, depots, and breaks. This field can't contain a null value and has a default value of 1.0. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CostPerUnitDistance	The monetary cost incurred—per unit of distance traveled—for the route length (total travel distance). This field can contain null values; a null value indicates zero cost. The distance unit is specified by the Distance Field Units property of the analysis layer. The solver will return an error if this field is given a value and the Distance Attribute property is not specified for the analysis layer.
OvertimeStartTime	The duration of regular work time before overtime computation begins. This field can contain null values; a null value indicates that overtime does not apply. The unit for this field value is specified by the Time Field Units property of the analysis layer. For example, if the driver is to be paid overtime pay when the total route duration extends beyond eight hours, OvertimeStartTime is specified as 8 if the Time Field Units property of the analysis layer is set to Hours.
CostPerUnitOvertime	The monetary cost incurred per time unit of overtime work. This field can contain null values; a null value indicates that the CostPerUnitOvertime value is the same as the CostPerUnitTime value.
MaxOrderCount	The maximum allowable number of orders on the route. This field can't contain null values and has a default value of 30.
MaxTotalTime	The maximum allowable route duration. The route duration includes travel times as well as service and wait times at orders, depots, and breaks. This field can contain null values; a null value indicates that there is no constraint on the route duration. The unit for this field value is specified by the Time Field Units property of the analysis layer.
MaxTotalTravelTime	The maximum allowable travel time for the route. The travel time includes only the time spent driving on the network and does not include service or wait times. The unit for this field value is specified by the Time Field Units property of the analysis layer. This field can contain null values; a null value indicates there is no constraint on the maximum allowable travel time. This field value can't be larger than the MaxTotalTime field value.
MaxTotalDistance	The maximum allowable travel distance for the route. The unit for the total distance is specified by the Distance Field Units property of the analysis layer. This field can contain null values; a null value indicates that there is no constraint on the maximum allowable travel distance. The solver will return an error if this field is given a value and the Distance Attribute property is not specified for the analysis layer.
SpecialtyNames	A space-separated string containing the names of the specialties supported by the route. A null value indicates that the route does not support any specialties. This field is a foreign key to the Name field in the Specialties table. Specialty objects must exist before they will appear in the SpecialtyNames list.
AssignmentRule	This specifies whether or not the route can be used when solving the problem. This field is constrained by a domain of values, and the possible values are the following: Include—The route is included in the solve operation. This is the default value. Exclude—The route is excluded from the solve operation.

Output fields of Routes

Output field	Description
Shape	The line shape of the route. If the Output Shape Type property of the analysis layer is set to None, no shape is returned. Setting the Output Shape Type property to Straight Line returns straight route lines that connect each pair of consecutive visits. True Shape with measures and True Shape both return lines that trace their corresponding routes on the network, the difference being that True Shape with measures returns a line that is already linearly referenced by time.
ViolatedConstraints	This field contains a summary of violated constraints and is set after a solve operation. If a route causes a constraint to be violated, a combination of one or more of the violations listed below could be assigned to the field. Dive-in: The coded value that represents the text description is shown in the list below in parentheses. Notice that the coded values are part of a geometric sequence that increases by doubling the last value. This allows various combinations of violations to be coded. For instance, the combination of Capacities exceeded (2) and Hard route zone (128) is coded as 130 (2 +128). MaxOrderCount exceeded (1)—The preassigned orders can't be assigned to the route since assigning the orders would exceed the maximum number of orders that can be assigned to the route as specified by the route's MaxOrderCount field value. Capacities exceeded (2)—The preassigned orders can't be assigned to the route since assigning the orders would exceed the total route capacity as specified by the route's Capacities field value. MaxTotalTime exceeded (4)—The travel time from the start depot to the end depot plus the service and wait times at both depots and any break exceeds the total time for the route as specified by the route's MaxTotalTime field value. MaxTotalTravelTime exceeded (8)—The travel time from the start depot to the end depot exceeds the total travel time for the route as specified by the route's MaxTotalTravelTime field value. MaxTotalDistance exceeded (16)—The travel distance from the start depot to the end depot exceeds the total travel distance for the route as specified by the route's MaxTotalDistance field value. Hard time window (32)—There is a hard time window violation on the start depot, end depot, or break associated with the route. Unmatched specialty (64)—The specialties required by an order are not found on the target route. Hard route zone (128)—An order that was preassigned to the route does not fall within a hard route zone. Order pair MaxTransitTime exceeded (256)—There is an order pair preassigned to the route, and assigning the orders in the order pair would exceed the maximum transit time for the order pair as specified by the order pair's MaxTransitTime field value. Order pair violation (512)—An order belongs to an order pair and can't be assigned to the preassigned route. Unreachable (1024)—A preassigned order is located on a network element that cannot be reached by the route. Cannot insert required break (2048)—A break for the route has a null sequence value in the presence of preassigned orders, and the break can't be inserted anywhere without introducing other violations. Cannot insert required renewal (4096)—A route exceeds its capacity and needs to visit a route renewal; however, the associated route renewal has a null sequence value in the presence of preassigned orders and can't be inserted anywhere without introducing other violations. MaxTravelTimeBetweenBreaks exceeded (8192)—The solver was unable to insert a break within the time specified by the break's MaxTravelTimeBetweenBreaks field. This is often caused by preassigning a sequence to a break such that it can't be reached within the maximum travel time. Break MaxCumulWorkTime exceeded (16384)—The solver was unable to insert a break within the time specified by the break's MaxCumulWorkTime field. This is often caused by preassigning a sequence to a break such that it can't be reached within the maximum work time.
OrderCount	The number of orders assigned to the route.
TotalCost	The total operating cost of the route, which is the sum of the following field values: FixedCost RegularTimeCost OvertimeCost DistanceCost
RegularTimeCost	The cost of regular work time, excluding any unpaid breaks.
OvertimeCost	The cost of overtime work, excluding any unpaid breaks.
DistanceCost	The distance cost component obtained by multiplying the TotalDistance and CostPerUnitDistance field values. This field value is null if the Distance Attribute property is not specified for the analysis layer.
TotalTime	The total route duration. This includes travel times as well as service and wait times at orders, depots, and breaks. The TotalTime value is the sum of the following field values: StartDepotServiceTime EndDepotServiceTime TotalOrderServiceTime TotalBreakServiceTime TotalRenewalServiceTime TotalWaitTime TotalTravelTime The unit for this field value is specified by the Time Field Units property of the analysis layer.
TotalOrderServiceTime	The total service time spent at all orders on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer.
TotalBreakServiceTime	The total service time spent at all breaks on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer.
TotalTravelTime	The total travel time for the route. The unit for this field value is specified by the Time Field Units property of the analysis layer.
TotalDistance	The total travel distance for the route. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters.
StartTime	The starting time of the route. The route may start before the beginning of its start depot's time window, in which case there is a wait time at the starting depot. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is taken from the network element that the starting depot is located on.
EndTime	The ending time of the route. The route ends upon completion of service at the ending depot. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is taken from the network element that the ending depot is located on.
StartTimeUTC	The start time of the route in Coordinated Universal Time (UTC).
EndTimeUTC	The end time of the route in Coordinated Universal Time (UTC).
TotalWaitTime	The total wait time at all orders, depots, and breaks on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer.
TotalViolationTime	The total violation time at all orders and breaks on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer.
RenewalCount	For a route with renewals, this is equal to the number of visits to depots for renewing.
TotalRenewalServiceTime	For a route with renewals, the total service time spent at all renewal visits on the route. The unit for this field value is specified by the Time Field Units property of the analysis layer.

Depot Visits feature layer

When a route starts, renews (unloads or reloads), or ends at a depot, a depot visit is created. Depot visit objects provide information regarding why a route visited a depot and what happened there. The quantity of goods loaded on or unloaded from a vehicle at the depot is recorded in the properties of a depot visit. Additional information that is useful in interpreting a vehicle routing problem solution is also included.

This is an output-only network analysis class. Depot visit features are created strictly during the solve operation; therefore, the analysis class is always empty before the solve process.

Depot visit properties

Output fields of Depot Visits

Output field	Description
ObjectID	The system-managed ID field.
Shape	The geometry field indicating the geographic location of the network analysis object.
DepotName	The name of the visited depot. This field is a foreign key to the Name field in the Depots network analysis class. If the route uses a virtual depot, which means the route starts or ends at an order instead of a depot, DepotName is null.
RouteName	The name of the route containing this visit. This field is a foreign key to the Name field in the Routes feature layer.
Sequence	Indicates the sequence of the visited depot on the route. The output sequence values for a route are shared across depot visits, orders, and breaks; start from 1 (at the starting depot); and are consecutive.
VisitType	The reason this depot was visited. This field is constrained by a domain of values: Start depot End depot Renewal depot
ServiceTime	The service time (such as loading or unloading) at the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer.
FromPrevTravelTime	The travel time from the preceding visit on the route to the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer.
FromPrevDistance	The travel distance from the preceding visit on the route to the depot. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters.
CumulTravelTime	The cumulative travel time for the route up to the arrival at this depot. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulDistance	The cumulative travel distance for the route up to the arrival at this depot. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters.
CumulTime	The cumulative route duration up to and including the depot. The cumulative duration includes travel times as well as service and wait times at orders, depots, and breaks. The unit for this field value is specified by the Time Field Units property of the analysis layer.
ArriveTime	The arrival time at the depot. The route may arrive at the depot before the beginning of the depot's time window, in which case there is wait time at the depot. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is the same as the network element that the depot is located on.
DepartTime	The departure time from the depot. When using traffic data that covers multiple time zones, the time zone for this time-of-day value is the same as the network element that the depot is located on.
ArriveTimeUTC	The date and time value indicating the arrival time in Coordinated Universal Time (UTC) at the depot.
DepartTimeUTC	The date and time value indicating the departure time in Coordinated Universal Time (UTC) from the depot.
WaitTime	The wait time at the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulWaitTime	The cumulative wait time from the beginning of the route up to and including the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulViolationTime	The cumulative violation time from the beginning of the route up to and including the depot. The unit for this field value is specified by the Time Field Units property of the analysis layer.
TotalLoadedQuantities	The amount (for instance, volume, weight, quantity) being loaded at the depot. If there are multiple capacities, as specified by the Capacity Count property of the analysis layer, they are separated by a space. For example, in case of deliveries, the value for the TotalLoadedQuantities field indicates the actual quantity of goods delivered by the vehicle before returning to a depot. This value is less than or equal to the Capacities field value for a given route, indicating that the route performs one truckload of deliveries.
TotalUnloadedQuantities	The amount (for example, volume, weight, quantity) being unloaded at the depot. If there are multiple capacities, as specified by the Capacity Count property of the analysis layer, they are separated by a space. For example, in case of pickups or routes with renewals, the value for the TotalUnloadedQuantities field indicates the actual quantity of goods picked up by the vehicle and brought to the depot. This value is less than or equal to the Capacities field value for a given route, indicating that the route performs one truckload of pickups.

Note:

There is no ViolationTime output field on the Depot Visits feature layer since depots have hard time windows.

Breaks class

This is a nonspatial network analysis class that stores the rest periods, or breaks, for routes in a vehicle routing problem. A break is associated with exactly one route, and it can be taken after completing an order, while en route to an order, or prior to servicing an order. It has a start time and a duration, which the driver may or may not be paid for. You have three options for establishing when a break begins: you can enter a time window, a maximum travel time, or a maximum work time.

• Time-window break—To set up a time-window break, you enter two time-of-day values to delimit a time range in which the break should begin. The TimeWindowStart and TimeWindowEnd fields hold the bounding time-of-day values. The duration, or service time, of the break is independent of the time window and, therefore, can extend beyond the end of the time window. For instance, if the time window for an hour-long break spans from 10:00 a.m. to 10:15 a.m., the break should start after 10:00 a.m. but before 10:15 a.m. If it starts at 10:10 a.m., the break will end at 11:10 a.m.

• Maximum-travel-time break—With this kind of break, you specify how long a person can drive before the break is required. (Note that only travel time is limited, not other times like wait and service times.) If you enter four hours into the first break's MaxTravelTimeBetweenBreaks property, for example, the driver will receive a break before the accumulated travel time from the start of the route exceeds four hours. For any subsequent breaks, the travel time is accumulated from the previous break. So if you have a second break with a MaxTravelTimeBetweenBreaks value of two hours, the second break will be taken before two hours of travel time have been accumulated from the previous break, not from the start depot.

  A route's final maximum-travel-time break not only limits the amount of accumulated travel time from the previous break or start of the route but also limits the travel time from the final break to the end depot. This is true even if there is only one break. The VRP solver is designed this way to prevent a route from taking all its breaks and then traveling for an extended period without taking another break. In the last example, MaxTravelTimeBetweenBreaks was set to two hours. If this is the route's final break, the route must be able to reach the end depot within two hours of travel time from the final break; otherwise, the solver will return an error.

• Maximum-work-time break—This break specifies how long a person can work before a break is required. Unlike maximum-travel-time breaks, which can accumulate travel time from the end of the last break, maximum-work-time breaks always accumulate work time from the beginning of the route, including any service time at the start depot.

  Note that this break limits the accumulated work time, which includes travel time and all service times; it excludes wait time, however.

A vehicle routing problem analysis layer can only be solved if all breaks are of the same type; that is, the solve process will fail if there is any combination of time-window, maximum-travel-time, and maximum-work-time breaks.

You can specify up to five breaks to a single route. For instance, assume you are using maximum-travel-time breaks for an analysis. You might assign two breaks to one route so that after two hours of travel time have been accumulated, the driver can rest for 15 minutes, and after two more hours of traveling, the driver can stop for a one-hour lunch break. You could have other routes with anywhere from zero to five breaks assigned to them.

Breaks have a Precedence field that orders them in a sequence. This way, if you want a 15-minute break to occur before a one-hour break, the precedence value of the 15-minute break should be 1, and the precedence value of the other should be 2. Precedence is required for all breaks, even though maximum-work-time and time-window breaks inherently have a chronological order.

If a route reaches the final destination before all maximum-travel-time or maximum-work-time breaks have been taken, the remaining breaks are ignored. If any time-window breaks remain at the end of a route, the route will wait until all breaks have been taken before finishing rather than finishing early.

Break properties

Input fields of Breaks

Input field	Description
ObjectID	The system-managed ID field.
TimeWindowStart	The starting time of the break's time window. If this field is null and TimeWindowEnd has a valid time-of-day value, the break is allowed to start anytime before the TimeWindowEnd value. If this field has a value, MaxTravelTimeBetweenBreaks and MaxCumulWorkTime must be null; moreover, all other breaks in the analysis layer must have null values for MaxTravelTimeBetweenBreaks and MaxCumulWorkTime. An error will occur at solve time if a route has multiple breaks with overlapping time windows. The time window fields in breaks can contain a time-only value or a date and time value. If a time field, such as TimeWindowStart, has a time-only value (for example, 12:00 PM), the date is assumed to be the date specified by the Default Date property of the analysis layer. Using date and time values (for example, 7/11/2012 12:00 PM) allows you to specify time windows that span two or more days. This is especially beneficial when a break should be taken sometime before and after midnight. The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time.
TimeWindowEnd	The ending time of the break's time window. If this field is null and TimeWindowStart has a valid time-of-day value, the break is allowed to start anytime after the TimeWindowStart value. If this field has a value, MaxTravelTimeBetweenBreaks and MaxCumulWorkTime must be null; moreover, all other breaks in the analysis layer must have null values for MaxTravelTimeBetweenBreaks and MaxCumulWorkTime. The default date is ignored when any time window field includes a date with the time. To avoid an error in this situation, format all time windows in Depots, Routes, Orders, and Breaks to also include the date with the time. See the description for TimeWindowStart (above) for more information.
MaxTravelTimeBetweenBreaks	The maximum amount of travel time that can be accumulated before the break is taken. The travel time is accumulated either from the end of the previous break or, if a break has not yet been taken, from the start of the route. If this is the route's final break, MaxTravelTimeBetweenBreaks also indicates the maximum travel time that can be accumulated from the final break to the end depot. This property is designed to limit how long a person can drive until a break is required. For instance, if the Time Field Units property of the analysis layer is set to Minutes, and MaxTravelTimeBetweenBreaks has a value of 120, the driver will get a break after two hours of driving. To assign a second break after two more hours of driving, the second break's MaxTravelTimeBetweenBreaks property should be 120. If this field has a value, TimeWindowStart, TimeWindowEnd, MaxViolationTime, and MaxCumulWorkTime must be null for an analysis to solve successfully. The unit for this field value is specified by the Time Field Units property of the analysis layer.
MaxCumulWorkTime	The maximum amount of work time that can be accumulated before the break is taken. Work time is always accumulated from the beginning of the route. Work time is the sum of travel time and service times at orders, depots, and breaks. Note, however, that this excludes wait time, which is the time a route (or driver) spends waiting at an order or depot for a time window to begin. This property is designed to limit how long a person can work until a break is required. For instance, if the Time Field Units property of the analysis layer is set to Minutes, MaxCumulWorkTime has a value of 120, and ServiceTime has a value of 15, the driver will get a 15-minute break after two hours of work. Continuing with the last example, assume a second break is needed after three more hours of work. To specify this break, you would enter 315 (five hours and 15 minutes) as the second break's MaxCumulWorkTime value. This number includes the MaxCumulWorkTime and ServiceTime values of the preceding break, along with the three additional hours of work time before granting the second break. To avoid taking maximum-work-time breaks prematurely, remember that they accumulate work time from the beginning of the route and that work time includes the service time at previously visited depots, orders, and breaks. If this field has a value, TimeWindowStart, TimeWindowEnd, MaxViolationTime, and MaxTravelTimeBetweenBreaks must be null for an analysis to solve successfully. The unit for this field value is specified by the Time Field Units property of the analysis layer.
RouteName	The name of the route that the break applies to. Although a break is assigned to exactly one route, many breaks can be assigned to the same route. This field is a foreign key to the Name field in the Routes class and can't have a null value. Route objects must exist before they will appear in the RouteName drop-down list.
Precedence	Precedence values sequence the breaks of a given route. Breaks with a precedence value of 1 occur before those with a value of 2, and so on. All breaks must have a precedence value, regardless of whether they are time-window, maximum-travel-time, or maximum-work-time breaks.
ServiceTime	The duration of the break. This field can contain null values; a null value indicates no service time. The unit for this field value is specified by the Time Field Units property of the analysis layer.
MaxViolationTime	This field specifies the maximum allowable violation time for a time-window break. A time window is considered violated if the arrival time falls outside the time range. A zero value indicates the time window cannot be violated; that is, the time window is hard. A nonzero value specifies the maximum amount of lateness; for example, the break can begin up to 30 minutes beyond the end of its time window, but the lateness is penalized as per the Time Window Violations property of the analysis layer. This property can be null; a null value with TimeWindowStart and TimeWindowEnd values indicates that there is no limit on the allowable violation time. If MaxTravelTimeBetweenBreaks or MaxCumulWorkTime has a value, MaxViolationTime must be null. The unit for this field value is specified by the Time Field Units property of the analysis layer.
IsPaid	A Boolean value indicating whether the break is paid or unpaid. A True value indicates that the time spent at the break is included in the route cost computation and overtime determination. A False value indicates otherwise. The default value is True.

Input/Output fields of Breaks

Input/Output field

Description

Sequence

As an input field, this indicates the sequence of the break on its route. This field can contain null values. The input sequence values are positive and unique for each route (shared across renewal depot visits, orders, and breaks) but need not start from 1 or be contiguous. The solver modifies the sequence field. After solving, this field contains the sequence value of the break on its route. Output sequence values for a route are shared across depot visits, orders, and breaks; start from 1 (at the starting depot); and are consecutive.

Output fields of Breaks

Output field	Description
RelativePosition	The relative position of the break. Breaks are taken somewhere between two network locations (orders or depots). A value of 0.0 indicates that the break is taken right after service completion at the preceding network location; a value of 1.0 indicates the break is taken right before starting service at the subsequent network location; and a value in between indicates where along the path from the first to the second network location the break is taken. For instance, 0.25 indicates the break is taken a quarter of the way from the previous network location to the next network location. No matter how many breaks occur between two network locations, the relative position is always reported relative to the network locations, not the other breaks.
FromPrevTravelTime	The travel time from the preceding order, depot, or break to this break. The unit for this field value is specified by the Time Field Units property of the analysis layer.
FromPrevDistance	The travel distance from the preceding order, depot, or break to this break. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters.
CumulTravelTime	The cumulative travel time for the route up to arrival at the break. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulDistance	The cumulative travel distance for the route up to arrival at the break. The unit for this field value is specified by the Distance Field Units property of the analysis layer. This field is null if the Distance Attribute property is not specified in analysis parameters.
CumulTime	The cumulative route duration up to and including the break. The cumulative duration includes travel times as well as service and wait times at orders, depots, and breaks. The unit for this field value is specified by the Time Field Units property of the analysis layer.
ArriveTime	The actual arrival time of the break. The route may arrive at the break before the beginning of the break's time window, in which case there is a wait time at the break. For a break with soft time windows, the route may also arrive at the break after the end of the time window, in which case there is a violation time at the break. If using network dataset with multiple time zones, the time is reported in the time zone of the actual break location.
DepartTime	The time the break is completed. If using network dataset with multiple time zones, the time is reported in the time zone of the actual break location.
ArriveTimeUTC	The date and time value indicating the arrival time in Coordinated Universal Time (UTC).
DepartTimeUTC	The date and time value indicating the departure time in Coordinated Universal Time (UTC).
WaitTime	The wait time at the break. The unit for this field value is specified by the Time Field Units property of the analysis layer.
ViolationTime	The violation time at the break. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulWaitTime	The cumulative wait time from the beginning of the route up to and including the break. The unit for this field value is specified by the Time Field Units property of the analysis layer.
CumulViolationTime	The cumulative violation time from the beginning of the route up to and including the break. The unit for this field value is specified by the Time Field Units property of the analysis layer.

Route Zones class

Route zones specify a work territory for a given route. A route zone is a polygon feature and is used to constrain routes to servicing only those orders that fall within or near an area. Here are some examples of when route zones may be useful:

• Some of your employees don't have the required permits to perform work in certain states or communities. You can create a hard route zone so they only visit orders in areas where they meet the requirements.
• One of your vehicles breaks down frequently so you want to minimize response time by having it only visit orders that are close to your maintenance garage. You can create a soft or hard route zone to keep the vehicle nearby.

If you use route zones in your analysis, you cannot also use route seed points.

Route zone properties

Input fields of Route Zones

Input field	Description
ObjectID	The system-managed ID field.
Shape	The geometry field indicating the geographic location of the network analysis object.
RouteName	The name of the route to which this zone applies. A route zone can have a maximum of one associated route. This field can't contain null values, and it is a foreign key to the Name field in the Routes feature layer. Route objects must exist before they will appear in the RouteName list.
IsHardZone	A Boolean value indicating a hard or soft route zone. A True value indicates that the route zone is hard; that is, an order that falls outside the route zone polygon can't be assigned to the route. The default value is True (1). A False value (0) indicates that such orders can still be assigned, but the cost of servicing the order is weighted by a function that is based on the Euclidean distance from the route zone. Basically, this means that as the straight-line distance from the soft zone to the order increases, the likelihood of the order being assigned to the route decreases.

Note:

• Since Euclidean distance is used in measuring the distance between the route zone and the orders, the network-based distance attribute is not required.
• Even though a route associated with a hard route zone can only service orders inside the route zone, other routes can still enter and service the orders inside the same zone. This is because route zones restrict the route, not the orders. (If you want to assign all the orders in an area exclusively to one route, don't use route zones; instead, select the orders in an area, change the orders' RouteName field to the proper route, and set their AssignmentRule field to Preserve Route.)

Route Seed Points class

This network analysis class stores the route seed points of a given vehicle routing problem analysis layer. Route seed points are used to specify point-based clustering for the routes. Typically, the closer an order is to a route's seed point, the more likely the order is to be assigned to that route—as long as other criteria are met, such as specialties and capacities. Clustering orders may result in routes that cover a smaller area and don't intersect other routes as much, but the overall cost of the solution could be more. You might want to use seed points to keep drivers in general neighborhoods or regions that they are familiar with, or you might want to have compartmentalized routes if they are easier for your organization to manage.

Here are a few rules and options to consider when working with route seed points:

• A route can have a preassigned route seed point, or the seed point can be calculated by the VRP solver.
• If you use route seed points in your analysis, you cannot use route zones.
• If route seed points are used, one route seed point must be assigned to each route.
• Route seed point types cannot be combined; the network analysis class must have either all dynamic or all static seed points.

Route seed points are point features; however, they are not network locations. Thus, they don't have network location fields.

Route Seed Points class

Input fields of Route Seed Points

Input field	Description
ObjectID	The system-managed ID field.
RouteName	The name of the route that this seed point applies to. There is at most one route seed point per route. This field can't contain null values and is a foreign key to the Name field in the Routes class. Route objects must exist before they will appear in the RouteName list.
SeedPointType	The type of seed point. This field is constrained by a domain of values, and the possible values are Static and Dynamic. This field has a default value of Static. In the case of static seed points, you specify where the route seed point is, and the solver tries to cluster the route around the seed point location. In the case of dynamic seed points, you add the seed point anywhere on the map, orders are clustered during the solve process, and then the seed point is relocated to the centroid of the route's orders.

Input/Output fields of Route Seed Points

Input/Output field	Description
Shape	As an input field, it indicates the location of a route seed point. For a static seed point, its input point shape is left intact throughout the solve process. On the other hand, the input shape is ignored for a dynamic seed point, and the solver modifies the Shape field during the solve process to show its new location.

Note:

Euclidean distance is used in measuring the distance between route seed points and orders; therefore, the network-based Distance Attribute in the layer properties is not required.

Route Renewals class

The Route Renewals class specifies the intermediate depots that the routes of a vehicle routing problem analysis can visit to reload and unload things they are delivering or picking up.

Specifically, a route renewal analysis object links a route object to a depot object. The relationship indicates the route can renew (reload or unload) at the associated depot.

In some industries, each route consists of one or more trips in which the vehicle delivers or picks up a full load and delivers them. Route renewals can be used to model scenarios in which a vehicle picks up a full load of deliveries at the starting depot, services the orders, returns to the depot to renew its load of deliveries, and continues servicing more orders. For example, in propane gas delivery, the vehicle may make several deliveries until its tank is nearly or completely depleted, visit a refueling point, and make more deliveries.

Here are a few rules and options to consider when working with route renewals:

• The reload/unload point, or renewal location, can be different from the start or end depot.
• Each route can have one or many predetermined renewal locations.
• A renewal location may be used more than once by a single route.
• In some cases where there may be several potential renewal locations for a route, the closest available renewal location is chosen by the solver.

Route renewal properties

Input fields of Route Renewals

Input field	Description
ObjectID	The system-managed ID field.
DepotName	The name of the depot where this renewal takes place. This field can't contain a null value and is a foreign key to the Name field in the Depots feature layer. Depot objects must exist before they will appear in the DepotName list.
RouteName	The name of the route that this renewal applies to. This field can't contain a null value and is a foreign key to the Name field in the Routes feature layer. Route objects must exist before they will appear in the RouteName list.
ServiceTime	The service time for the renewal. This field can contain a null value; a null value indicates zero service time. The unit for this field value is specified by the Time Field Units property of the analysis layer. Note: The time taken to load a vehicle at a renewal depot may depend on the size of the vehicle and how full or empty the vehicle is. However, the service time for a route renewal is a fixed value and does not take into account the actual load. As such, the renewal service time should be given a value corresponding to a full truckload, an average truckload, or another time estimate of your choice.

Input/Output fields of Route Renewals

Input/Output field

Description

Sequences

As an input field, specifies a space-separated string of sequence values of visits to the renewal depot. This field can contain a null value and is used to preassign visits to the renewal depot. As an output field, the solver may modify and store the sequence here. After solving, this field contains the sequence values of the visits to this renewal depot for the related route. If more than one renewal visit occurs at that depot on a single route, the sequence values are separated by a space. Output sequence values for a route are shared across depot visits, orders, and breaks; start from 1 (at the starting depot); and are consecutive. So if a route starts at a depot, visits two orders, makes a renewal visit, and continues, the sequence value at the renewal is 4.

Specialties class

This table lists the specialties that can be required by orders and supported by routes. A route can service an order only if it supports all the specialties required for that order.

An order may require a technician with a certain skill set or a vehicle with certain capabilities. You model these skills, capabilities, and so on, by first adding them in the Specialties class. Next, you add the specialties that are supported by a route to its SpecialtyNames property. Finally, you add the specialties that an order requires to its SpecialtyNames property. When the VRP analysis is solved, orders that require certain specialties are matched with routes that can provide them.

Specialty properties

Input fields of Specialties

Input field	Description
ObjectID	The system-managed ID field.
Name	The name of the network analysis object. This field is the primary key and is used as a foreign key in the Orders and Routes feature layers to refer to specialties. Specialty names have to be unique and can't be empty. They also can't contain spaces. So, for example, a senior technician specialty should be entered as SeniorTechnician. The no-spaces requirement is necessary because orders and routes that are associated with multiple specialties list specialty names separated by spaces; for example, SeniorTechnician Lift.
Description	The descriptive information about the network analysis object. This can contain any textual information and has no restrictions for uniqueness.

Order Pairs class

This network analysis class is a table of records that is used to pair delivery and pickup orders so they are serviced by the same route.

Sometimes it is required that the pickup and delivery for orders be paired. For example, for a courier company, a delivery of a document might involve two stops: one to pick up the document at the source and a second stop to drop it off at the destination. These related stops are assigned to the same route with the appropriate sequence. It is prohibited to assign only one of the orders to a route: either both orders are assigned to the same route, or neither order is assigned.

There may be restrictions on how long the package can stay in the vehicle; for example, a blood sample has to be transported from the doctor's office to the lab within two hours.

Some situations might require two pairs of orders. For example, suppose you want to transport a senior citizen from her home to the doctor and bring her back home. The ride from her home to the doctor is one pair of orders with a desired arrival time at the doctor, while the ride from the doctor back home is another pair with a desired pickup time.

Order pair properties

Input fields of Order Pairs

Input field	Description
ObjectID	The system-managed ID field.
FirstOrderName	The name of the first order of the pair. This field is a foreign key to the Name field in the Orders feature layer. Order objects must exist before they will appear in the FirstOrderName list.
SecondOrderName	The name of the second order of the pair. This field is a foreign key to the Name field in the Orders feature layer. Order objects must exist before they will appear in the SecondOrderName list. The first order in the pair must be a pickup order; that is, the value for its DeliveryQuantities field is null. The second order in the pair must be a delivery order; that is, the value for its PickupQuantities field is null. The quantity that is picked up at the first order must agree with the quantity that is delivered at the second order. As a special case, both orders may have zero quantities for scenarios where capacities are not used. Note: The order quantities are not loaded or unloaded at depots.
MaxTransitTime	The maximum transit time for the pair. The transit time is the duration from the departure time of the first order to the arrival time at the second order. This constraint limits the time-on-vehicle, or ride time, between the two orders. When a vehicle is carrying people or perishable goods, the ride time is typically shorter than that of a vehicle carrying packages or nonperishable goods. This field can contain null values; a null value indicates that there is no constraint on the ride time. The unit for this field value is specified by the Time Field Units property of the analysis layer. Excess transit time (measured with respect to the direct travel time between order pairs) can be tracked and weighted by the solver. Because of this, you can direct the VRP solver to take one of three approaches: (1) minimize the overall excess transit time, regardless of the increase in travel cost for the fleet; (2) find a solution that balances overall violation time and travel cost; and (3) ignore the overall excess transit time and, instead, minimize the travel cost for the fleet. By assigning an importance level for the Excess Transit Time setting of the analysis layer, you are in effect choosing one of these three approaches. Regardless of the importance level, the solver will always return an error if the MaxTransitTime value is surpassed.

Point, line, and polygon barriers

Barriers serve to temporarily restrict, add impedance to, and scale impedance on parts of the network. When a new network analysis layer is created, the barrier classes are empty. They are populated only when you add objects into them—but adding barriers is not required.

Barriers are available in all network analysis layers; therefore, they are described in a separate topic.

Learn more about barriers

Vehicle routing problem analysis parameters

Analysis parameters are set on the Layer Properties dialog box for the analysis layer. The dialog box can be accessed in different ways:

Learn more about opening the network analysis Layer Properties dialog box

The Analysis Settings tab

The following subsections list parameters that you can set on the analysis layer. They are found on the Analysis Settings tab of the analysis layer's Layer Properties dialog box.

Analysis Settings for a vehicle routing problem analysis layer

Time Attribute

The time cost attribute used to define the traversal time along the elements of the network. The time cost attribute is required, since the vehicle routing problem solver minimizes time.

Learn more about cost attributes

Distance Attribute

The distance cost attribute used to define the length along the elements of the network. The distance cost attribute is optional.

Learn more about cost attributes

Default Date

The implied date for time-field values that don't have a date specified with the time. If a time field for an order, such as TimeWindowStart1, has a time-only value, the date is assumed to be the one specified by the Default Date property. For example, if an order has a TimeWindowStart1 value of 9:00 AM and Default Date is March 6, 2011, the entire time value for the field is 9:00 a.m., March 6, 2011. If the Default Date setting is changed, the implied date for all time field values with an unspecified date is the new default date. The default date has no effect on time field values that already have a time along with a particular date.

If your network dataset includes traffic data, the results of the analysis could change depending on the date that you specify here. For example, if your routes start at 8:00 a.m. on Sunday, when there is not much traffic, versus 8:00 a.m. on Monday during rush hour, the Monday route would take longer. Furthermore, the best path could change depending on traffic conditions.

You can choose between a "floating" day or a calendar date. A calendar date has a specific day of the month, month, and year. A floating day can be Today or any day of the week (Sunday through Saturday). Floating days enable you to set up an analysis layer that can be reused, without having to remember to change the date.

Floating days are especially beneficial when used with traffic data, since traffic changes from minute to minute and day to day. For example, if you calculate the same routes each day and need accurate times or the best routes given traffic conditions, you can choose the Day of Week and Today settings. The solver will generate results based on the traffic for the current day, which is determined by your computer's operating system. If you return the next day—for instance, May 5—to update the routes for that day, you can re-solve the same analysis layer. The solution will automatically be based on the traffic for May 5 since Day of Week was set to Today.

Caution:

If you choose Day of Week, the network analysis object time fields are only allowed to have time values; they cannot have date and time values.

Learn more about historical traffic data

Capacity Count

The number of capacity constraint dimensions required to describe the relevant limits of the vehicles. In an order delivery case, each vehicle may have a limited amount of weight and volume it can carry at one time based on physical and legal limitations. In this case, if you track the weight and volume on the orders, you can use these two capacities to prevent the vehicles from getting overloaded. The capacity count for this scenario is two (weight and volume). Depending on the problem, you may need to track different types or amounts of capacities. The capacities entered into the capacity fields (DeliveryQuantities and PickupQuantities for the Orders class and Capacities for the Routes class) are space-delimited strings of numbers, which can hold up to the number of values specified in Capacity Count. Each capacity dimension should appear in the same positional order for all capacity field values in the same VRP analysis layer. The capacities themselves are unnamed, so to avoid accidentally transposing capacity dimensions, ensure that the space-delimited capacity lists are always entered in the same order for all capacity field values.

Time Field Units

The time units used by the temporal fields of the analysis layer's sublayers and tables (network analysis classes). This does not have to be the same as the units of the time cost attribute.

Distance Field Units

The distance units used by distance fields of the analysis layer's sublayers and tables (network analysis classes). This does not have to be the same as the units of the optional distance cost attribute.

U-Turns at Junctions

Network Analyst can allow U-turns everywhere, nowhere, only at dead-ends (or culs-de-sac), or only at intersections and dead-ends. Allowing U-turns implies the route can turn around at a junction and double back on the same street.

Learn about U-turn policies

Output Shape Type

The route features that are output by the analysis can be represented in one of four ways:

• True Shape gives the exact shape of the resulting route.

  

• True Shape with Measures gives the exact shape of the resulting route. Furthermore, the output includes route measurements for linear referencing. The measurements increase from the first stop and record the cumulative impedance.

  Learn more about linear referencing

• Straight Line results in a single, straight line between the stops.

  

• When the output shape type is set to None, no shape is returned.

In all these cases, the time-based and distance-based costs in the solution are the same, and the Routes feature layer attributes are the same as well; the only difference is in the shape of the Route output or whether or not linear referencing is automatically set up.

Use Hierarchy

If the network dataset has a hierarchy attribute, you can use the hierarchy during the analysis. Using a hierarchy results in the solver preferring higher-order edges to lower-order edges. Hierarchical solves are faster, and they can be used to simulate the driver preference of traveling on freeways instead of local roads—even if that means a longer trip. Not using a hierarchy, however, yields an exact route for the network dataset.

Learn more about routing with hierarchy

Ignore Invalid Order Locations

Specifies whether invalid orders should be ignored when solving the vehicle routing problem. If this option is unchecked and any orders are invalid, the solve operation will fail.

An invalid order is an order that the VRP solver can't reach. An order may be unreachable for a variety of reasons, including the following: it is located on a prohibited network element, it isn't located on the network at all, or it is located on a disconnected portion of the network.

Sorting out the causes of invalid orders and resolving them takes time. Therefore, if you need to generate routes and deliver them to drivers immediately, you may be able to ignore invalid orders, solve, and distribute the routes to your drivers. Next, resolve any invalid orders from the last solve, and then include them in the VRP analysis for the next workday or work shift.

Restrictions

You can choose which restriction attributes should be respected while solving the analysis. In most cases, restrictions cause roads to be prohibited, but they can also cause them to be avoided or preferred. A restriction attribute, such as Oneway, should be used when finding solutions for vehicles that must obey one-way streets (for instance, nonemergency vehicles). Other common restriction attributes include height or weight limits that prohibit some vehicles from traversing certain roads or bridges; hazardous materials restrictions that hazmat drivers need to completely bypass or at least try to avoid; and designated truck routes that truck drivers should try to follow. You can choose which restriction attributes should be respected while solving the analysis. (You can further specify whether the elements that use the restriction should be prohibited, avoided, or preferred in the Attribute Parameters tab.)

• Learn more about restrictions
• Learn more about routing with parameterized attributes
• Exercise 12: Solving a network analysis using restriction attributes

Directions

With the Directions properties, you can set the units for displaying distance and, optionally, time. Additionally, you can choose to open directions automatically after the generation of a route. (If you choose not to display directions automatically, you can click the Directions Window button to display directions.)

The Advanced Settings tab

The Advanced Settings tab of the Layer Properties dialog box displays the following properties for the vehicle routing problem analysis layer. The settings you make here influence the solver's priorities when handling time window violations for routes and excess transit times for paired orders. You can assign a value of Low, Medium, or High. The higher the importance, the more the solver tries to reduce or eliminate the associated time window violations or excess transit time.

Time window violation

Time Window Violation: This property allows you to rate the importance of honoring time windows without causing violations. A time window violation occurs when a route arrives at an order, depot, or break after a time window has closed. The violation is the interval between the end of the time window and the arrival time of a route.

The VRP solution can change according to the value you choose for the Time Window Violation property. The following list describes what the values mean and how the resulting VRP solution can vary:

• High—The solver tries to find a solution that minimizes time window violations at the expense of increasing the overall travel time. Choose High if arriving on time at orders is more important to you than minimizing your overall solution cost. This may be the case if you are meeting customers at your orders and you don't want to inconvenience them with tardy arrivals (another option is to use hard time windows that can't be violated at all).

  Given other constraints of a vehicle routing problem, it may be impossible to visit all the orders within their time windows. In this case, even a High setting might produce violations.

• Medium—This is the default setting. The solver looks for a balance between meeting time windows and reducing the overall solution cost.

• Low—The solver tries to find a solution that minimizes overall travel time, regardless of time windows. Choose Low if respecting time windows is less important than reducing your overall solution cost. You may want to use this setting if you have a growing backlog of service requests. For the purpose of servicing more orders in a day and reducing the backlog, you can choose Low even though customers will be inconvenienced with your fleet's late arrivals.

The next two graphics show the same set of orders and depots; however, the routes are not the same because different Time Window Violation settings were used. The graphic on the left shows the route that resulted from the Time Window Violation's importance set to Low. The route is short, but it has a time window violation. If set to High, the route meets all the time windows, but it is longer because it services the order with a time window first.

Low importance

High importance

Excess transit time

This property allows you to rate the importance of reducing excess transit time. Excess transit time is the amount of time exceeding the time required to travel directly between the paired orders. The excess time results from breaks or travel to other orders or depots between visits to the paired orders.

Calculating excess transit time

The VRP solution can change according to the value you choose for Excess Transit Time. The following list describes what the values mean and how the resulting VRP solution can vary:

• High—The solver tries to find a solution with less excess transit time between paired orders at the expense of increasing the overall travel costs. It makes sense to use this setting if you are transporting people between paired orders and you want to shorten their ride time. This is characteristic of taxi services.
• Medium—This is the default setting. The solver looks for a balance between reducing excess transit time and reducing the overall solution cost.
• Low—The solver tries to find a solution that minimizes overall solution cost, regardless of excess transit time. This setting is commonly used with courier services. Since couriers transport packages as opposed to people, they don't need to worry about ride time. Using Low allows the couriers to service paired orders in the proper sequence and minimize the overall solution cost.

The next two graphics show the same set of orders and depots; however, the routes are not the same because different Excess Transit Time settings were used. The graphic on the left shows the route that resulted when the Excess Transit Time's importance was set to Low. The overall route is short, but the travel time from the first order to its paired order, the airport, is long. If the importance is set to high, the route reduces the time between the first order and the airport while maintaining the same ride time to the airport for the order on the right; however, the overall cost of the route increases.

Low importance (courier)

The Network Locations tab

The parameters on the Network Locations tab are used to find network locations and set values for their properties.

Learn more about network locations

Solving and interpreting the results of a vehicle routing problem

After creating a vehicle routing problem analysis layer, populating the required network analysis objects, and setting appropriate analysis properties, the solution for the vehicle routing problem analysis layer can be obtained by clicking the Solve button on the Network Analyst toolbar.

After solving, if the Output Shape Type property is set to True Shape, the vehicle routing problem solver draws lines along the network connecting starting depots, orders, renewal depots, and ending depots for each route.

The Network Analyst window also updates the Orders class to group all orders by the routes to which they are assigned. The Depot Visits class updates to show the starting, ending, and renewal depots for each route.

On solving, the vehicle routing problem solver ignores any route whose AssignmentRule field value is set to Exclude and any order whose AssignmentRule field value is set to Exclude.

The vehicle routing problem solver then computes an internally managed origin-destination (OD) cost matrix between each of the orders and depot locations using Time Attribute as impedance and Distance Attribute (if specified) as an accumulated attribute.

Learn about OD cost matrix analysis

The VRP solver creates an initial solution composed of the preassigned orders, breaks, and renewal visits if any of these network analysis objects are preassigned to routes. If a valid initial solution can't be found using this preassignment (that is, some constraints are violated), the solve process fails.

While there are unrouted orders, the VRP solver tries to insert the cheapest unrouted order into the best compatible route. The solver tries to resequence orders assigned to a route if the resequencing improves the solution, but it does not move the relative sequence of orders whose AssignmentRule field value is set to Preserve route and relative sequence. For an order whose AssignmentRule field value is Anchor first or Anchor last, the solver ensures that the order is the first one or the last one on the route it is assigned to.

After successfully routing all possible orders, the vehicle routing problem solver outputs the results in the appropriate output fields of the network analysis objects. If some orders can't be routed, the violated constraints are output to the ViolatedConstraints fields in the Orders feature layer. If a route is not used in a solution, its output fields are set to null.

Learn about violated constraints for orders and routes

Interpreting the results of a vehicle routing problem analysis

After successfully solving a vehicle routing problem analysis layer, the routing solution for each route can be assembled by reading the input and output fields of the Breaks table, Depot Visits feature layer, Orders feature layer, and Routes feature layer. For each route, searching by RouteName and looking at the sequence values in Breaks, Depot Visits, and Orders provide the itinerary for the route. You can generate directions to compile a similar itinerary. The Routes feature layer provides a summary of each computed route.