Proceedings of the 2009 IEEE Systems and Information
4
Engineering Design Symposium, University of Virginia,
Charlottesville, VA, USA, April 24, 2009
GPS Tracking of Intermodal Transportation: System Integration
with Delivery Order System
Christopher Heywood, Craig Connor, David Browning, Michael C. Smith, Jianping Wang
Abstract— TMO Global Logistics currently provides cargo
tracking services that rely on clients calling the TMO office to
request estimated time of arrivals (ETAs) and TMO employees
calling shipping dispatchers to find current cargo locations and
relaying experience-based ETAs to the client. For TMO,
minimizing the resources (dollars, man-hours, data storage
space, and bandwidth) spent accepting ETA requests,
calculating ETAs, and relaying results can free those resources
for use on other tasks. At the same time, if TMO can provide
its clients with more accurate ETAs retrievable in less time,
relative to competitors, the firm stands to gain significant
market share as a result of these attractive services.
The team considered issues such as accuracy of the data, ease
of implementation, resource usage, and client privacy of the
solution. The recommended solution analyzes a particular
route’s historical shipment data and segments each trip into
legs that might be used, in conjunction with legs from other
shipments also stored for future historical analysis, to
reconstruct hypothetical trips and calculate a more accurate
ETA than simply using initial and terminal points would
permit. To further increase the reliability of the calculation,
legs with similar start- and endpoints (within a critical radius
of the actual leg’s start- and/or endpoints) are also used in the
calculation.
The project team anticipates integrating this ETA approach
into TMO Global Logistics’ cargo tracking system. The
revamped system includes a TMO client interface that maps
the client’s cargo for added customer satisfaction and a TMO
administrator interface to initialize, and if necessary, manually
adjust shipments.
I. INTRODUCTION
T MO Global Logistics, a Charlottesville-based firm,
provides third-party shipping logistics solutions to its
clients. A client might want to move a load of lumber
Manuscript received April 6, 2009. This work was supported in part by
TMO Global Logistics of Charlottesville, VA.
C. Heywood was a student with the Department of Systems and
Information Engineering, University of Virginia, Charlottesville, VA
22904, USA (phone: 301-367-9091; email: cjh3n@virginia.edu).
C. Connor was a student with the Department of Systems and
Information Engineering, University of Virginia, Charlottesville, VA
22904, USA (email: cmc5ma@virginia.edu).
D. Browning was a student with the Department of Systems and
Information Engineering, University of Virginia, Charlottesville, VA
22904, USA (email: dab4w@virginia.edu).
M. C. Smith is an Associate Professor with the Department of Systems
and Information Engineering, University of Virginia, Charlottesville, VA
22904, USA (email: mcs5f@virginia.edu).
J. Wang is a Senior Research Scientist with the Department of Systems
and Information Engineering, University of Virginia, Charlottesville, VA
22904, USA (email: jw9bn@virginia.edu).
1-4244-4532-5/©2009 IEEE
FPM2DMSim.
from Germany to the central United States. TMO would
then hire the marine, trucking, or rail carriers, obtain the
required permits, and supervise the cargo’s customs
processing. During this process, the customer is very
anxious about the condition of his valuable cargo, but he is
more concerned with its arrival time at its destination. The
client wants to know when he will need resources at the
delivery point to unload and utilize the cargo. When a
request for information is received, a TMO employee
contacts the carrier currently in possession of the cargo to
obtain its real-time location. The TMO employee then
makes an educated guess, based on his or her experience,
and provides the client with an Estimated Time of Arrival
(ETA). This process consumes TMO personnel resources
and often results in inaccurate ETAs because TMO must
rely on the carrier to report the location of the shipment.
TMO engaged a Systems Engineering team from the
University of Virginia to develop a solution to the problem.
The company hoped that the team could decrease or
eliminate the daily time spent by TMO agents on cargo
tracking. TMO also wanted greater client satisfaction to
retain and improve market share, and it decided that TMO
clients needed a more accurate, reliable ETA. This paper
focuses on the complex problem of generating an accurate
ETA for TMO’s clients. The solution proposed here is a
significant improvement on the existing ETA calculation
process’s accuracy, and it demands less from TMO
employees.
II. PREVIOUS WORK
There are a number of methods that already exist to
calculate ETA. Mass transit systems, aviation systems, train
systems, and many other modes of transportation for people
and goods benefit from estimates of the arrival time at the
destination. One method for generating an ETA for an
aircraft involves locating the plane relative to three or four
fixed positions. As the aircraft’s speed is known, the time
until it arrives is simply the distance from its current
location to its destination divided by its speed [1]. This
solution could be applied to any system where the current
location, the destination location, and the current speed were
known. The resulting ETA, however, is most accurate for
straight-line, constant-speed modes of transportation like
planes or ships and is not sufficient for variable-speed and
route-based modes like trucks and trains.
Another group predicts ETAs for London buses by
determining which two stations the bus is between with the
help of an on-board GPS system. The system then uses the
known distances between stops to predict an ETA [2]. This
191
method works well for a predicted route with many stops
and a constant low speed of advance. However, it is not
robust enough to account for new routes, and it would not
generate a different (and more accurate) ETA whether the
bus was closer to the next stop or closer to the stop it just
left.
ETAs cannot simply be calculated from point A to point B.
Many trips, including most of TMO’s shipments, travel from
A to B to C, and possibly beyond, with at least one transfer
point (here at B). A transfer point could be a warehouse, a
change in the mode of transportation, a customs inspection,
or any other standardized delay. One study examines the
process of calculating ETAs from these transfer points, as
well as estimating time spent at each transfer point. The
study notes that if an unusual delay occurs at one transfer
point, delays are likely at future transfer points due to a
disruption in the planned schedule [3].
Other researchers suggest queuing models for ETAs. If
traffic is very light or nonexistent, travel times for cars on
roads can be represented with a random variable distribution.
If there is some traffic, it is accurate to calculate ETAs by
saying that the vehicles are waiting in queues whose
attributes can be represented with random variable
distributions [4]. This method requires a lot of data to
generate distributions, unfortunately.
A study undertaken for the Washington State Department
of Transportation uses historical data between points to
create an ETA algorithm for a mass transit system. This
solution also includes a noise function to account for
variability in travel time: if the first part of a leg takes one
and a half times as long as usual, the system predicts that the
second half of the leg will also take one and a half times as
long as usual [5]. This solution is excellent for short legs
and small networks, but the traffic noise function cannot be
applied across long distances. This study [3] also uses
historical data to estimate leg durations, but its lack of a
method to calculate ETAs when in the middle of a leg
recommends it for short journeys as well.
III. SPECIFICATIONS
The system needs to meet a number of requirements in
order to achieve the goals described in the introduction. An
improved ETA calculation would increase the resolution of
the prediction—perhaps the likely hour of arrival, rather than
the day—and would increase the accuracy of the prediction.
A more accurate prediction would have a smaller error, or
the difference between the predicted ETA and the actual
arrival time. These improvements would gratify existing
TMO clients and hopefully attract new ones.
The ETA calculation should be automated and require
very little input or time commitment from a TMO employee.
While a completely autonomous system might not be
plausible at this time, the hour a day TMO agents currently
spend on ETA calculation must be reduced.
The ETA calculation must be flexible and robust. It needs
to operate across all modes of transportation, and it should
be able to self-correct. TMO’s clients will not accept large
inaccuracies, yet routes can change, cargo can transit on any
1-4244-4532-5/©2009 IEEE
mode of transportation, and cargo speeds are rarely constant
or predictable. Finally, an ETA algorithm should be
feasible, and TMO should be able to implement it with
currently available resources, including data storage and
location information from cargo carriers.
IV. IMPLEMENTATION
A. General Solution
The proposed solution divides a shipment into a series of
legs connecting the departure point, intermediary transfer
points, and the destination. A TMO agent enters the
locations of all points as individual addresses or as
coordinate points using latitude and longitude. The system
then tracks the cargo as it transits from point to point as long
as it receives location information from the cargo unit.
Every received location point is stored in a database table
called HistoricalLeg, along with the mode of transportation,
the location of the next transfer point (or, if there are no
more transfer points, the final destination), and two empty
fields for the arrival time and the elapsed time. These empty
fields are filled in when the cargo arrives at the next transfer
point. Each HistoricalLeg row thus represents one trip from
the point at which location data were received to the next
transfer point.
Fig. 1. HistoricalLeg rows generated as the cargo proceeds from A to
B. Sent location information is indicated by triangles. Each dotted
line over the route indicates a startpoint, endpoint, and elapsed time
added to HistoricalLeg.
Over time, the HistoricalLeg table grows until the
commonly traveled path from a given point A to point B is
littered with start points for HistoricalLeg rows (Fig. 1). If a
TMO client requests an ETA on in-transit cargo traveling
currently at point P in between the A and B points, the
algorithm will query the HistoricalLeg table for the n rows
with the same mode of transportation, the same next transfer
point B, and the same current location P. The system will
then use the mean of the elapsed time for each row ti to
calculate the estimated time from the current location to B,
tPB.
n
∑ t
i =1 i
tPB = (1)
n
If necessary, it will also calculate the estimated time on
the remaining j complete legs (from B to C, and so on, until
destination Z) as well as the estimated time at the remaining
j transfer points
€ between P and D.
192
 t BZ = t BC + tCD + ...+ tYZ
ttransfer = tB + tC + ...+ tZ
ETA = tPB + tBZ + ttransfer (4)
This method allows for a robust ETA calculation (4) at
€point in the route, as opposed to a manipulation of an
any
ETA€only available between points A and B. As certain
routes are traveled repeatedly, more data will accumulate
€
and the predicted trip time at any point will become more
accurate. In addition, most trips will have multiple segments
and transfer points. Some segments will yield rich GPS
data, but others (such as train segments) may yield sparse
location data. These legs without much location data will
lead to error in ETA calculations. However, the error will
only affect the time calculation for that segment. The ETA
will be corrected when the segment is completed and the
error will not compound over time.
B. Specific Issues and Solutions
This solution, while fairly simple, presents complications
that require resolutions. First, except at transfer points,
current-location coordinates received will rarely match
points in the HistoricalLeg table. The less rows the system
can base its average on, the more inaccurate the estimate will
be. Thus, the system uses a “sensitivity radius” r around the
current location P of the cargo to find HistoricalLeg rows
that begin near the cargo’s current location.
r = 0.05• AB (5)
These rows’ elapsed times are then averaged to generate
the ETA at the next point. Fig. 2 demonstrates a sensitivity
radius and four HistoricalLeg rows that are captured with
startpoints
€near P and endpoints of B.
Fig. 2. Sensitivity radius capturing HistoricalLeg rows with
startpoints near P. Four legs are deemed within r of P and also end at
B. The ETA will be calculated using the average of the elapsed time
of these previous shipments.
The solution will be implemented over time as historical
data are collected to provide a more accurate ETA. When
the system is first integrated into TMO’s existing customer
service operations, there will be no historical data available
for any route. Two proposed solutions will be left to the
discretion of TMO. The website and historical data
components can operate in “stealth” mode, recording
positions and trip lengths without allowing any TMO clients
to use the site. During this phase, TMO agents would
continue to provide ETAs as they do now. After historical
data are accumulated to allow the system to be operational,
clients would be given accounts to the website. The second
option calls for immediate implementation of the system,
including full customer use. Under this option, ETAs would
1-4244-4532-5/©2009 IEEE
(2) be calculated using Google Maps’ estimated driving time
(3) function. Estimates for legs that have no Google Maps
estimate (e.g. rail or water segments) would be calculated
using the straight-line distance remaining divided by the
estimated speed of the cargo. The estimated speed would be
calculated using the distance covered over the last three data
points divided by the time in which they were covered. A
TMO agent would approve all times under this method to
account for variation in projected times specific to certain
modes of transport (e.g. wide load, hazardous materials).
This method will be built into the system as a backup in
case the cargo is in a location outside the sensitivity radii of
the startpoints of all legs in HistoricalLegs. However, it is
highly inaccurate and will only be used when absolutely
necessary. One of these stopgap solutions to an incomplete
HistoricalData table will be used temporarily, upon
initiation of the system, and will not significantly affect
ETAs once the system is fully operational.
Unusually high traffic volumes can present another issue:
weighting one trip’s elapsed time too generously. For
example, consider a trucking leg from A to B that typically
takes one hour. During that hour, the system receives a
location on the cargo every 5 minutes, thus placing evenly
spaced entries into the HistoricalLeg table. However, if the
truck encounters traffic and stops moving for 15 minutes,
three legs would be recorded in the HistoricalLeg table for
this journey, all of which begin in the same location. The
next time a client’s cargo is near that point, and the client
wants an ETA, the ETA will be calculated using the average
duration of all the legs that start within r of the current
location. This average will include three legs from the high-
traffic trip. Thus, the time intensive trip will be weighted
three times as much as any other historical trip.
193

Fig. 3. High traffic problem and solution. Assuming constant location
data input, in the steady traffic case, only four HistoricalLeg rows are
generated.. However, in the heavy traffic case, six are generated, and
three are very close to each other (those rows created when the cargo
encountered the traffic). The corrected heavy traffic case throws out
all but one of the rows whose origins are too close, thereby weighting
the high traffic leg fairly in the HistoricalLeg table and in the next
ETA calculation.
This concern is corrected by once again utilizing
sensitivity radii. A row will only be entered in HistoricalLeg
if the current location is at least 2r away from the startpoint
of the last leg entered in the table due to the same shipment.
This solution avoids including the same trip multiple times
in an average when creating a future ETA. No sensitivity
radius will contain more than one leg from any previous
individual shipment, thus avoiding inaccurate weighting of
traffic-heavy shipments. This is summarized in Fig. 3.
Transfer points provide another concern for an ETA
calculation. If cargo is traveling from A to B to C, and B is
projected to be a one hour transfer point, the ETA will be the
sum of the projected time from B to C, the one hour transfer
time at B, and the estimated time from the current location P
to B. As soon as the cargo arrives within one sensitivity
radius of B, it is assumed to be at B, and thus tPB is
considered zero. A clock tB begins to count down from one
hour, representing the projected time left at B. However, the
transfer estimate is never perfectly accurate, and so when the
vehicle leaves the vicinity of transfer point B, tB is set to
zero, and the final ETA equals tPC. If a truck driver,
however, enters and leaves the sensitivity circle around B
before he actually arrives at the transfer point (a feasible
situation), the system might consider the transfer point
finished and underestimate the time remaining before
arrival.
1-4244-4532-5/©2009 IEEE
Fig. 4. Transfer point arrival and departure sensitivity circles. Note
how as the cargo breaches the inner circle, the system considers it to
have arrived at B. However, even though it leaves the arrival circle
before it actually reaches B, it does not leave the departure circle.
Thus the system correctly infers that the cargo has left B when the
cargo leaves the outer circle.
Thus the system incorporates two circles: an arrival circle
of radius r, and a departure circle of radius 2r, as shown in
Fig. 4. The cargo is considered to have arrived at the
transfer point, and thus started the clock, when the inner
sensitivity circle is breached. The cargo then is considered
to have departed the transfer point when it leaves the outer
circle, thereby setting tB to zero and beginning the leg to C.
C. Testing
Fig. 5. Test path. Cargo at P has not yet traversed the dotted segment.
In order to show the importance of depth of data on the
usefulness of the historical analysis estimated time of arrival,
the team needed to compare the accuracy of the estimations
with the frequency of leg start- and endpoints in the area. In
the absence of reliable real trip data, the team simulated data
for a hypothetical highway. The highway is 1000 miles long
and has a speed limit of 65 mph. The estimated time of
arrival is requested when the driver is at the 500 mile marker
(shown with a P in fig. 5). The time taken to traverse any
stretch of the hypothetical highway was calculated by
assuming the driver would drive at the speed limit, and then
adding on a delay represented by a time pulled randomly
from a normal distribution with a mean of two hours and
standard deviation of 50 minutes. The team realized that
194
these traffic conditions do not exist exactly in the real world,
but also thought that simulation was better than inaccurate
data. The system looked for historical legs with start- and
endpoints within 25 mile radii (5%) of the current location
and destination (shown with a B in fig. 5), and used those to
calculate an estimated time of arrival. The team then
compared this estimation with the actual travel time, which
was drawn from the same normal distribution as the legs
were, and was replaced for each comparison. The team ran
the experiment with 20 leg startpoints dropped randomly
between the start of the 1000-mile stretch of highway
(shown with an A in fig. 5) and the end of the stretch of
highway (marked by the T), and then repeated the
experiment with 50 points (0.05 drops per mile), 100 points
(0.1 drops per mile), 300 points (0.3 drops per mile), and
600 points (0.6 drops per mile).
The results showed that the historical analysis ETAs get
more robust as the amount of data increases. This happens
for two reasons. First, the probability of being in an area
with no historical leg startpoints within the sensitivity radius
decreases as the number of GPS inputs received along that
stretch of road increases. This relationship is shown in fig.
6. Secondly, the accuracy of the estimations also increases,
although very slightly, as shown in fig. 7.
Fig. 6. More drops/mile leads to historical data on a greater
percentage of the road in simulation.
Fig. 7. Accuracy of ETA in simulation.
The proposed system thus meets the requirements of
increased resolution and accuracy. It also requires less time
commitment from TMO employees, as it only requires each
1-4244-4532-5/©2009 IEEE
order to be initialized by a technician. The system
automates the rest of the process by storing historical data
and automatically calculating ETA. It also accepts data of
any frequency and from any source, as long as it arrives in
address or latitude/longitude format, allowing it to be
multimodal and flexible.
The system also allows for future analysis of its accuracy
and of possible trends among errors. Every calculated ETA
is stored in a table called EtaAnalysis, where the predicted
arrival date and time are recorded next to the actual arrival
date and time. This allows for future enhancements of the
algorithm, including an examination of trends over time and
periodic or cyclical variations in the error due to time of
day, week, or year.
V. CONCLUSIONS
TMO hopes to increase market share and maximize the
utility of its resources. An automated, more accurate ETA
can contribute to the solution of both these problems. When
the historical analysis ETA is combined with a map-based
user interface (fig. 8), TMO clients will have a powerful
new tool to monitor their shipments. The system
architecture (fig. 9) remains hidden, but accurate and
automatic ETAs are outputted. Costs and stresses due to
uncertain cargo arrival times will be significantly reduced.
Fig. 8. TMO client interface conception.
195
 Fig. 9. Architecture of information flow in the system. Location
information flows from the cargo as it passes through various points
and legs to the data receiver, at which point it enters the designed
system. The location information is then sent to storage, where it is
accessed by the TMO admin interface and the ETA algorithm. The
algorithm stores the estimates in the database and later compares them
to the true values for accuracy. The TMO agent initializes shipments
in the database.. The end result is an accurate ETA estimate sent to
the client interface.

ACKNOWLEDGMENT
The team thanks the employees of TMO Global Logistics
for their support. Joseph “J.C.” Toe and James Holland
were especially helpful as the team struggled with problem
comprehension and needed data to analyze.

REFERENCES
[1] B. S. Levy and S. Bedada, “A real-time ETA-to-threshold prediction
tool,” 2006 IEEE/AIAA Digital Avionics Systems Conference, pp. 1-
12.
[2] O. Rashid, P. Coulton, R. Edwards, A. Fisher, and R. Thompson,
“Mobile information systems providing estimated time of arrival for
public transport users,” Spring 2005 IEEE Vehicular Technology
Conference, vol. 5, pp. 2765-2769.
[3] B. Kara and B. Tansel, “The latest arrival hub location problem,” in
Management Science, vol. 47, no. 10, October 2001, pp. 1408-1420.
[4] A. Miller, “A queueing model for road traffic flow,” in Journal of the
Royal Statistical Society, Series B (Methodological), vol. 23, no. 1,
1961, pp. 64-90.
[5] Z. Wall and D. J. Dailey, “An algorithm for predicting the arrival time
of mass transit vehicles using automatic vehicle location data,”
Transportation Research Board, Washington, D. C., Jan. 10-14, 1999.

1-4244-4532-5/©2009 IEEE 196