A very recent question to me is: “What is the Scope of the TM optimization?” The question is simple. But the where should I start with my answer. Let’s concentrate on the Vehicle Scheduling & Routing-Optimizer as the largest optimization engine in TM. Let’s first look onto the process and its Business Objects. Then we can look onto the supported features on these objects. But first I have to begin with the usual disclaimer for feature lists:
This blog describes my personal understanding of the current features. It may contain errors. This list of features is no commitment in any kind for current or future products of SAP. For official statements consider the SAP Product documentation.
The Freight units are the start of the optimization process. They drive as demand the complete optimization process. The Freight Units describe, what we need to transport, form where to where and when.
The optimizer has to match these Freight Units versus available capacity. Capacity could be your own fleet or capacity of your carriers. Trucks and Trailers are one kind of capacity. Schedules and Freight-Bookings are the second usual kind. Whereas the optimizer has to route and schedule the trucks, the schedules contain already the routing (sequence of locations) and dates. The optimizer only has to assign the Freight Units to the schedule. The same is true for already existing Freight Bookings. The LTL-Tariffs are similar, for which the optimizer don’t need to care about routing and scheduling, too.
With that input of Freight Units as demands and the different kinds of capacities the optimizer builds your transportation plans. The results are saved as freight orders, bookings and if required newly created bookings. So we have a first overview like in the following slide.
To be complete, I have to add some additional objects before we start the deep dive. Above I mentioned the Freight Units as Demand. There are other demand classes, too:
A filled container behaves similar to a Freight Unit. It needs to be transported from one location to another one, or to several locations. The optimizer can plan it versus the different capacities very similar to Freight Units. Currently VSR does not support a combined planning putting FU’s into a container and planning it simultaneously on the capacities.
Very similar to Containers. There is just one additional constraint: Rail-Cars require capacities, which have the mode of transport “Rail”.
There is another kind of capacity, too: If you have already existing Freight Orders, you want to use the remaining capacities for additional demands. We call this feature to fill up Freight Orders “Incremental Planning”. Incremental planning will be the topic of a separate blog with all its possibilities to define what changes to existing freight orders are allowed.
To find the right routing for road freight orders and to find the right path through the network the optimizer needs the definition of the transport network. That contains locations, zones, hubs lanes, and default routes. Finally we have some additional constraints in the planning profile.
With this overview we can start to look onto the different objects and all the attributes and features supported inside optimization. Features marked with "BADI" are available in the optimization engine, but not integrated by TM. You can be use them if you provide the necessary data via a BADI implementation.
Locations: Start- and Destination-Location, but also additional locations which the freight must pass (transshipment locations).
Dates: Soft and Hard Intervals for every stop of the FU. Details are explained in note 1908165. If you want to model several alternative intervals, you can use the handling capacity or the opening hours of locations.
Dimensions: describing weight, volume and customer specific dimensions of Freight Units to check versus capacity
Optional constraints on mode of transport, means-of transport, resource instance
Different modes of transports can be planned in one optimization run, even alternative mode for a common Freight Unit.
Planning of complete FU with several stages or only of selected stages, even if some stages are already in execution
Optional non-delivery cost per FU to allow profit optimization (BADI only)
Behave like Freight Units. If required, the planning of Freight Units into Container or Rail-Cars must be done manually before VSR-call.
Capacity-Dimensions: Used to check the weight, volume and customer specific dimensions of the freight assigned to the resource. For each dimension the sum of all loaded Freight units is compared versus the capacity of the truck or trailer. The check is done per stage of the Freight Order. Since 9.1 additional check if length, width and height fit into the capacity.
Decreasing capacity: Reduction of capacity by additional stops to model fragmentation or additional material to separate the load.
Downtime, maintenance with and without location.
Availability and breaks (breaks only for trucks)
Modeling of different carriers by separate means of transport (different rates, different number of resources, different lanes)
Concrete resource instances or multi-resources to model a type of truck and trailer.
Automatic backhaul planning to depot
Vehicle combination to express allowed combinations of trucks and trailers. Combinations can have optional constraints to combine the total capacity.
Routing based on Geo-Information-System (GIS), distances, durations, multiple GIS-Support
Trailer Swaps, predefined secure and unsecured Swap-locations
Constraints on number of intermediate stops, duration and distance of tour
Very rough modeled constraints for duty regulations (max working time per fix or rolling bucket)
Cost: Fix cost per tour, distance and load dependent cost, cost per duration and intermediate stops.
Freight Unit and location dependent loading/unloading durations (BADI), fix duration in profile
Opening hours and handling capacity at locations, for example to model the number of docks. BADI implementation allows these definitions means of transport and Freight Unit specific.
Automatic sorting of loading/unloading activities in Last-In-First-Out-sequence (LIFO)
Dangerous Goods: Support of 1000-point-rule and general incompatibilities
Fix routing and fix dates
Several departures per schedule
Support of cut-off times
Cost: Simple cost value in schedule maintenance, BADI: fix-cost, distance and load dependent cost
Freight-Order-Creation for complete schedule or bookings per pair of locations
Add Freight units to existing bookings
Create new bookings based on schedules.
Cost: Specific fix cost and load dependent cost per Booking
LTL/Tariff based planning
Planning of Freight Unit on tariff based cost and departure rules
Based on cost calculation of the TM Charge Calculation Module.
Currently the complete Freight Unit is planned in one stage with a tariff. Planning of special stages and consolidation of several Freight Units into the same tariff is not supported so far.
Incremental Freight Orders
Add stops to existing Freight Orders or only add Freight Units on existing stops
Limit additional distance and duration
Mark stop as first or last stop
Optional dates to restrict shifting of the schedule
BADI: Restrict additional locations to specific sets of locations
Lanes to define reachability between locations and zones. Lanes can be specified on a general level or specifically for means-of-transport.
Lane based cost definition possible.
Geo-Information-System supported for detail distance and duration determination
Hub-Definition for Cross-docking and change of resources and modes of transports.
Rough planning to allow planning on rough estimations of durations without maintaining resources and without GIS-System.
Optional Default routes to force the routing of specific Freight Units.
Visualization of master data and optimization result in map.
Different kind of incompatibilities
Freight Unit vs. Freight Unit on Truck/Trailer
Freight Unit vs. Freight Unit inside same compartment
Freight Unit vs. Freight Unit on same truck-trailer combination
Freight Unit vs. truck/trailer/schedule/booking
Freight Unit vs. transshipment location (hub)
Freight Unit vs. compartment
Truck/trailer vs. truck/trailer in same truck-trailer combination
Truck/trailer vs. location to stop this truck/trailer at this location as part of a combination
Truck/trailer vs. location to load this truck/trailer at this location
Truck-trailer combination vs. location
BADI: Ship-With, set constraints that Freight Units must be transported together
BADI: sustainability, additional fuel cost per distance and/or load
Beside the detailed features on the Business Objects there as some more features to mention:
Seamless integration into TM
Repair mechanisms to exclude inconsistent data. Otherwise inconsistent data could lead to infeasibilities and stop the optimizer or lead to wrong decisions.
Most parameters to control the search progress are set automatically. The main exception is the runtime for batch processing.
You can use panning profiles to model different planning steps and planning goals with the same engine.
The explanation tool allows you a close look into the data. It shows detailed information about exceptions on the level of the different object instances (For example freight unit XY cannot be planned because of its Mode-Of-Transport-Constraint).
Finally lets have a look the the usual volumes, on which the VSR-optimizer is called:
If you call the optimizer for Transportation Proposal or for Sales-Order-Scheduling, you see the smallest volumes: usual one Freight Unit in rare cases two or three.
For local truck and trailer routing scenarios we see volumes from 200 to 3000 Freight Units
For more regional or national planning we see usual volumes of 500-8000 Freight units
For continental or global scenarios 5000-20000 Freight Units are usual.
Larger scenarios are usual spitted into different runs of smaller sizes.
As the number of Fright Units is important for performance, you have the possibility to influence the volume by your freight unit building rule.
Until now the development on the VSR engine has been running for more than ten years. During this long time a lot of efforts were invested to continuously improve the performance and plan quality of the solver. In parallel more and more features have been added and the combination of sometimes contradicting features has been fine-tuned.
We now have a very fast engine with a unique combination of features. Nevertheless, you see that still enough processes and features are remaining. We work hard to fill the gaps and even increase the performance.