Context-Aware Customizable Routing Solution for Fleet

Management

Jānis Grabis

, Žanis Bondars

, Jānis Kampars

, Ēriks Dobelis

and Andrejs Zaharčukovs

Institute of Information Technology, Riga Technical University, Kalku 1, Riga, Latvia

LLC PricewaterhouseCoopers, Kr. Valdemara 21-21, Riga, Latvia

Keywords: Decision Support Systems, Vehicle Routing, Customization, Context-awareness.

Abstract: Vehicle routing solutions delivered to companies as packaged applications combine vehicle routing

decision-making models and supporting services for data integration, presentation and other functionality.

The packaged applications often are tailored to specific needs of their users thought customization methods

and mainly focus on the supporting services rather than on modification of the routing models. This paper

proposes a method for customization of the routing model as a part of the routing application. The

customization method enables companies to incorporate their specific decision-making goals and context

into the routing model without redesigning the model itself. The routing model is also capable of adapting

its behaviour according to observed interdependencies among decision-making goals and routing context.

An illustrative example is provided to demonstrate customization of the routing solution and to highlight

multi-objective and context-dependent characteristics of the vehicle routing problem.

1 INTRODUCTION

Recent developments in information technology

such as services, sensor technologies, advanced data

analytics and cloud computing have allowed to

reconsider solutions of well-known operations

management problems. New data sources can be

incorporated in problem solving and larger

computational resources can be used for searching

solutions. That allows developing models of higher

sophistication providing more realistic solutions. A

vehicle routing (VR) problem is one of such

problems benefiting from the new technological

capabilities (Keming, 2015; Wan et al., 2016).

To make operations managements models

available to users, they are delivered as a part of

various enterprise applications such as decision-

support systems and ERP systems (Madapusi and

D'Souza, 2012; Carton et al., 2016). These enterprise

applications are provided by their vendors and often

require customization to fit needs of particular users.

In the case of the VR problem, the users are

companies providing logistics services. While

customization of enterprise applications is frequently

considered (e.g. Parthasarathy and Sharma, 2016),

traditional methods provide limited guidance for

customization of decision-making components of

these applications and modification of operations

management models used, in particular.

The VR problem also depends on a number of

company specific requirements and circumstances.

The traditional models allocate client requests to

vehicles to minimize traveling costs, and there are

generic formulations of the problem solving model

available (Eksioglu et al., 2009). However, there are

many possible variations. Companies providing

logistics services have different objectives,

deliveries are affected by local circumstances and

there are specific delivery constraints. Developing a

customized solution for every user is resource

intensive for software vendors. One of the possible

solutions is development of operations management

models on the basis of a common reference model

(RM), which consists of generic and customizable

parts. The generic part incorporates the most

common aspects of the VR model shared by many

users, and the customizable part incorporates user

specific aspects of the VR problem.

The objective of the paper is to elaborate a

method for customization of the VR service on the

basis of the RM. The method focuses on

customization of the VR model underlying the

service. It allows to incorporate company specific

638

Grabis, J., Bondars, Ž., Kampars, J., Dobelis, ÄŠ. and Zahar

cukovs, A.

Context-Aware Customizable Routing Solution for Fleet Management.

DOI: 10.5220/0006366006380645

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 1, pages 638-645

ISBN: 978-989-758-247-9

objectives in the model without structural

modification of the routing model. It also allows to

represent specific operational circumstances faced

by the company. These circumstances are referred as

to context (Abowd, 1999). At this stage of the

research, customization does not address specific

internal constraints because these might require

more comprehensive changes in the model structure

and model solving procedure. Customization is

performed on the basis of the RM, which defines

typical VR objectives and context factors as

described in literature.

The paper describes modules of the customizable

VR service and the customization process. The main

contributions of the paper are a proposal for

separating generic and customizable parts of the VR

model and methods for RM based modification of

this customizable part. The paper is also an initial

step towards a method for developing customizable

operations management applications not only in VR.

It relates to research by Giaglis et al. (2004) and

Cordoso et al. (2016) in its emphasis on addressing

of the routing problem as a part of the overall

information system.

The rest of the paper is organized as follows.

Section 2 provides an overview of the routing

solution. The customization process is described in

Section 3. This section also elaborates key features

of the process including the RM, routing model and

adaption. The vehicles routing results obtained using

the proposed solution are provided in Section 4.

Section 5 concludes.

2 SOLUTION OVERVIEW

The solution is developed for the vehicles routing

problem. A company operates fleet of vehicles and

provides transportation services for its clients. Given

a set of client requests, the routing problem finds a

set of routes starting and ending at a depot that

serves all clients. Typically, there are specific time

windows when the service should be provided.

Requirements are established according to

literature review, evaluation of similar solutions and

interviews with companies.

2.1 Requirements

The VR solution should satisfy all traditional

requirements such as defined in Solomon (1987) and

Laporte (1992). There are several specific

requirements identified in literature and practice that

are not fully satisfied by existing VR solutions.

R1. Multi-objective decision-making – typical

objectives of VR are minimization of costs, time

and travelling distance (Jozefowiez et al., 2008).

Environmental issues, safety concerns and other

factors are often mentioned as relevant.

R2. Customer service requirements should be met -

time windows is a typical way to define

customer service requirements.

R3. Customer priorities should be considered - if

customer requirements cannot be fully satisfied

due to capacity constraints priority should be

given to the most important customers.

R4. Robust and risk aversion is preferable - some of

potential routes exhibit large variations in

travelling time and companies often prefer

routes, which are longer on average but their

traversal time is more predictable.

R5. System level special events should be accounted

for - travel time strongly depends on special

events such as street closures and public

holidays. The system should provide predictive

capabilities to estimate impact of such events.

R6. Route specific exceptional events should be

considered - during the route execution,

exceptional events (e.g., traffic accidents) occur

and the impact of these events on the route

planning should be evaluated.

R7. Location specific requirements should be taken

into account - routing is affected by different

factors depending on location (Cattaruzza et al.,

2014). Additionally, data sources characterizing

routing situations also vary across locations.

R8. Routes should be updated during their execution

in response to customer requests, exceptional

events and other circumstances (Haghani and

Jung, 2005; Ghannadpour et al., 2013).

R9. The solution ramp-up time should to short and

modifications could be introduced in an

expedite manner (Prindezis et al., 2003).

2.2 Key Modules

A complete VR solution consists of routing service,

context platform and transportation management

application (Figure 1). The routing service is the

focal part of this investigation and it is responsible

for generating routes for every vehicle in the

company’s fleet to serve client requests in the given

situation. The transportation management

application provides a wide range of functions to

logistics and transportation companies (Speranza,

2016). It provides input data to the routing service

and consumes routing results. From the routing

perspective, its main function is route execution (i.e.,

Context-Aware Customizable Routing Solution for Fleet Management

639

assignment of client requests to drivers, tracking of

deliveries, performance evaluation). The context

platform is responsible for gathering and pre-

processing of context data from different external

sources. The context data characterize particular

route planning and execution circumstances.

Functionality of the VR service and

transportation management application overlaps

depending on needs of the particular company. If a

company does not possess route execution

functionality then that is provided as modules of the

VR service.

The core part of the routing service is the route

calculation module. It implements route an

optimization model and finds a solution of the VR

problem. The service is packaged as a web service,

which acts as a wrapper for invoking a specific

model solver. This way different model solving

procedures can be used if necessary. The service

also includes additional functions such as model’s

adaptation functions according to the performance

evaluation feedback (see Section 3.4).

The routing model is a mathematical

programming model specified. The model consists

of its generic part and customizable part (see Section

3.3). The generic part is the traditional VR model

while the customizable part represents company’s

specific requirements. The customizable part is

configured according to the VR business model,

which defines unique requirements of the company.

The business model consists of goal and context

models. The goal model specifies company’s VR

and fleet management objectives. It enables meeting

requirement R1 concerning capturing multi-

objective nature of the VR problem. The context

model describes various factors affecting route

planning and execution. It enables meeting

requirements R5 and R6. The business model is

derived from the routing RM. The RM captures the

common VR knowledge and allows sharing the

model development effort among multiple service

consumers. The customer specific model is

developed by extracting relevant features from the

RM or adding unique goals and context factors.

The data integration model is responsible for

supplying the route calculation module with all

necessary input data. It gathers data from sources,

transforms these data and passes them to the route

calculation module. The main input data are: 1)

client demand data provided by the transportation

management application; 2) context data provided

by the context calculation module; 3) performance

evaluation data provided by the transportation

management application. These input data are pre-

processed, aggregated and transformed by the

module.

The context calculation module specifically deals

with processing of context data because context data

providers change dynamically and provide data of

different quality and granularity. The context

platform receives data directly from various sensors.

These data are fed to the context calculation module,

which transform, for instance, raw traffic intensity

data into traffic intensity categories such as light,

medium or heavy traffic. This transformation allows

to decouple volatile data providers from business

interpretation of context data. The context

calculation module is configured according to data

from the context model.

Currently, the prototype of the VR solution uses

OPL to define the routing model and CPLEX to

solve the routing model. The goal and context

Figure 1: Key modules of the vehicle routing solutions.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

640

models are formally specified in the XMI format.

Data from the XMI file are extracted to add

necessary elements to the routing model.

3 CUSTOMIZATION

The key requirement is an ability to customize the

solution for a particular company and the

customization should be done in a cost-efficient

manner. The proposed approach addresses the

customization issue during the solution design as

well as during the solution execution.

3.1 Process

The customization process defines activities

performed to develop a company specific VR

solution. This solution is created on the basis of the

common reference goal and context model and

generic route optimization model. The final result is

a complete routing solution. The customization

process focuses on tailoring the routing model while

development/integration of the transportation

management application is performed using an

engineering process traditionally used by the service

provide and service consumer.

The first activity of the process is development

of the business model consisting of the goal and

context model (Figure 2). The consumer specific

model is derived from the RM. The RM is

maintained by the service provider and contains all

relevant VR goals and context factors affecting the

route planning and execution. It is a result of

knowledge accumulated from providing routing

services to multiple customers. The business model

is used to create a company specific route

optimization model, which is again derived from the

generic routing model. The generic routing model is

augmented by including goals and context factors

important for a particular company as specified in

the business model.

The data integration model is configured by

establishing data bindings. That includes

specification of context data sources, which could be

specific for every company, and integration with the

transportation management system. The route

optimization model includes multiple parameters

steering the route planning and execution activity.

Initial values of these parameters are set for initial

runs of the routing model. The customized model is

tested and deployed as a part of the routing solution

for productive usage.

The route planning and execution activity

includes tasks on generating routes, tracking route

execution, measuring performance and providing

feedback. This activity is executed continuously

whereas routing performance is monitored. If

performance objectives are not met then the routing

solution should be updated. The model parameters

are changed in an adaptive manner (see Section 3.4),

and these changes can be made without redeploying

the solution in run-time. If adaptation is insufficient

to improve routing performance, changes in the

route optimization model or business model might

be required. A typical change in the route

optimization model is introduction of additional

constraints. A typical change in the business model

is updating of the relevant routing objectives or

context factors. These changes require re-testing and

re-deployment of the routing solution.

The main benefits provided by the proposed

customization process are availability of routing

knowledge, reduction of customization effort and the

feedback loop.

3.2 Reference Model

The RM is maintained by routing service provider

and it contains the most common routing goals used

by different logistics companies and frequently

observed context factors affecting routing activities.

The RM is developed according to scientific

literature and professional experiences while

detailed discussion of the RM is beyond scope of

this paper and it is not attended that this RM is

accepted across the industry (i.e., its scope may be

Figure 2: Customization process.

Context-Aware Customizable Routing Solution for Fleet Management

641

restricted to a single routing service provider). The

RM is developed using the goal and context

modelling methods used in the CDD methodology

(Bērziša et al., 2015).

Figure 3 shows a fragment of the goal model

(elements in the model will be used in Section 4).

This model names relevant routing goals and there

could be relationships among the goals. From the

routing model customization perspective, it is

important that the goal model also contains KPI for

measuring the goals. These KPI can be incorporated

in the optimization model to account for specific

decision-making needs for a particular routing

service client.

Figure 3: A fragment of the goal model.

A fragment of the context model is given in

Figure 4. The model names context elements

affecting routing. In the CDD methodology, a

context element represents already processed raw

context information, which is provided by

measurable properties. The measurable properties

are actual observations gathered from sensors while

the context element already represent domain

specific interpretation of the context measurements

(e.g., measureable property counts cars while

context interpretation defines what does account for

a traffic jam). Measurements are transformed into

context elements using context calculations. This

kind of context processing allows using customer

specific data sources by changing data bindings for

measurable properties without affecting definition of

the context elements.

Figure 4: A fragment of the context model.

3.3 Routing Model

The routing model is a mathematical programming

model (Table 1). The generic model is a typical

formulation of the VR model (e.g. Solomon 1987). It

optimizes routing cost and its main decision-making

variable is a binary variable indicating whether a

vehicle travels from one client to another. This

decision variable is denoted by X. The main

constraints are that each client is visited exactly

once, vehicles have finite capacity, customer service

time windows, routes start and finish at a depot, if

vehicle arrives at a client it also must leave and

departure, transit and arrival time dependences.

The vector c represents expense of taking a

particular path between two clients. This expense

can be expressed in different ways, e.g., actual travel

costs, travel distance or travel time. In the generic

formulation this expense equals to d, which

represents travel distance. Vectors a and b are

parameters used to specify constraints.

The generic model is augmented by a

customizable part. That includes customization of

the objective function by adding a term v’P, where P

is a vector of penalties for not meeting company’s

specific goals and v is a vector of weights indicating

a relative importance of each goal. A corresponding

set of constraints (Eq. 4) is also added to the model.

These constraints represent relationships among

target values of KPI and values estimated by the

model. kpi

are target values set by decision-makers

and KPI

is a KPI value estimated using the routing

model. This estimated value depends on the decision

variable X. The constraint implies that if the target

KPI value is not achieved then a positive penalty is

added to the objective function. The penalty term in

the objective function and the KPI constraint are

added according to the goals and their measurements

specified in the goal model.

Table 1: Generic and customizable parts of the routing

model.

Additionally, constraint Eq. 3 is also modified.

The cost of the route is now calculated as a sum of

the distance and the weighted impact of context

factors (the weight vector w). This modification

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

642

implies that the cost parameters characterize

different aspects of the route. For instance, there is a

short route where accidents frequently occur; the

aggregated cost parameter captures these

characteristics. The aggregated cost parameter is

defined as c

ijk

implying that there are k different

routes leading from i to j. These different routes are

obtained by finding the best path from i to j using

different sets of w. For instance, one set of w

favours the shortest path while another set of w

favours the safest path.

Changing the goal and context models in the

business model automatically changes the routing

model thus enabling customization of the solution

according to specific requirements. That is

performed in a similar manner as described in

(Chandra and Grabis, 2009).

The routing model depends on a number of

weighting parameters. The initial values of these

parameters are specified in a judgmental manner.

Subsequently, they are continuously updated to

improve routing performance. The adaption is

performed periodically once information about route

execution is accumulated in the transportation

planning application. Adaptation is also one of the

mechanisms used to customize the solution.

4 ROUTING EXAMPLE

The customization approach is explored using an

example. The objectives of the experimental studies

are: 1) to demonstrate impact of company specific

goals on the routing results; 2) to illustrate context-

dependency of the routing results; and 3) to outline

adaptive behaviour of the routing model.

The routing solution is set-up for a logistics

services provider. The provider receives client

requests on the daily bases and must visit these

clients during specified time windows. This provider

has identified that its primary KPI are KPI1)

customer service measured as a percentage of the

clients served during the specified time windows;

KPI2) travel cost calculated as time spent on

deliveries times hourly rate; KPI3) vehicle operating

cost incurred for every vehicle used on a given day

regardless of distance travelled; and KPI4) safety

aimed at avoiding traversal of accident prone routes

measured by an index characterizing frequency of

the accidents. The provider also indicates that two

major context elements affecting its operations are:

CTX1) route variability measured as variation of

driving time from day to day; and CTX2) route

safety measured as a number of accidents observed

for the given route. These goals and context factors

are shown in the business model (see Figure 3 and

Figure 4, respectively). There are hypothesis that the

CTX1 affects KPI1 and CTX2 affects KPI4.

The route optimization model is customized

according to the business model. As the result, a

constraint

KPI1

Pkpi is added to the model

to represent KPI1. The corresponding constraints are

added for other KPI as well. Similarly, the expense

calculation is update and now the cost is expressed

as a weighted sum of distance and two context

factors, namely, CTX1 and CTX2

12 3

ijk k ij k ij k ij

c w d w CTX w CTX



 ,

where subscripts ij denote distance or context values

or the path between i and j and subscript k denotes

type of the path.

Routing is performed for 20 client requests

received for a single day. The travel distance and

time data are retrieved from OpenStreetMap

(https://www.openstreetmap.org). The accident data

are gathered from a web mapping service. For every

pair of customers, three different paths are obtained

by varying the context dependency weights (Table

2). The path type is referred as Short because the

best route between two customers is found giving

the most importance to the distance minimization.

The path type is referred as Safe because the largest

weight is given to the context factors including the

safety context element CTX2.

Table 2: The weights used to find the best path between

two customers.

Path type w

Short 0.8 0.1 0.1

Safe 0.1 0.1 0.8

Balanced 0.34 0.33 0.33

The optimization is performed by allowing to select

any of the paths (EXP1), only the shortest path

(EXP2), only the safe path (EXP3) and only the

balanced path (EXP4). The values of KPI obtained

for these four experiments are reported in Table 3.

These values are reported relative to EXP1 or the

optimal case but Z, which is the actual objective

value observed and is a weighted sum of all criteria.

It can be observed that EXP2 yields the best result in

term of actual costs but neglects the impact of

context factors (high value of the cost) and delivers

weak customer service performance. Similarly,

EXP3 selects safe paths and scores the best

according to the safety KPI4. Selecting balanced

path (EPX4) expectedly yields results close to the

Context-Aware Customizable Routing Solution for Fleet Management

643

optimal. None of the experiments yields satisfactory

customer service performance (KPI1). The actual

values recorded were 65 to 75% while the KPI target

was 100%.

Table 3: Values of KPI

Expe-

riment

Z Cost KPI1 KPI2 KPI3 KPI4

EXP1 0.28 1.00 1.00 1.00 1.00 1.00

EXP2 0.40 1.76 1.00 0.75 0.50 0.95

EXP3 0.72 3.41 1.00 1.85 1.50 0.38

EXP4 0.30 1.10 1.07 1.08 1.00 0.97

Figure 5 illustrates differences between routing

results in EXP1 and EXP2. It can be observed that

different paths are selected on several occasions.

EXP2 favours path length over other characteristics.

As a result, the whole route can be performed by a

single driver. In the EXP1 other paths are taken to

choose routes with better safety and variability

characteristics. That indicates context-dependency in

path selection.

As mentioned before KPI1 did not yield

satisfactory performance (other KPI target values

were satisfied). Therefore, weights v are changed

adaptively, to find a better balance among the goals.

Initially the weight for c’X in Eq. 1 was set to v

=0.4

and v

=0.2

for KPI1(remaining 0.4 are equally split

among other KPI). The weight of KPI1 is gradually

increase by 0.1 and the weights for other KPI1 are

decreased accordingly (EXP1a has v

=0.2 and

EXP1b has v

=0.4). The adaption results are

reported in Table 4. One can observe that initially

the adaptation improves customer service though the

result is not improved in the next step when KPI1

and KPI4 values worsen. Therefore, the adaption

should be reversed and the importance of KPI4

should be increased.

Table 4: Impact of the weights adaptation on KPI.

Expe-

riment

Z Cost KPI1 KPI2 KPI3 KPI4

EXP1 0.28 1.00 1.00 1.00 1.00 1.00

EXP1a 0.33 1.01 1.07 1.02 1.00 1.01

EXP1b 0.37 0.99 1.07 1.02 1.00 0.56

5 CONCLUSION

The paper developed a method for customization of

VR solutions. The customization is done in a model

driven manner making easier to involve company’s

representatives in the customization process. The

model driven customization of the VR model is

made possible by distinguishing generic and

customizable parts of the mathematical model.

Additionally, customization is achieved by

considering case specific data sources for measuring

context and adaptation of the model’s parameters

during its execution.

The proposed model depends on availability of

contextual data. Some of these data can be

accumulated during route execution while other can

be obtained from external sources. Sharing of data

among users of the VR service would be beneficial.

The model is computationally hard and model

solving time could be reduced by possibly

employing non-parametric optimization techniques.

Currently, the business model defines goals and

context. Business rules could be added to the

business model and these could be used to specify

constraints in the routing model. However,

Figure 5: Routing results for EXP1 (left panel) and EPX2 (right panel). Notable differences are marked with red dots.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

644

translation of business rules into the constraints

would impose specific requirements towards

specification of rules hard to fulfil in practice (i.e.,

requiring a mathematical modelling expert

participation in business model development).

Detailed numerical analysis of relationships

among context and routing goals and efficiency of

the adaptation procedure is beyond scope of this

paper and is subject of further research.

ACKNOWLEDGEMENTS

This research has received funding from the research

project "Competence Centre of Information and

Communication Technologies" of EU Structural

funds, contract No. 1.2.1.1/16/A/007 signed

between IT Competence Centre and Central Finance

and Contracting Agency, Research No. 1.6 “Support

for multi-criteria enterprise vehicle routing”.

REFERENCES

Abowd, G.D., 1999. Software engineering issues for

ubiquitous computing. Proceedings - International

Conference on Software Engineering, pp.75-84

Bērziša, S., Bravos, G., Cardona Gonzalez, T., Czubayko,

U., Espana, S., Grabis, J., et al., 2015. Capability

Driven Development: An Approach to Designing

Digital Enterprises. Business & Information Systems

Engineering, 57 (1), pp. 15-25.

Cardoso, P.J.S., Schütz, G., Semião, J., Monteiro, J.,

Rodrigues, J., Mazayev, A., Ey, E., Viegas, M. 2016.

Integration of a real-time stochastic routing

optimization software with an enterprise resource

planner. Advances in Intelligent Systems and

Computing, 582, 124-141.

Carton, F., Hynes, T., Adam, F., 2016. A business value

oriented approach to decision support systems. Journal

of Decision Systems, 25, pp. 85-95.

Cattaruzza, D., Absi, N., Feillet, D., Vidal, T., 2014. A

memetic algorithm for the Multi Trip Vehicle Routing

Problem. European Journal of Operational Research,

236 (3), pp. 833-848.

Chandra, C., Grabis, J., 2009. A Goal Model Driven

Supply Chain Design. International Journal of Data

Analysis Techniques and Strategies, 1, (3), 224-241.

Eksioglu, B., Vural, A. V., Reisman, A., 2009. The vehicle

routing problem: A taxonomic review. Computers &

Industrial Engineering, 57, pp. 1472-1483.

Ghannadpour, S. F., Noori, S., Tavakkoli-Moghaddam, R.,

2013. Multiobjective Dynamic Vehicle Routing Problem

with Fuzzy Travel Times and Customers’ Satisfaction in

Supply Chain Management. IEEE Transactions on

Engineering Management, 60, 4, 777-790.

Giaglis, G.M., Minis, I., Tatarakis, A., Zeimpekis, V.,

2004. Minimizing logistics risk through real-time

vehicle routing and mobile technologies. International

Journal of Physical Distribution & Logistics

Management, 34, 9, 749-764.

Haghani, A., Jung, S, 2005. A dynamic vehicle routing

problem with time-dependent travel times. Computers

& Operations Research, 32 (11), pp. 2959-2986.

Jozefowiez, N., Semet, F., Talbi, E.-G., 2008. Multi-

objective vehicle routing problems. European Journal

of Operational Research, 189 (2), pp. 293-309.

Keming, C., 2015. Research on Distribution Vehicle

Routing Optimization Based on Cloud Computing.

The Open Automation and Control Systems Journal, 7,

pp. 2184-2188.

Laporte, G., 1992. The Vehicle Routing Problem: An

overview of exact and approximate algorithms. European

Journal of Operational Research, 59, 345-358.

Madapusi, A., D'Souza, D., 2012. The influence of ERP

system implementation on the operational

performance of an organization. International Journal

of Information Management, 32 (1), pp. 24-34.

Parthasarathy, S., Sharma, S., 2016. Efficiency analysis of

ERP packages—A customization perspective.

Computers in Industry, 82, pp. 19-27.

Prindezis, N., Kiranoudis, C. T., Marinos-Kouris, D.,

2003. A business-to-business fleet management

service provider for central food market enterprises.

Journal of Food Engineering, 60 (2), pp. 203-210.

Solomon, M. M., 1987. Algorithms for the Vehicle

Routing and Scheduling Problems with Time Window

Constraints. Operations Research, 35 (2), 254-265.

Speranza, M. G., 2016. Trends in transportation and

logistics. European Journal of Operational Research,

in press.

Wan, J., Liu, J., Shao, Z., Vasilakos, A. V., Imran, M.,

Zhou, K., 2016. Mobile Crowd Sensing for Traffic

Prediction in Internet of Vehicles. Sensors, 16, 88.

Context-Aware Customizable Routing Solution for Fleet Management

645