Performance - White Paper

VSR Optimization
Modeling and Performance Guide
for SAP Transportation Management

Development Team Optimization

Document version 1.2 – October 2014


© Copyright 2010 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any
form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior
notice.
Some software products marketed by SAP AG and its distributors
contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered
trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p,
System p5, System x, System z, System z10, System z9, z10, z9,
iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390,
OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM,
Power Architecture, POWER6+, POWER6, POWER5+, POWER5,
POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System
Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks,
OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner,
WebSphere, Netfinity, Tivoli and Informix are trademarks or
registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and
other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either
trademarks or registered trademarks of Adobe Systems Incorporated in
the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the
Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,
VideoFrame, and MultiWin are trademarks or registered trademarks of
Citrix Systems, Inc.
Typographic Conventions
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf
Germany
T +49/18 05/34 34 34
F +49/18 05/34 34 20
www.sap.com
HTML, XML, XHTML and W3C are trademarks or registered
trademarks of W3C®, World Wide Web Consortium, Massachusetts
Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc
JavaScript is a registered trademark of Sun Microsystems, Inc., used
under license for technology invented and implemented by Netscape.
SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge,
ByDesign, SAP Business ByDesign, and other SAP products and
services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP AG in Germany and in
several other countries all over the world. All other product and
service names mentioned are the trademarks of their respective
companies. Data contained in this document serves informational
purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials
are provided by SAP AG and its affiliated companies ("SAP Group")
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any.
Nothing herein should be construed as constituting an additional
warranty.
Disclaimer
Some components of this product are based on Java™. Any code
change in these components may cause unpredictable and severe
malfunctions and is therefore expressively prohibited, as is any
decompilation of these components.
Any Java™ Source Code delivered with this product is only to be used
by SAP’s Support Services and may not be modified or altered in any
way.
Type Style Represents replace these words and
characters with appropriate
Example Text Words or characters that entries.
appear on the screen. These
include field names, screen EXAMPLE TEXT Keys on the keyboard, for
titles, pushbuttons as well as example, function keys (such
menu names, paths and as F2) or the ENTER key.
options. Icons
Cross-references to other
documentation
Icon Meaning
Example text Emphasized words or
phrases in body text, titles of Caution
graphics and tables Example
EXAMPLE TEXT Names of elements in the
Note
system. These include report
names, program names, Recommendation
transaction codes, table
names, and individual key
words of a programming
language, when surrounded
by body text, for example,
SELECT and INCLUDE.
Example text Screen output. This includes
file and directory names and
their paths, messages,
names of variables and
parameters, source code as
well as names of installation,
upgrade and database tools.
Example text Exact user entry. These are
words or characters that you
enter in the system exactly
as they appear in the
documentation.
<Example text> Variable user entry. Pointed
brackets indicate that you
Contents
1 History of Changes ...............................................................................5
2 About this Paper ...................................................................................5
3 Overview to VSR Optimizer..................................................................6
3.1 Starting the Optimizer ................................................................................ 6
3.2 Phases of the Optimization ....................................................................... 6
3.3 Parallel Processing .................................................................................... 7
4 Dividing into sub-problems .................................................................7
5 Resources .............................................................................................8
5.1 Means of Transport .................................................................................... 8
5.2 Trailer .......................................................................................................... 8
5.3 Scheduling Constraints (Driving Times) .................................................. 9
5.4 Multi-Resources, Compartments, Load Costs ......................................... 9
6 Geography ...........................................................................................10
6.1 Zones and Lanes ...................................................................................... 10
6.2 Reference Coordinates ............................................................................ 10
6.3 Transshipment Locations ........................................................................ 11
7 Freight units ........................................................................................11
7.1 Dates and Times....................................................................................... 11
7.2 Incompatibilities ....................................................................................... 12
8 Others ..................................................................................................12
8.1 Horizons.................................................................................................... 12
8.2 Runtime..................................................................................................... 12
8.3 Incremental planning ............................................................................... 13
9 System Landscape .............................................................................13
9.1 SAP Transportation Management-Systems and Optimization Server .. 13
9.2 Hardware................................................................................................... 14
10 Sum up Recommendations................................................................14
10.1 Runtime and Planning Quality ................................................................ 15
10.2 Memory ..................................................................................................... 15
10.3 Setting up the solution ............................................................................ 15
11 Appendix – Some Sizing Figures ......................................................17
11.1 Memory Consumption ............................................................................. 17
11.2 Runtime to calculate initial solution ....................................................... 18
 VSR Optimizer Performance Whitepaper

1 History of Changes
The following table provides an overview of the most important changes made in the latest
versions.

White Paper Version Important Changes

1.0 Initial version of White Paper
1.1 Minor adaption, new layout
1.2 Incremental planning

2 About this Paper

The aim of VSR optimization (VSR = Vehicle Scheduling and Routing) is to assign freight
units to capacities (for example, vehicle resources) in a cost-effective way, while adhering to
constraints, and to determine the sequence of deliveries and transportation dates/times. This
means in detail: For each freight unit the optimizer must decide
 which transshipment locations will be used,
 which means of transport will be used on the different stages - this could be
trucks of different sizes, trailers, schedules, booking orders or direct shipment
options,
 how to schedule the resulting freight orders to satisfy opening hours at customer
locations, requested dates and times, constraints for driving times, and a lot of
other details.
Since all these decisions influence each other, it is not easy to find the optimal solution. For
example, a transshipment location can save cost if there are enough other freight units so
that you can consolidate them. But some freight units may not be allowed to move together.
Additionally there is a permanent competition between the freight units to get some of the
valuable transportation resources.
With a growing number of each of the above mentioned objects, the number of possibilities to
plan one freight unit increases rapidly, so that each decision gets more and more complex
and the problem is much harder to solve. For example, in a scenario with 1 DC and 10 freight
6
units to be shipped with 1 truck, there are approximately 3.6*10 alternatives, whereas the
158
number of alternatives increases to approximately 9.3*10 , if you only increase the number
of freight units and trucks by a factor of 10.
This white paper will give you some insights to understand the importance of a good
modeling of the transportation scenario and the consequences for the optimizer. You will find
several recommendations and hints, how to model transportation problems in such a way that
you can solve your transportation scenarios fast, and with very good results by the optimizer.
This paper will concentrate on the VSR optimization. The same optimization server is used
for the transportation proposal, too. Most of the recommendations will also improve the
proposal-process. The Carrier-Selection-Optimizer is not covered in this paper.

5
VSR Optimizer Performance Whitepaper

3 Overview to VSR Optimizer

3.1 Starting the Optimizer
If you start VSR optimization from interactive planning or in the background, there will in a
first step be a collection of all selected data in the SAP Transportation Management
application. Afterwards an optimization process will be started, which can (and should) run on
a different server than the application server. In this case we use the Remote-Control-and-
Communication – Framework (RCC) to start up the optimization process. When selecting the
server the RCC is checking the priority and the remaining capacity (in free slots) of the
possible optimization servers. On the one hand you can use this step to prefer special
servers by priorities of the connection, and on the other hand you get an automatic load
balancing between servers of the same priority.
After starting the optimization process, the complete selected data of the transportation
scenario is transferred to the optimization server. The optimizer itself has no internal
database, but receives always the complete data set. This avoids consistency problems in
your data between application server and optimizer. Additionally this allows an easy switch of
using one optimization server for several installations of SAP Transportation Management
and using several optimization servers in one SAP Transportation Management installation.

3.2 Phases of the Optimization

The optimization itself consists of 3 phases:
1. Model-Creation-Phase building up the internal representation
2. Initialization-Phase creating the first complete solutions
3. Improvement-Phase improving the solutions
In the Model-Creation-Phase the optimizer reads the data which is transferred during the
start-up and stores it in an internal structure, which is ideal for the following computations. In
a second step there are running several checks to find any inconsistencies of the data and to
repair them in such a way, that the following optimization is not disturbed. During this phase
the most of the messages and items of the explanations are created.
Within the Initialization-Phase some first complete solutions are created, in which all freight
units should be planned (=assigned to capacities). If a partial solution was passed to the
optimizer (e.g. a result from a previous optimization run which should be enhanced by some
new freight units), this solution will be used as base for the new first solution. Adding
unplanned freight units into a partial solution is done by a so called insert move. This move
selects an unplanned freight unit and enumerates alternatives for inserting it into the
transportation plan. If the freight unit can use different routings through the network, e.g. use
different pairs of ports for passing an ocean, all possible routings will be considered. For each
routing the alternative means of transports which are available for the different legs (e.g. pre-
carriage to a port by rail, main-carriage by vessel, and on-carriage by truck) are taken into
account. Usually the vehicle resources of one means of transport differ from each other, e.g.
vessels by their departure times or trucks by their performed tours. This leads to different
solutions regarding final tours and especially the time when the freight units will be delivered.
Among all those solution candidates for one freight unit, the most promising one regarding
the transportation cost (including possible penalties for early/late delivery) will be selected.
The main goal of the Improvement-Phase is to optimize the routing of the existing tours
(minimize travelled distance or re-arrange the visit sequences by the opening hours of
customers to minimize waiting times) as well as improving the assignment of freight units to
tours. This includes the selection of resources (means of transport) for the tours and in case
of trailers additionally the selection of tractors. The Improvement-Phase is usually the most
time consuming phase of the optimization run.

6
 VSR Optimizer Performance Whitepaper

The Improvement-Phase will end when the time limit is reached, or no improvement is found
after a certain period of time. These values can be maintained in the optimization profile.
After finishing the Improvement-Phase some small end-up procedures are done: The result is
mapped back in a format suitable for SAP Transportation Management, the engine completes
the explanation and sends the result and the explanation back to the application server. As
last step RCC will mark the optimization server as free again to allow further optimization
runs.

3.3 Parallel Processing

In two phases the optimizer can use several cores in parallel
 During the initialization phase the optimizer can execute different initialization
heuristics in parallel. This limits the number of parallel used cores to the number of
different initialization heuristics. Currently five such heuristics are used. Each
heuristic for its own is not changed. Therefore you get nearly no speed up until the
first solution is found (beyond 5), but you can speed up the complete phase by a
factor of 5 (compared to using only 1 core).
 During the improvement phase the optimizer can use as many cores as you want.
Dependent on the scenario this can result in an enormous speed-up or in small
improvements only. You need to check how your scenario will benefit by parallel
processing.
Nevertheless you should always start to solve the problem in a serial manner without parallel
processing. After understanding the serial run, you can think about a speed up by parallel
processing as a subsequent step.

4 Dividing into sub-problems

As written in the introduction, with growing scenario size the number of alternatives to
consider grows more rapidly. One could try to use parallelization inside the optimizer to
increase performance, but even in the best case parallelization provides at most a linear
speedup.
From a performance side, a decomposition of the problem into several smaller sub-problems
leads to a higher increase, because the number of alternatives grows much more than linear.
The sum of the alternatives for the sub-problems is much smaller than the number of
alternatives in the combined scenario.
Dividing a problem into smaller sub-problems does not only increase the performance in the
sum of the sub-problem, it additionally allows to solve the different sub problems in parallel
which leads to additional performance increase.
Due to the fact that each sub-problem contains comparatively less alternatives, each sub-
problem is easier to solve and the overall solution will be better.
Another side effect is a smaller memory consumption when dividing into sub-problems. The
memory consumption is mainly driven by distance information, the optimizer needs
information on travel time and distance for every pair of locations (plants, customers, DCs
etc.) and means of transport. Having e.g. 1 means of transport and 100 locations in sum, the
combined scenario has 10,000 location pairs, while dividing it into 5 sub-problems with 20
locations each the total number of location pairs is equal to 5*20*20=2,000.
Beside the technical aspects, separated sub-problems give the planners the freedom to
decide independently when they need an update of their plan. This allows much faster
reaction to changes in your business and avoids a lot of communication between the
planners. SAP Transportation Management will coordinate the dependencies like the
constraints between stages for you

7
VSR Optimizer Performance Whitepaper

When splitting up a problem you should involve your planners, because they know best how
the complete scenario looks like and how it could be split into independent sub-problems. In
most cases they already have experience how to split the planning work to different planners,
because they did that already before using SAP Transportation Management.
The following rules were mainly used (but not the only possibilities):
 Divide problem by geography: The sub-problem definition is done by e.g. region,
plant or DC
 Divide problem by product group: If the scenario incorporates different product
groups which are incompatible for transporting together (e.g. frozen and non-frozen
products or liquid products and packaged goods), the split can be done according to
the related rule
 Divide problem by time horizon: Set up different optimization runs for the short term
planning for the next day(s) and for initial planning for the next weeks
 Reduce problem by separate planning of full truck loads, and less-than-truck-load
freight units.

5 Resources
5.1 Means of Transport
One of the basic elements for planning are the resources (truck, trailer, etc.) which perform
the tours for moving the freight units. The different resources are grouped to means of
transport. Each means of transport defines a cost structure and a set of possible lanes
through the network which the optimizer has to evaluate in order to find the optimal solution.
As written above when introducing the optimizer, each extra means of transport creates
additional alternatives, which decreases the performance of the search. Therefore, for a
performance reason, as little as possible different means of transport should be defined. In
case of using external freight forwarders without an own fleet, only means of transport which
really differ by speed or ability to reach different locations should be presented for the VSR
optimization to build tours, while the assignment of tours to the different carriers should be
done by a carrier selection optimization. That is, if there are for example 3 carriers which
have large, slow trucks and small, fast trucks, VSR optimization should receive 2 means of
transport, one for the large and one for the small trucks to assign freight units to tours. The
carrier selection optimization would then receive the tours and all carriers with their trucks to
select the cheapest carrier while additionally respecting business shares and freight
agreements.
Another relevant aspect for reducing the number of means of transport, beside reducing the
number of alternatives, is the memory consumption, since in general each means of transport
has its own distance information to represent the possible lanes, which usually is the main
driver for memory consumption during the optimization. The less distance matrices involved,
the less memory is needed for optimization which could lead to a smaller and cheaper server
regarding main memory. If different means of transport are necessary because of significantly
different cost structures but the same distance information, the use of hierarchies in the
means of transport definition is required, where the topmost means of transport should be
assigned to the transportation lane.

5.2 Trailer
There are various ways and use cases to model trailers for a transportation problem, be it
additional transportation capacity when delivering products from a plant/warehouse to the
customers in production or retail scenarios, or be it the dynamic way in freight forwarding

8
 VSR Optimizer Performance Whitepaper

where complete trailers have to be moved between different locations including changing the
tractor. In general the usage of trailers increases the complexity of the problem significantly,
because there is another dimension of decisions to be taken which tractor has to pull the
trailer, and at which locations should it couple or release the trailer.
In many scenarios there is an alternative modeling possible that has a smaller impact on
performance. If the trailer can be considered as additional capacity for a tour, or has a fixed
assignment to a tractor, that combination of tractor and trailer should better be modeled as
one active resource with the sum of the capacities.
From a performance point of view, trailers should only be used if there are variable locations
for coupling and uncoupling, and when trailers should change the tractor frequently.

5.3 Scheduling Constraints (Driving Times)

In most countries there are legal driving time regulations for trucks. It is possible to model
many of them for the optimizer. But due to their nature, they require a lot of additional
computation effort to ensure feasibility.
For performance reasons we recommend to use as few as possible driving time constraints.
E.g., when planning for only one day, the constraints dealing with working time per week can
be omitted. When planning transcontinental transports with a length of several days,
constraints for each single and small break are mostly needless because the actual traffic
situation forces to adapt the plan, or has some kind of fuzziness already planned within.
For the constraints itself, we recommend to prefer fixed time window constraints against
rolling time window constraints.

5.4 Multi-Resources, Compartments, Load Costs

For the use of multi-resources there is, from an optimization point of view, no restriction,
especially when having the possibility to use additional transportation capacity from external
freight forwarders. There the different freight forwarders could be handled best as one means
of transport in the VSR optimization and the selection which one is best should be done by
carrier selection.
Compartments are completely supported by the optimizer. On one hand they give you a
strong possibility to model constraints on the usage of your resources. On the other hand
they can result in a lot of detailed checks which must be evaluated during each small change
of the current solution during optimizing. This can impact the run time of the optimizer or the
quality of the solution. Therefore we recommend to use compartments carefully. If you want
to use compartments, compare test runs with and without compartments to find the best level
of detail to express all necessary constraints with minimal decrease of performance and best
possible solution quality.
The relative utilization of resources is usually the result of the different cost settings for fixed
cost, distance related cost and penalties for earliness and lateness. Nevertheless you can
use a load cost function to represent the wish of some kind of minimal truck usage for a tour.
This will add additional soft penalties to the optimization run to force the optimizer into the
specified search direction. But before adding load cost functions you should carefully
examine why you current cost settings lead to an unwanted usage. The starting point for that
kind of analysis is the detailed information for the freight orders in the explanation tool. The
drawback of load cost functions is their effect on the search process: High penalties on low
usage of trucks hinders the optimizer to start new tours with only a few freight units and to fill
up this tour later during the search process. That can slow down the optimization or even
prohibit some partial solutions which are needed to find the wanted plans.

9
VSR Optimizer Performance Whitepaper

6 Geography
6.1 Zones and Lanes
Each transportation problem requires several locations, at least as source and destination for
the freight units. To be able to transport the goods between the different locations, lanes are
needed, which describe the distance between the location and the time needed, as well as
other costing information for the connection.
To receive good optimization results with meaningful tours, appropriate lanes have to be
defined, but defining all theoretically possible lanes would not be the best solution, in addition
to the effort maintaining all lanes. The more possibilities for connecting two locations exist,
the more alternatives have to be considered during optimization, including all those
alternatives leading to a proven non optimal solution.
We recommend to group locations into zones where inside a zone the locations use distance
information on the most detailed GIS level. Between the different zones only those lanes
should exist where the two zones can be reached directly by each other.
If some lanes would be forbidden (e.g. crossing the ocean by truck) or are not wanted at all
(e.g. small truck for regional deliveries should not be used for global transports), there should
not exist a corresponding lane. This means that only the real required lanes should be
maintained and not everything possible.
Maintaining only the required lanes has two main benefits
 The optimizer can concentrate on checking promising routing alternatives. This
results in a speed up of the search process and in better planning results.
 The information about the distance and the duration between locations is the
dominating amount of data. If you have n locations you have to handle O(n*n) such
distance information. Reducing distance information significantly reduces the
memory consumption.
Compared to the dividing the problem into sub-problems, you have here a fine grained
instrument to prohibit transportation options that you don’t want to consider.

6.2 Reference Coordinates

Even if you reduce the possible lanes to a minimum, they may need a lot of memory, to save
all the distance and duration information. For this case there is the possibility to switch from a
very detailed distance and duration information to a more aggregated model: For short
distances you can still work with the detailed information, but for large distances you can use
a aggregated value which is shared for several location pairs.
An example: besides having the real coordinates for locations near New York City for
transports in the state of New York, one could have the coordinate of NYC for all that
locations if a transport should go to somewhere in California (destination could have
coordinates from L.A. as reference coordinates).
Reference coordinates significantly decrease the memory needed to store distance
information for the problem since lots of locations pairs would share a acommon entry due to
the same pair of reference coordinates. Furthermore, processing the data would be faster,
since less data has to be processed.
There are two pitfalls you should have an eye on:
 The limits to use references should fit ideally to your rule to set the reference
coordinates. Usually the distance between reference coordinates must be smaller
than the threshold x to switch to the reference coordinates. Otherwise locations a
little bit further away from each other than x could have a resulting distance of far
more than x if the reference locations have larger distance than x, which needlessly
distort the truth.

10
 VSR Optimizer Performance Whitepaper

 Locations with the same reference coordinate should belong to the same zone.
Otherwise they might have different allowed lanes, but the optimizer would use the
lane from the reference coordinate, if it is defined for at least one zone, even if it is
not allowed for the other zone.
If you use reference coordinate you usually will do that with a Geo-Information-System to
extrapolate all the coordinates and distances. Nevertheless you still can override distances
and durations in the maintenance of lanes. For the optimizer it is more memory-efficient to
use GIS and reference coordinates only, because they can share distance information, which
is not the case if distance or duration is specified on the lanes. In this case the optimizer
internally must handle it on location level without sharing of information. For the
preprocessing before an optimization run it is the other way around: Using fixed durations
and distances at lanes is reducing the buffered data in the TM system and can improve the
performance of the preprocessing.

6.3 Transshipment Locations

In many optimization problems it is necessary to use transshipment locations that may
represent a train station, or sea port, where the freight units change the mode or means of
transport. In general, any kind of transshipment location network is supported, but the more
complex the network is, the more theoretical alternatives exist to transport the goods, and the
more solutions regarding different transshipment locations must be considered, each one
with different trucks and tours to use for the freight units. Shortly spoken, the larger and the
more complex the network, the less performance can be expected.
Most times it is more or less clear which transshipment locations are meaningful to use for a
specific freight unit, e.g. for freight units from US east cost to Europe, ports at the east coast
of the US and ports in Europe have to be considered, while ports at the west coast of the US
or in Asia won’t make sense. Therefore the number of alternative transshipment locations for
the freight units should be restricted to minimize the number of routing alternatives for the
SAP Transportation Management and to increase the performance compared to allow the
complete network to be used. Restricting the alternative transshipment locations to a small
set of meaningful ones by the planners would even help to achieve one of the alternative
expected.
The other dimension is the number of transshipment locations to use in a chain for a freight
unit, which corresponds to the number of times the freight units is being reloaded to another
resource. Most times there are few chains of transshipment location meaningful for the freight
unit and not every possible combination of transshipment locations. E.g. for transporting
goods from Chicago to Munich the planner knows that either the ports of Newark and
Hamburg with an additional transshipment location in Frankfurt can be used, or as alternative
Boston – Rotterdam and Paris should be used, while all other ports and transshipment
locations can be ignored for that freight unit. With the use of such transshipment location
chains the number of alternative routings for freight units can be restricted to a small number
which represents the alternatives preferred by the planners, while all other theoretical
possible but most times nonsensical options weren’t taken into account and therefore don’t
slow down the search.

7 Freight units
7.1 Dates and Times
One of the decisions which has to be taken by the optimizer is the time when a freight unit
has to be loaded initially (at the plant, warehouse, etc.) and the time at the destination
location to be delivered. One can maintain hard dates which forces the freight unit not to
violate that dates (e.g. material availability at a production site, it can only be transported after

11
VSR Optimizer Performance Whitepaper

being produced), the other option is to use requested dates with penalties for being early or
late, as well as combinations of all. E.g. requested delivery date for a freight unit can be next
Wednesday, Tuesday can be used, but it would cost some penalty as well as delivering late
up to Friday (lateness cost might be worse than earliness cost), but delivering earlier than
Tuesday or later than Friday is not allowed.
We recommend to use cost for earliness and cost for lateness (cost factor can be different)
for at least loading or unloading, where there can be one single point (e.g. exactly 5:00 p.m.)
or an interval (e.g. 2:00 p.m. until 5:00 p.m.) where the freight unit is on time. Without such
costs the freight units can be planned anywhere within the planning horizon and represent
the optimal solution regarding loading/unloading point of time.

7.2 Incompatibilities
Products which are to be transported can have different characteristics. This might be the
packaging type (e.g. pallet, packaged goods or bulk material) or handling type (needs e.g. to
be transported frozen or is a dangerous good). Transporting different freight units with
different characteristics in one optimization run means that different resources and resource
types must be available where usually not every resource is allowed to transport every freight
unit. This is modeled with incompatibilities which forbid, e.g., assigning freight units to
resources or to compartments, to use several transshipment locations (e.g. packaged goods
can’t use a port with only container terminals), or just to transport two freight units at the
same time with the same truck.
Each incompatibility reducing the number of resources or alternative transshipment locations
increases the performance of the optimizer since less solutions have to be evaluated.
Depending on the kind of characteristic it should be considered to split up the problem into
several sub-problems (see above) when the sub-problems are mostly disjoint.
Incompatibilities between different products within a resource reduce the number of tours
where a freight unit can be assigned, but on the other hand make feasible and good
combinations harder to find.

8 Others
8.1 Horizons
The planning horizon represents the interval of time where all transports have to be planned.
This horizon should include all requested dates for freight units (otherwise they can’t be on
time and would always cause penalty cost for being early or late) as well as at least a
subinterval of a hard time constraint for the freight units. Having home bases for resources
(e.g. where the trucks have to return after their tours) one has to ensure that the planning
horizon allows the return trip.
On the other hand, the planning horizon should be restricted to a short amount of time to
minimize the number of alternatives the optimizer has to evaluate. In addition, when having
scheduled vehicles, a shorter planning horizon reduces the number of schedules resulting
from the departure calendar, which furthermore decreases the number of alternatives to
consider.

8.2 Runtime
A frequent question is “how to determine the runtime of the optimization run”. To find a good
runtime for your scenario you need your scenario modeled as completely as possible
regarding features and constraints and you should have the data volume in your system like
you expect it for your productive use.

12
 VSR Optimizer Performance Whitepaper

Then you first start the optimizer with a very long runtime, perhaps during the complete
weekend. After the optimization run you analyze the progress of the total cost with help of the
explanation tool. Here you should see a fast decrease at the start of the run and a very slow
decrease of the cost at the end. You should use this progression of the cost over the time to
decide, which runtime and solution quality fits best to your requirements.
SAP recommends to start this analysis single threaded with on CPU only. After defining a
good runtime for one CPU you can try to improve the runtime further by parallelization.

8.3 Incremental planning

Since TM 9.2 the optimizer supports incremental planning. If a Freight order is marked as
incremental it is not deleted in the next optimization run. It can only be enhanced by new
stops or new Freight Units.
Until know the incremental behavior can only be controlled in the planning profile for all
freight orders. The incremental planning has the following impact on the performance:
 If you do usual VSR optimization the incremental planning sticks on the decisions of
Freight Units that they are on an incremental FOR. Because of that the search space
is smaller and the optimization run should work faster. For example this is the case, if
you run your optimization every 10 or 20 minutes. In this case only the new arrived
Freight Units must be planned, whereas for all already planned Freight Units only
some dates are adapted.
 For the proposal it can be vice versa: If you want to plan new FU’s via proposal to
incremental Freight Orders, you must activate the context determination, to read all
FORs as input for the Proposal. This increases the data volume which must be
handled by the optimizer and will slow down the optimization process.

9 System Landscape
9.1 SAP Transportation Management-Systems and
Optimization Server
A complete SAP Transportation Management System consists of one database server, one
or several application server(s), the optimization server(s) and maybe some additional
server(s), e.g. for GEO-Coding.
In principal you can install the optimizer on either one of the other servers, for example on the
application server. But you shouldn’t forget that the optimizer will need a lot of CPU power
and memory during an optimization run. For this reason, you have to keep these peaks in
mind when you size your application server. Usually this results in higher costs than
separated servers and you have the permanent risk that an optimization run with a very high
peak can influence your ongoing business on the application server. SAP recommends to
use separated server, especially for productive systems.
For one SAP Transportation Management System one or several optimization servers can be
used. It may be a good idea to start with one optimization server and to add additional
servers when the system grows and more optimization runs must be done in parallel.
On the other side, one optimization server can support several SAP Transportation
Management Systems, which might be useful for development and test systems that can
share an optimization server. There might also be several versions or support pack stacks of
the optimizer on one optimization server. But within the productive environment we usually
recommend to connect one optimization server to only one SAP Transportation Management
System.

13
VSR Optimizer Performance Whitepaper

9.2 Hardware
In general each optimization run needs at least on core of a CPU (when running internal
parallelization it would need more cores, depending on customizing) and a scenario specific
amount of main memory exclusively for that optimization run. Depending on the number of
optimization runs which should be done in parallel, the total number of cores and the total
amount of main memory necessary can be estimated. Be aware of the fact that operating
system functions also run on each optimization server. A server with e.g. 4 cores and 8 GB
main memory can run 4 scenarios requiring 1 core and 2 GB main memory each or 1
scenario 4 times internal parallelizes using up to 8 GB main memory. For rough estimations
of the memory consumption we refer to SAP note 1148444, where the latest quick-sizer for
optimizer memory consumption is available.
Selecting the hardware you should focus on two criteria:
 CPU-Power
The CPU will mainly influence the needed runtime to solve your scenario in the
requested quality. Therefore you should use one of the fastest available CPU’s. You
can use the SpecInt benchmark for the CPU power at http://www.spec.org to select
the machine. You should mainly focus on the single threaded performance.
 Memory and possibility to enhance memory
Like mentioned above, you can calculate the required memory on your machine.
Beside the fact of the currently needed memory, you should additionally check if it
will be possible to enhance the memory in future, if the business volume will increase
or you will need further optimization runs. Usually in today’s hardware the memory is
more restrictive than the CPU power.
 Local Hard-Disc
The optimizer should be installed on a local hard disc. You should avoid to load it via
network from other disc spaces. The transfer via network and the possible check of
anti-virus software can slow down the start of the optimizer. We saw this especially
for calls of Scheduling or Proposal, which are usually short.
Beside of that the local hard disc is used for traces. Usually we propose at least 1 GB
disc space. Writing the traces via network could slow down the optimization process.

You can usually avoid to buy expensive fail-safe hardware for your optimization server,
because there is no database on it, so there is no danger of data lost. The load-balancing of
RCC will automatically go to the next optimization server if one server would be down.
So you can benefit a little bit in splitting your hardware for optimization into different smaller
servers. That is in most cases even cheaper than a very large server. On the other hand, you
should plan with enough reserve that the scenarios can be solved on each server, even if the
volume will increase a little.
It is no problem to enhance a running SAP Transportation Management with an additional
optimization server during the live-time of the system. It may even be a good idea to
modernize the optimization hardware after several years to directly benefit from latest CPU
improvements and to save money with better transportation plans.

10 Sum up Recommendations
In this section we shortly sum up all the most important recommendations. The suggestions
are listed by their importance.

14
 VSR Optimizer Performance Whitepaper

10.1 Runtime and Planning Quality

From a runtime and planning quality point of view the recommendations are
1) Divide the scenarios into independent sub-problems
2) Model your scenario with as little different means of transport as possible
3) Try to model complete vehicle combinations instead of separate trailers,
unless the trailer must change their movers
4) Involve expert consulting for fine tuning of the scenario setup
5) Use zones and lanes to focus the search on meaningful alternatives regarding
distance information
6) Using compartments or load costs carefully, examine their impact on the
optimization process
7) Minimize usage of driving time constraints and favor fixed towards rolling time
windows
8) Restrict number of alternative transshipment locations
9) Use transshipment location chains to express routes through the network
10) Use optimizer internal parallelization only as last measure

10.2 Memory
From a memory point of view our recommendations are
1) Divide the scenarios into independent sub-problems
2) Model your scenario with as little different means of transport as possible
3) Use hierarchies of means of transport when having the same distance information
4) Use zones and lanes to reduce the required distance information
5) Use reference coordinates to reduce detailed information for long distance
connections

10.3 Setting up the solution

After elaborating on all the objects and aspects to watch when setting up a planning scenario
using the VSR optimizer, this last section includes some guidelines on how to proceed in an
implementation project.
When setting up a solution, it is very important to have a clear picture about the scenario and
planning problem to be solved. It is key to identify
 the relevant constraints/restrictions and
 the key decisions to be taken.
The VSR optimizer allows to define lots of constraints (e.g. vehicle resource capacity,
opening hours of locations, handling resource capacity at locations, pick-up and delivery time
windows, loading and unloading durations). While considering all the details may give you a
very accurate picture of the real life in the system, the resultant optimization problem may be
hard to solve and suggest more accuracy than can be reached in reality due to deviations
between plan and execution. Therefore, it is important to think about, which are the
constraints that will influence the solution and model those in the system.

15
VSR Optimizer Performance Whitepaper

The same holds true with respect to the objective function of the VSR optimizer. The VSR
optimizer minimizes a cost function made up of freight unit dependent cost (e.g. non-delivery,
earliness, lateness) as well as vehicle resource related costs (e.g. fixed cost, distance
dependent cost, duration dependent cost). The sum of all costs are minimized. Specifying the
“right” cost values is key to finding the desired solution. A simple example can illustrate this
situation. Assume, a customer is served from a distribution center and this customer orders
each day goods corresponding to the size of a half-full truck. Then the system may either
propose to deliver daily to the customer, which is not very efficient with respect to vehicle
utilization or the system may propose to deliver every other day, which is efficient with
respect to vehicle utilization, but less good with respect to service level of customer
deliveries. The VSR optimizer can create both solutions, but the one presented to the user is
governed by the cost setting. The first solution is chosen in case vehicle costs are small
compared to freight unit dependent costs (earliness/lateness), while the second solution is
chosen in the opposite situation.
Depending on the scenario, you may prefer either one. To understand the impact of different
cost settings on the behavior of VSR optimizer is key to set up a planning scenario. Thus, it is
important to clearly understand the planning objective and set up the system accordingly.
Other decisions that may be influenced by different cost settings are, e.g., consolidation vs.
direct delivery.
To validate the conceptual correctness of the VSR optimization solution, it is recommended
to test based on a rather small scenario, because in this situation, the (human) planner has a
chance to validate the result with a manual solution. This may no longer be possible, once
too many freight units, vehicle resources and constraints are to be respected.
However, at the same time, it is important to validate the performance of the optimizer on a
realistic scenario (volume-wise). The planning problem is a hard optimization problem and
therefore may require a reasonable amount of time to end with a business acceptable
solution. It is important to note that not only the time to calculate a reasonable solution within
the optimization engine, but also the retrieval of relevant information (e.g. distance matrix)
from the SAP Transportation Management System application may require a significant
amount of time.
Finally, it is important to keep in mind that the VSR optimizer does not solve everything, but
the performance and solution quality may be significantly impacted by decisions and settings
you have done outside of the VRS optimization domain. The most important topic to mention
here is freight unit building. Freight units are the incoming objects for the VSR optimizer. Your
decision on e.g. split values can severely impact the behavior of the optimization engine. Just
think about the combinatorial effect of creating freight units per individual pallet compared to
creating freight units in multiples of 10 pallets. It is strongly recommended to do as much
consolidation as possible already at freight unit creation.
Similarly, you should avoid defining individual means-of-transports per carrier. Carrier
selection is done by a separate optimization engine and you should avoid trying to code the
carrier costs into your means of transport specific costs. The VSR optimization is
conceptually more aimed at finding the right means of transport (FTL vs. LTL, or truck vs.
rail), while the decision which carrier to subcontract is made in a separate planning step
thereafter (of course, the transportation management application allows you to define
planning strategies executing this individual steps sequentially without further user
interference).
As planning and optimization is recognized a non-trivial topic, SAP has set-up a consulting
offer to help customers in modeling their scenario and trying to find the right cost settings.
Details of this offering are described in SAP note 1143744.

16
 VSR Optimizer Performance Whitepaper

11 Appendix – Some Sizing Figures

11.1 Memory Consumption
Mem Overall
Distance
# Delivery Parallelization consumption Peak
# FU # MTr Matrix
Locations (# of cores) Distance Memory
Entries
Matrix [KB] [KB]
1000 1000 5 2 5,035,060 1,155,507 2,770,004
2000 1000 5 2 5,035,060 1,155,507 3,019,856
5000 1000 5 2 5,035,060 1,155,507 2,959,464
10000 1000 5 2 5,035,060 1,155,507 3,375,780
15000 1000 5 2 5,035,060 1,155,507 4,049,592

Mem Overall
Distance
# Delivery Parallelization consumption Peak
# FU # MTr Matrix
Locations (# of cores) Distance Memory
Entries
Matrix [KB] [KB]
15000 1000 5 2 5,035,060 1,155,507 4,049,592
15000 1000 5 4 5,035,060 1,155,507 4,146,084
15000 1000 5 8 5,035,060 1,155,507 5,502,088
15000 1000 5 16 5,035,060 1,155,507 8,194,488

Mem Overall
Distance
# Delivery Parallelization consumption Peak
# FU # MTr Matrix
Locations (# of cores) Distance Memory
Entries
Matrix [KB] [KB]
2000 100 5 2 53,560 12,292 1,762,660
2000 200 5 2 207,060 47,519 1,822,208
2000 500 5 2 1,267,560 290,895 2,250,320
2000 1000 5 2 5,035,060 1,155,507 3,349,464
2000 1500 5 2 11,302,560 2,593,849 5,187,944

Mem Overall
Distance
# Delivery Parallelization consumption Peak
# FU # MTr Matrix
Locations (# of cores) Distance Memory
Entries
Matrix [KB] [KB]
1000 1000 5 2 5,035,060 1,155,507 3,619,812
1000 1000 10 2 10,070,120 2,311,014 5,474,572

17
VSR Optimizer Performance Whitepaper

1000 1000 25 2 25,175,300 5,777,535 10,122,452

Mem Overall
Distance
# Delivery Parallelization consumption Peak
# FU # MTr Matrix
Locations (# of cores) Distance Memory
Entries
Matrix [KB] [KB]
1000 1000 25 2 25,175,300 5,777,535 10,122,452
1000 1000 25 4 25,175,300 5,777,535 10,950,628
1000 1000 25 8 25,175,300 5,777,535 12,530,468
1000 1000 25 16 25,175,300 5,777,535 13,752,936

11.2 Runtime to calculate initial solution

Runtime
# Delivery Parallelization
# FU # MTr First Solution
Locations (# of cores)
[s]
1000 1000 5 2 768
2000 1000 5 2 1468
5000 1000 5 2 3810
10000 1000 5 2 10047
15000 1000 5 2 18056

Runtime
# Delivery Parallelization
# FU # MTr First Solution
Locations (# of cores)
[s]
15000 1000 5 2 18056
15000 1000 5 4 13842
15000 1000 5 8 9173
15000 1000 5 16 10095

Runtime
# Delivery Parallelization
# FU # MTr First Solution
Locations (# of cores)
[s]
2000 100 5 2 862
2000 200 5 2 903
2000 500 5 2 1077
2000 1000 5 2 1437
2000 1500 5 2 2075

18
 VSR Optimizer Performance Whitepaper

Runtime
# Delivery Parallelization
# FU # MTr First Solution
Locations (# of cores)
[s]
1000 1000 5 2 1173
1000 1000 10 2 1959
1000 1000 25 2 2949

Runtime
# Delivery Parallelization
# FU # MTr First Solution
Locations (# of cores)
[s]
1000 1000 25 2 2949
1000 1000 25 4 2752
1000 1000 25 8 2303
1000 1000 25 16 2391

19