Problem 5: Fleet Flow Model for Optimal
Fleet Sizing of a Dedicated Trucking Operation
Formulation and solution development


Reginald Joules 
Document content writer 

Reginald Joules 
Target audience 

Quantitative modeling professionals
Technical managers
Anyone who likes solving problems 
Original model and document posting 

February 2003 
Revisions 

October 2010
January 2020 
A dedicated truck services company wants a
descriptive (whatif) model for sizing a dedicated fleet for a customer based on
recurring weekly delivery requirements. The focus during initial phase
of the analysis is investment and operational cost consequences of any given fleet size.
The whatif model is to be used as a response object to NMOD's Optimization
Module to find fleet size with the lowest total costs. Note: Data used in this
illustrative example are artificial.
The core idea: I got the core idea for this model (unavailability of
trucks based on route zones) from a transportation analyst at MS Carriers in
Memphis, TN (Spring 2001). He was trying to use an Excel spreadsheet to
"simulate" the movement and availability of trucks manually but that would
have taken hours to do just one scenario, not to mention finding an optimal
answer.
With ORMSware I could easily handle the dynamics of this problem and measure
various performance factors, and then use Fibonacci search to find optimal
(minimum cost) fleet size in a few seconds. As you will see it is very fast
and easy to set up this problem with ORMSware, while setting up this entire
solution in Excel would be quite impractical.
To watch the video below
right here without going to Vimeo, press the Play button at bottom left of
the displayed player.



Notes

When
a proposed fleet size is insufficient to meet customer’s shipping demands
for a given weekday, loads that cannot be handled with trucks in the fleet are
outsourced. When too many truckloads have to be outsourced, chances are the
company can increase financial performance by increasing fleet size.

When
available trucks in the fleet exceed demand on any given day, some trucks in the fleet are left
idle. When too many trucks are idle, chances are the company can increase
financial performance by decreasing fleet size.

Proper formulation of this problem is a normative model which prescribes optimal fleet size for
a dedicated operation. But, the purpose of
this example is to show how to build a descriptive model of a situation to
facilitate whatif analysis and then use the descriptive model for Fibonacci
(response surface) search to prescribe optimal fleet size.

We
will also use this example to explain how a more comprehensive model can be
built with due consideration of other operational matters in
choosing appropriate fleet size. Such
complex issues may not lend themselves to easy normative formulation,
requiring descriptive models such as this one to find optimal solutions
using response surface search.

The
label fleet trucks is used here to distinguish trucks in the fleet
from contractor trucks carrying outsourced loads.
The problem is modeled here as a closed system
with fixed resources and deterministic, totally predictable, recurring weekly demands for the
resources, since the fleet will be dedicated to a customer. The resources are fleet trucks and demands are truckloads to be
shipped to various destinations. The loads transition fleet trucks from available or
idle status to busy status for a certain period of time before returning them to available status.
When a fleet truck is assigned to deliver a load,
it becomes unavailable to
satisfy other demands for a certain period of time. The length of time that truck will be unavailable
depends on how long it has to travel to deliver a load and return to base.
In this example, we have classified demands by
route durations/route zones. Zones were
determined in terms of route durations of one, two, and three days. It will be
obvious to the reader that this model can be scaled to refine and extend zone classifications to a minimum of any
fraction of a day to a maximum of any multiple of the minimum duration.
From recurring weekly shipping demands
projected by the customer, demands for each day of the week were grouped in terms of the number of days they cause a truck to be unavailable
(i.e. in terms of route duration/route zones), as
shown in the image of the Excel table above.
On any given day when available fleet trucks
are insufficient to handle all of that day's demands, excess demands are
outsourced; if there is insufficient demand to assign all available fleet
trucks, the unassigned trucks go into idle state till the next time period,
which is the next day in this formulation.

On
the margin, outsourcing
is more expensive than satisfying demands with trucks in the dedicated fleet.
(Otherwise, it might make more sense to outsource the whole operation.)

Because
outsourcing is more expensive than using fleet trucks, oneday route deficits
should be outsourced first, then twoday routes and threeday routes, in that order.
This may be a myopic policy, since it is quite possible that in some cases
such an outsourcing policy could cause costlier truck assignments in subsequent
days. But, the purpose of this example is merely to demonstrate how problems
are modeled using ORMSware's NMOD, not to research the best assignment
policy.
Formulation of this problem is more easily
understood through its ORMSware network diagram towards the top and its supplemental data
files. Click the links below to open these files in separate windows for
reference while reading the rest of this document.
Results: Preview of results of this
model.
Following section describes the
model:

Total demand on any given day is the sum of
truckloads to be shipped that day to all route zones.

Total supply of fleet trucks
in any given
time period (day)
is the sum of all fleet trucks that have returned in time to meet that time
period's (day's)
demand plus idle trucks, if any, left over from previous time period (day).

Idle trucks on any given day are those fleet
trucks that could not be assigned loads on that day due to insufficient total
demand on that day.

Outsourced truckloads on any given day are
loads that cannot not be assigned to fleet trucks, because not enough fleet
trucks are available to meet that day's total demand.

Since demand pattern is exactly the same
every week and truckloads that cannot be hauled by fleet trucks are always
outsourced, truck assignment and truck flow are always balanced, and exactly the same,
every week.
The model starts execution at the green Start node, viz.
n[3]Initializations.
The node happens to be [Visioassigned] object number 3 in this case, indicated as [3]
in the line above the node name. Analysts typically model the middle parts
of a model first before dealing with the Start node, so Start nodes often have
object numbers other than 1.
The Start node in the top level network of a model is
typically used to set up and
initialize various variables, perform
various nonrepetitive tasks, and to launch repeated executions of various cycles (loops) in the model.
There are three cycles in this
model as explained below:

Day
tracking cycle (n[4]a[5]n[4]):
This cycle increments the day number each time and roundrobins through the
days of the week, so that demand for each day can be fetched in
n[7]AssignTrucks according to
day of the week.

Routes
cycle (n[7]a[9]n[7]):
This cycle keeps trucks unavailable for the length of time consistent
with the route duration of the truckloads to which they are assigned.

Idle
cycle (n[7]a[10]n[7]):
This cycle keeps trucks for which loads could not be found on a given
day in idle status till the next day when they are made available with other
trucks returning in time to handle that day's loads.
Contents of key nodes and
arcs

n[7]AssignTrucks: This node fetches demands for each route
zone from the
Excel table shown
earlier in this document, calculates available fleet trucks
and determines what loads, if any, should be outsourced. It then creates a
temporal connection to a[9] and sends to it different signal entities
(calculation threads) carrying fleet truck dispatches to all route zones (an
alternate way is available in ORMSware 2020). Notice
in the image of the dialog box below for a[9] that its Branch property is set to
No/False. The
loads assignment algorithm in n[7] determines how many fleet trucks are
dispatched to each route zone. Each signal has properties that carry its assigned route zone and
associated number of trucks assigned to the zone.

a[9]AssignTrucks>>AssignTrucks: Signals turn into regular entities when they reach a[9]. NMOD
figures out the length of time each entity should take to traverse [9] to get
back to n[7] based on the expression you can see in the Duration property box of
[9] at left. The value comes from the 8th row of the TruckLdDemand table (shown
at top
of this page). The column value defining the cell in the 8th row is RouteZone.
n[7] also dispatches idle trucks count along
a[10] back to itself for the next day's assignment cycle.
Threads reaching n[7] are held in a queue until all threads converging on the
node have arrived. When all threads have arrived, they are merged, and since
there is merging logic provided by the modeler, that code executed before the
rest of the node is executed.
[11]OutsourcingCalcs: This node will be triggered only
during the statistics and cost calculation period defined by the analyst. We
have defined it to be days 8 through 14. This node tracks how many runs to each zone
are outsourced and consequential cost of outsourcing per week.
[15]FleetCalcs: This node will be triggered only during
the statistics and cost calculation period defined by the analyst. We have
defined it to be days 8 through 14. This node tracks how many runs to each zone
are made each week by fleet trucks.
[12]FinalCalcs: This node wraps up results reporting on the final day
of the analysis horizon, writing to the Results file certain interesting summary
information captured during a model run and all of the calculated costs
information.

Fibonacci search procedure in NMOD's Optimization Module was used to find optimal fleet size. Fibonacci search is a procedure for finding
optimal value of an integer decision variable (in this case, the number of trucks
in the fleet) which produces a unimodal response curve over a decision range. In
other words, it was obvious in this case that the total cost
curve would go down for a while as the fleet size increases from zero and then at some point
would start to go up for larger fleet sizes. Thus, the fleet
size that yields the lowest total cost value would be the ideal fleet
size.
Using Fibonacci search in a model involves
inserting two lines of code in the model, one for providing a stimulus for probing
the model and the other for sending the model's response to the optimizer. These
lines can remain in the model even if the analyst wants to do just one whatif
probe at a time.
The stimulus line should go where the model sets the decision variable's
value. In the case of this model, it is in n[3]Initializations (CALL OptimizationStimulus). This call updates the value of FleetSize
with the stimulus value provided by the optimizer. If the model is being run in
the whatif probe mode instead, this call will leave FleetSize unaffected.
The response line goes where total costs are computed at the bottom of the Trans property of n[12]FinalCalcs
(CALL OptimizationResponse).
 Results from optimization run.
You will see how the Fibonacci search figures out that 66 is the optimal fleet
size in the search range suggested (50 to 70 trucks), with zero error tolerance,
in 6 probes of the model. Since the search called the model 6 times, you will see in the results file
6 executions of the model for different fleet sizes.
If the search range suggested were 0100 trucks, Fibonacci search would have
found the answers with 10 probes. As the suggested search range increases,
the economics of this nonnaive search procedure becomes exponentially
superior to naive searches, such as trivial looping through the search range
(shown next).
Since this is a systematic, nonnaive search, you will notice from the
execution feedback to the screen that the optimizer knows before the search
begins how many probes of the model will be necessary to find the optimal
answer within the range and the tolerance specified by the analyst.
You can see feedback to the screen from the execution by clicking here.
 Results from NMOD's Trivial
Search procedure. This file contains 21 probes of the model (fleet sizes
of 50 to 70),
which the stakeholders will be curious to see after they see results from the
Fibonacci search. You can see total costs going down until fleet size
reaches 66
and starting to increase thereafter. This procedure tracks minimum and
maximum values in a range and displays both stimulusresponse pairs at the
end of the search.
You can see feedback to the screen from this execution by clicking here.
 Results from a single whatif
probe. This was was run by simply changing the Optimization mode in the
Excel spreadsheet to 0 and executing the model. We used fleet size of 64 for
this exercise.
You can see feedback to the screen from this execution by clicking here.
There are, of course, less naive approaches than the trivial search
described above.
One approach would be to stop the
search immediately, as it proceeds from one end of the solution range to
another, when total costs start going up. This too can be cumbersome and
inconsistent for large scale models in large ranges. For example, if the range
we guessed is 65 to 200, we would have gotten lucky and found the answer in 3
probes. But, if we guessed 0 to 135 instead (same width of range), it would have
taken 68 probes to find the optimum.
