In the first blog I already discussed how important it is, to do incremental tests of your optimization scenario. You should start simple and enhance it to the complex scenario by adding feature by feature. But what are a simple scenario and a good starting point?
Here is my concrete proposal with the focus on the transportation network:
Start with few locations and a- freight units. Three or five freight units are already enough to test most scenarios.
Start with one type of vehicle only. Define only one means of transport. If you want you can already create a few resource instances of it.
Start with the simplest possible cost model: Maintain an overall rate of cost per distance for this means of transport in the cost profile of the planning profile. This implies that there is no lane specific cost so far.
To set the runtime use the optimization profile in your planning profile and set the automatic runtime detection to fast. How to set up more sophisticated runtimes is topic of the blog Effective optimization: run-time.
Now we have to define our transportation network in order to specify how we want to transport our freight. Our network will determine which paths to the network are allowed, how long they need and what they cost.
In a first most simple step we want to define, that we can drive with our vehicle from every location to every other location:
5. We define a zone, put all our locations into this zone and define an intra-zone lane. The intra-zone-lane allows driving from each location inside the zone to any other location of this zone.
During the creation of the intra-zone lane in step 5) we have to do an important decision: How do we decide, how long are the distance and the duration, to travel from one location to another.
The simplest possibility is to manually maintain the duration and the distance of a travel between two locations. To do so you flag the switches for fix transportation duration and/or fix transportation distance and enter the values. If you do that, the maintained duration and distance is valid for all possible pairs of locations in our zone. As result, the routing of the optimizer in this zone will be more or less random. As we use the cost based on distance (3), there is no cost difference between all the possible stages between pairs of locations. The optimizer can only try to plan freight orders with as less stages as possible.
If you don’t select the fixed duration and distance, the Geo-Information-System(GIS) is responsible for deciding the concrete duration and distance for every pair or locations in our zone.
If you now start an optimization run, you can use the explanation tool to see, if the distance calculation of your GIS system is working like you expect it. In the standard few of the explanation tool you see information about locations, zones and lanes. If you know switch to the technical view (Menue->Extras->Technical view On) you can see the additional entry “Distances” . Here you should see different values for the distance and the durations. This entry is usually disabled because of the data volume and the resulting poor performance.
If the distance- and duration-values are ok, it is a good idea to check the planning result the first time. The easiest way is the map. Here you see easily if the routing is meaningful. As long as no dates, opening hours or driving constraints are defined you should see one or several tours with good routing. If there are no critical capacity constraints on the resources you should see no crossing stages of the planned freight orders.
Now you can start to add more and more details to your network:
You can define additional zones to define a more detailed reachability. If groups of locations have the same reachability (for example delivered from the same DC) put them into a zone. This allows you to reduce the maintenance effort for lanes or Hubs
You can define the reachability between different zones and Hubs, by defining the lanes. You can maintain the lanes in a specific manner for every means of transport. For example you can use smaller trucks for the last stage of a delivery (lanes into the zones of customer locations) and larger trucks for the traffic between your DC’s (perhaps lanes between the DC-locations)..
Whenever you want to express that a hub can be used to switch the vehicle, you can define this hub as transshipment-location in TM. You do it by defining the location as hub for (most often) a zone of locations. Then you allow the optimizer to use this hub location to unload the freight and to use another vehicle for the next stage whenever you transport into the zone or out of this zone.
If you define a hub for a location or zone, you should also maintain at least one lane for it. The hub-assignment only explains that it can be used as transshipment location. But we still need information of lanes to see, if we can reach it, with which vehicles and with which cost and durations.
Especially the hubs are a very powerful tool. By each definition of a hub you allow additional alternatives to route the freight through the network. You can define chains and complete networks of hubs. Often this results in millions of different possible routings through the network. The optimizer classifies this routing. The alternatives for every Freight Unit are calculated at the beginning of the optimization run. It concentrates on the best alternatives considering cost, distance and durations. Additionally you can specify the maximal number of hub on each routing in the optimization profile. In most cases you can start here with a high number like 5 or 6. If then detect performance issues you can try to decrease it. But in most cases the focusing on the best alternatives can handle even very large numbers of possible routings. The most critical drawback is that at the beginning of an optimization run the system must read all this possibilities and distances.
If you enhance you network with such hub’s, additional lanes and zones, you should test your network after every sense full changes. As soon as the new network should work again, check if the optimizer can still fins the routings or use the Transportation Network Cockpit: On the “Connection” tab you can test if the system can find a routing from a start location to a destination location.
If there is no routing at all possible, the optimizer reports that. In most cases you can find additional details in the explanation tool (Result->Freight Units). To explain the issue, the optimizer tries to relax constraints like incompatibilities or capacities to give you a hint, what’s the root-cause for the current problem. Nevertheless the optimizer is not planning the freight unit, is stays unplanned.
For the further enhancement of your network, there two additional constructs:
• You can define Default-Routes from a location to another one (or between zones). This can be helpful, if you want to avoid that the optimizer is searching for a route. Perhaps you do that to improve the performance or if you want to explicitly select this route, even if there are other ones, which seem better in term of cost of durations to the optimizer.
• You can define schedules to model regular transportation capacities. For schedules the optimizer is implicitly adding the hub-relation. So you don’t have to maintain the hub-relation to load your freight from one schedule to the next one. This automatic-Hub-Assignment is only active for the main stages: The optimizer follow possible hubs, until you reach a schedule, then it follows the schedule and the possible schedules after it. From there it again follows the hub definition to reach the final destination. To limit the reading of data in the preprocessing we don’t switch several times to this schedule-hub-completion and back to the usual hub-definition.
Here are two examples how zones & co can be used:
Multi- DC’s with traffic between DC’s
Very often we see several DC’s for every DC you define a zone containing all locations which can be delivered by a specific DC. Then you define lanes from this DC into the zone, from the zone back to the DC and an intra-zone-lane. Additionally you define the DC as Hub for that zone. Then you define lanes to connect the DC you can do that with specific lanes or you define a zone for all DC’s and an intra-zone-lane on that zone of DC’s.
You can even save some lane definitions, if you directly include the DC’s into their assigned zones. But you still need the hub-assignment.
Sometimes customers require being the first stop on your delivery tours. You can model that, if you separate your customer locations into two zones: Zone_1st for all customers, which need to be the first delivery stop and Zone_2nd for all the others. Now you define a lane from zone_1st to zone_2nd and an intra-zone-lane for zone_2nd. In a last step you define zone_all containing zone_1st and zone_2nd. If you now define your DC’s as usual to zone_all (lane from and to the DC and the hub-assignment) you have required behavior.
I don’t want to close without mentioning a very common pitfall: The trapped vehicles.
If you assign a Hub A to zone Z, this assignment has no direction in the following sense: It allows you to transport freight out of Z via A and it allows at the same time to transport freight via A into Z.
But if you have lane from the location A to another location B it has a direction! You can use this lane to build freight orders going from A to B. But to come back to A again you need the lane from B to A. That’s mainly because of the integration of the GIS system and the possibility to model one way streets. Most probably it is the same distance from A to B like from B to A. But in the general case the distances and durations may differ. The lane from A to B triggers the GIS system to detect distance and duration from A to B. To get the distance information into the other direction we need the lane from B to A.
If such a backward lane is missing, you may wonder about some messages about trapped vehicles. Because of the asymmetric meaning of the lanes the optimizer would like to use vehicles, but cannot drive them back, where they are needed. These messages are extremely annoying, as they usually don’t appear in the first optimization call. Only after several optimization calls and with increasing number of freight units, the vehicles move more and more into zones without the possibility to escape again. To repair the issue, add the missing lanes to your model.