108

ICT for efficient 05

road freight
transport
DEREK BEEVOR, WITH CONTRIBUTIONS FROM
BEN CLEWETT

The whole is greater than the sum of the parts.

ARISTOTLE

Introduction
From the mid-1980s the ability of a distributor’s transport management
system to interface with a customer’s computer system became a major selling
point for transport operators. Contracts were won or lost on the exibility
of a transport operator’s transport management system (TMS). A major
development at that time was for a transport operator’s customer base to
require a remote login to allow the distributor to follow the progress of jobs.
A large distributor could be handling work for several transport operators,
but the distributor would want to follow the progress of all their deliveries,
in real time, no matter which transport operator was handling the job. In the
subsequent decades, developments in information technology and the internet
have allowed for the development of bespoke systems that have signi cantly
enhanced the management of logistics and distribution. This chapter
discusses these developments and some of the issues associated with com-
patibility and security when systems are integrated to provide more effective
management solutions.
 ICT for Efficient Road Freight Transport 109

Skylark
One solution, developed by Road Tech to meet this need, was called Skylark
(Figure 5.1). In 1996 three manufacturers in the food industry came to-
gether to attempt to standardize some parts of what were, at the time,
relatively new telematics systems. Masterfoods, Coca-Cola Enterprise
and Procter & Gamble had become frustrated by the need to access many
separate websites in order to ascertain where their goods were within the
distribution system. Each haulage contractor used a separate booking system
and had separate telematic solutions. Thus, the simple task of identifying the
delivery time of a consignment was almost impossible. These organizations
therefore came together to see whether a solution could be found, and com-
missioned Road Tech to develop a system under the name of Skylark. The
idea was that a single website would publish details of all consignments
from all the involved haulage contractors. This would then be used to track
the progress of consignments, and also to provide key point indicators
(KPIs) measuring on-time arrival rates. These KPIs would be tied into the
contract of the haulier, providing an effective and open mechanism to
enhance ef ciency.

F I G UR E 5 . 1 Skylark logo

One of the biggest issues faced in the development of such a system was the
complete lack of standards. Skylark was intended to take data feeds from a
large number of systems. Thus, over the course of several months, every part
of what comprised a consignment and tracker was analysed and standardized.
Subsequently the best open standards were employed in order to provide
portals for data to ow between systems (for example, SOAP, HTTP and
XML). The interfaces were published in an open document, and the various
components brought together. This allowed any source of data to be entered,
110 E-Logistics for Transport Modes and Nodes

and the client was free to use any front-end system they wished to commission,
although ultimately the built-in front end developed by Road Tech became
the de facto standard (Skylark, 2015).
Road Tech enhanced the front end by predicting the arrival time of each
consignment in real time using route-planning software, calculating the
route of many thousands of items every minute. This provided a traf c-light
system where red indicated that the consignment could not possibly make
delivery on time. Skylark was an online (or cloud-based) system that interfaced
with different transport management and also telematics systems. The idea
was to present the customer with a live view of jobs that were being under-
taken for them by different transport operators who could possibly all be
using different transport management systems. This requirement for closer
integration and reporting led to much more data being available to enhance
the information held in the TMS. For example, data from telematics systems
and from digital tachographs allow much greater accuracy in reporting for
the transport operator. The following sections discuss the key aspects of
TMSs, being cloud computing, telematics, tachograph and GPS data.

Personal observation of the author: the beginning

of computerized transport booking systems

Derek Beevor first became involved with computerized transport

management systems in 1984. At the time he was running a small transport
company, taking the bookings over the phone, driving some of the trucks
and spending the weekend typing invoices. A labour-saving device
was needed to help with the paperwork side of the business and so a
programmer was employed. Together they developed a computerized
transport booking system. The theory was quite simple: instead of writing
down the details of a booking on paper and then transferring the booked
jobs to a traffic sheet, the job details would be typed straight onto a
computer screen and the system would then automatically complete the
traffic sheet and invoice the jobs at the end of the week. While this may
now sound quite simple, in 1984 the only computer packages available
to transport companies were simple accounts programs and Lotus 123
spreadsheet software. The transport booking system was a new concept
that worked and was a significant leap forwards.
The system worked so well that the author ended up selling the
transport company and developed a new business based around the newly
 ICT for Efficient Road Freight Transport 111

developed software. More than 30 years later the company is still

operating successfully, based on newer versions of the software first
developed in 1984. One of the major differences between then and now is
the amount of data that has to be dealt with, being many times bigger and
more complex. In the original systems all of the job information had to be
typed into the computer manually. Nowadays it is common for transport
bookings to be input directly into the system from the customer’s own
system; likewise if the transport company subcontracts a job, it will go
directly from the author’s system to another transport organization’s
system electronically. And this is not just one-way data transfer – the
systems have to update the progress of jobs so that, at each stage of a
booking, the two computer systems can exchange data to allow each
party to keep abreast of the job status.

Cloud computing
Cloud computing is now the standard method for telematics, tachograph
analysis and TMS software suppliers, and most of the valuable transport-
related information is stored in the cloud. But what is the cloud and where
is it? Cloud computing from the IT purist point of view says that it is not
important what hardware is used, or the location of the equipment, or even
who owns and maintains it. Services should provision themselves for the
needs of the user on-demand, and be elastic: thus they should scale to the
exact needs of the customer. Data is stored so that it cannot be destroyed by
hardware failure, or have any limits on size. While that is the purist point of
view, the question arises as to whether those organizations operating in the
transport industry are happy to use cloud services without the full knowledge
of where the data is being kept and how secure the servers are. While cloud
services are relatively cheap to set up and it is easier to share data, there is a
requirement for the data to be secure. Most telematics, tachograph and TMS
suppliers offer cloud services, but the issue may be whether they run their
own cloud servers or whether they have contracted out to a third-party supplier.
If the latter is the case and they have contracted out, the next question is:
how secure and safe is any data uploaded to such a system?
The most common use for cloud services is for simple data storage and to
facilitate the ease of sharing that data. For example, all of the photographs
that someone has taken on a smartphone can be stored in the cloud and then
synchronized to their tablet or home PC. But does the owner of those
112 E-Logistics for Transport Modes and Nodes

photographs have any idea of where they are being stored and who is
responsible for keeping them private? It may be Apple if someone is using
an iPhone, or it may be Microsoft or Google. There have been several incidents
reported in the press where celebrities have lost very personal photos that
were stored in the cloud, and until those photos were lost the owners had no
idea where they were kept or indeed that they could so easily fall into the
wrong hands (see for example Kedmey, 2014).
The same is true for very valuable transport-related data. The telematics
and tachograph data that are stored in the cloud contain an extremely
accurate account of everywhere that vehicles have been, how much fuel they
have used and how many times the drivers have broken the regulations. This
is not data that should be lost. From a commercial point of view, competitors
who may be bidding for a contract would nd such data invaluable. It is
important to know who is storing the data, whether they are subcontracting
that storage and, if they are, the strength of the third party’s security.

Virtual computers
Cloud computing is not just for data storage. The most common use of the
cloud in the business world is for hosting virtual computers. A cloud service
provider is able to set up a complete virtual computer for an organization to
use. This virtual computer looks like a normal computer to the user at the
interface end of the cloud service, but in reality it is only a le on the cloud
provider’s hardware. The fact that it is only a le enables the cloud provider
to store copies of that le for backup reasons and to easily replicate those
les if more computing power is required. So instead of being restricted to
the power of the hardware used, it will have unlimited power available as
long as the cloud provider can keep on replicating the les that represent the
computer hardware.
More and more companies are relying on virtual computers to run their
businesses, but how many of them consider security before investing in a
speci c system? Of course, if any cloud provider is asked about security, it is
likely they will have a standard reply that suggests they are very secure. Yet
how does a business ascertain the security provided by the cloud provider?
The standard way of undertaking a security check on a cloud service is via
a ‘penetration test’. The most basic penetration test is simply an automatically
run software package that looks up what software the cloud service runs
and then checks that all the relevant updates have been applied. This is a
very basic test and it does not provide a signi cant level of con dence in the
security of a system. Further, more comprehensive versions of automatic
 ICT for Efficient Road Freight Transport 113

software checkers are also quite limited in their scope. The only proper way
to run a ‘penetration test’ is via a third-party security expert or a reputable
company that specializes in these services. Comprehensive penetration tests
will take several days and cost around £10,000. However, there are only a
few transport companies testing the security to this level; the majority of
companies are either not looking, or are willing to take the cloud providers’
security assurances without undertaking in-depth checks for themselves.

Telematic data
Telematics is a branch of IT that deals with the long-distance communica-
tion of data, in this case gathered from commercial vehicles. The telematic
cloud is a service available on the internet that allows multiple telemetric
devices to connect and upload data for storage and analysis. Data will be
cross-referenced, aggregated and formatted to the requirements of the client.
Typically this is for a website, but can also be a web-service client – another
computer system consuming this data for its own needs. The aim is to collect
data and return this in real time to the cloud, typically: 1) real-time views of
vehicle operation; 2) historical reports.
The cloud service at company Road Tech typically hosts 20,000 or so
telematic inputs, including their own tracking devices, and feeds from many
other major telematic suppliers. This leads to the addition of many millions
of rows of data daily.

C A S E S T U DY Malcolm Group

An example of this cloud computing model is a trial on fuel economy by the

Malcolm Group, a leading haulier based in Glasgow (Malcolm Group, 2015).
Malcolm Group employed a mixed fleet of commercial HGV tractors and wanted to
standardize on a single vehicle manufacturer. Fuel economy was a vital input for
this decision. Three providers of telematic data on three vehicle types sent data to
a single cloud service based at Road Tech Computer Systems (Road Tech, 2015).
Some of this data came directly from telematic black boxes fitted in the engine bay
(Falcon Tracking, 2015), while others came from third-party telematic providers via
published APIs (Microlise, 2015; Dynafleet, 2015). Road Tech was then able to
normalize this data against tachograph data, global positioning system (GPS) data
114 E-Logistics for Transport Modes and Nodes

and TMS data: tachograph data provided information on when the vehicle was
driven, and the name of the driver; TMS data provided information on what
contracts and jobs were being completed; GPS provided input of the route taken
by the vehicles on these jobs.
Together this data provided information for fuel economy during typical work
shifts. This data was aggregated and broken down by driver, by contact, by job
type, by route driven by each driver and, of course, by the vehicle type. From this
data, Malcolm Group was able to confidently report that their Volvo FM11 offered
the best fuel, archiving over nine miles per gallon. From this, 40 vehicles of the
same type were purchased. Chief Executive Andrew Malcolm said: ‘I am confident
in Volvo’s approach to Euro-6 and I expect the newcomers to at least equal, if
not exceed the performance of our current FM trucks.’ This multi-million-pound
decision was aided by successful collection and analysis of telematic data from
multiple sources. It can be appreciated how useful telematic data can be to a
commercial organization, and also some of the complexity involved in gaining
useful and usable data (Meczes, 2013).

Data source
Data available from commercial vehicles may be derived from a number of
sources:

● controller area network (CAN) bus, eet management system (FMS)

and on-board diagnostics (OBD);
● tachograph;
● global positioning system (GPS) trackers;
● driver collected data;
● external sources:
– transport management systems (TMSs);
– fuel suppliers;
– driving licence checks.

CAN bus
The CAN (controller area network) is a serial network within a vehicle,
designed to allow components to communicate without the requirement for
 ICT for Efficient Road Freight Transport 115

a central controller. Started in 1983 at Robert Bosch GmbH (CIA, 2015),

standardized in ISO 11898 in 1993, CAN is now found in all vehicles. The
primary reason for CAN is to reduce the amount of signalling wires used
on a vehicle. As well as Bosch, CAN is manufactured by Magneti Marelli,
Sagem, Siemens and others. CAN can connect together as many as 70 electronic
control units (ECU), the most important of which is the engine control unit.
Another signi cant use of CAN is for the dashboard, where a large bundle
of wires is replaced by just two. Other uses include engine management,
telematics and other peripheral uses such as informing the stereo that the
lights are on, so that it can illuminate the display.

CAN mechanics
CAN is formed from two wires carrying the same data, labelled CAN-high
and CAN-low. The signal is taken from the difference between the two wires
(differential), and not from ground. This has signi cant advantages in the
reduction of noise. A typical message, or frame, consists of an ID and data.
The ID identi es the ECU and data address. The data may be a digitally
encoded reading from the vehicle. In order to provide service to safely critical
systems, the BUS has a priority. Frames of a higher priority take precedence
over those of a lower priority. Typical priorities are:

Priority 1: engine controls, brakes and airbags. These are of the utmost
importance from a safety viewpoint. Commands to activate these
systems are given highest priority and will be actioned over less
critical ones.
Priority 2: audio and navigation devices are often medium priority.
Priority 3: simple activation of lighting may be lowest priority.
(see: http://www.picoauto.com)

Vehicles may also contain more than one CAN. Different CAN standards
require more than one network, and this also isolates some parts of the
vehicle from the general CAN. In recent vehicles the use of multiple CAN
networks has replaced the priority, with lower-priority broadcasting to
higher networks through a gateway.
There are several common CAN networks that may all be in use, including:

● J1708: early CAN spec, only 9600 baud, now more commonly
known as Dash CAN, due to the fact that because of its slow
speed it is mainly used for instrumentation and warning message/
light information.
116 E-Logistics for Transport Modes and Nodes

● J1939: higher-speed CAN, now with 16bit address range, with a bit
rate of 250kbit/sec, and with some default parameter group number
(PGN) and some proprietary information.
● J11992: an extension of J1939 but with a more robust physical layer
used to communicate with the trailer.

This list is not exhaustive; Wikipedia lists 20 or so other technologies

(Wikipedia, 2015a).

Issues with CAN

Although CAN reduces the weight of a vehicle and drastically cuts the
number of wires, it also increases the cost and complexity of the vehicle, and
can make faults hard to nd without expert knowledge. Further interpreting
CAN can be hard or impossible for third parties. Documentation is required,
which is sometimes elusive due to the closed nature of some vehicle
manufacturing. CAN also does not contain any security and any ECU can
listen or send to the CAN. While mechanisms exist in order to pass secure
information (eg key codes) these are, however, extensions to the protocol
rather than built into it.
CAN is optimized for small data frames: for instance, a reading of engine
coolant temperature. The movement of media across CAN is slow, and may
block signals of other ECUs. For instance, the retrieval of tachograph driver
history data, which uses its own private CAN.
While in terms of telematics it is simple for third parties to join the bus
this may lead to interference with the running of the vehicle, or even cause
damage. It has been claimed that vehicle res have been caused by a third
party cutting into the CAN. However, reading the CAN may be completed
using induction, which protects the CAN and removes the need to cut into
wires (see Figure 5.2). For instance, a patent is held by Masternaut S.A.S for
the induction reading of CAN (Masternaut, 2015).

F I G UR E 5 . 2 Connecting an induction reader to CAN

 ICT for Efficient Road Freight Transport 117

Some CAN data may contain quality issues of which fuel is arguably the
most important. Fuel usage is one of the highest costs associated with
operating a commercial vehicle, and is therefore commercially sensitive.
As has been shown, commercial vehicle sales are made and lost on fuel
economy. This data is only readable on internal CAN networks, to which
telematic providers are not encouraged to connect.
The ‘total fuel used’ may be read, and is the ‘holy grail’ metric. However,
this gure may be inaccurate and require calibration in each vehicle, which
is a long and tedious process and possibly requires access to more than one
CAN bus.

Fleet management system

A public interface to the CAN is commonly available in order to address
some of the issues. The eet management system (FMS) interface provides a
read-only standard interface providing some common metrics, and also acts
as a rewall, protecting the internal CAN from injection of data from
unknown ECUs. This uses the J1939 standard. FMS was agreed in 2002 by
the six main manufacturers: DAIMLER AG, MAN AG, Scania, Volvo
(including Renault), DAF Trucks and Iveco. According to ACEA around
160,000 vehicles were tted with an FMS standard interface in 2007.

Issues with FMS

Although FMS would seem to be a good solution, it has not been completely
or correctly implemented by all manufacturers. FMS ports may be provided
only at additional cost, and the manufacturer is not required to broadcast
any metrics they choose to withhold. Fuel is an example of a gure that
is less often broadcast. This can make FMS less than ideal and therefore
many telematic solutions continue to take a feed from the internal CAN
system.
Examples of some metrics available on FMS are:

● vehicle speed;
● brake switch;
● total fuel used;
● engine speed;
● axle weight;
● tachograph information;
● engine coolant temperature (Wikipedia, 2015b).
118 E-Logistics for Transport Modes and Nodes

On-board diagnostics
The on-board diagnostics (OBD) port provides a diagnostic port that may be
used by repair technicians. In 1996 OBD-II became mandatory in all cars to
be sold in the United States, and all cars sold in the EU from 2003 (Figure 5.3).
Often located in the fuse box, this contains a power source, various diagnostics
and access to CAN. Early OBD simply illuminated a malfunction indicator
light if a problem was detected, but would not provide any information as to
the nature of the problem. Later versions showed a single error code. Modern
OBDs use a standardized digital communications port to provide real-time data
in addition to a standardized series of diagnostic trouble codes. A standard
interface to the vehicle CAN is provided in the OBD-II socket, using J2284,
ISO 11898 and ISO 15765, broadcasting a limited set of data.

F I G UR E 5 . 3 OBD-II socket

For telematics, the CAN is of particular interest, aided by cheap CAN to

Bluetooth dongles, which broadcast CAN to any paired computer. A developing
market in insurance linked to OBD-II is maturing, whereby the driving style
of the insured party can be monitored, combined with GPS and video feeds.
However, for the commercial vehicle advanced telematics, usability is somewhat
limited. The vehicle manufacturer is under no obligation to publish more
data than required. For instance, Volkswagen diesel cars broadcast con-
siderably less data than petrol models, simply because this is not a legislated
requirement. Deep feedback on such systems – including accurate fuel use,
throttle and brake positions, transmission modes and cruise control – remain
elusive. However, some telematic providers (for instance TomTom Telematics
(TomTom, 2015) do make use of OBD-II.
 ICT for Efficient Road Freight Transport 119

Tachograph
A tachograph is a recording device tted to a vehicle, which automatically
records the vehicle speed and distance as well as the ‘mode’ the driver is
currently in. Made compulsory under European Union law in 1985, original
analogue tachographs recorded to a wax disk. From 2006, digital driver’s
cards were introduced, resembling a modern chip-and-pin bank card
(Figure 5.4). These are currently tted to all HGV vehicles above 7.5 tonnes,
and PSV vehicles of nine passengers and above. In future they will be tted
to all commercial vehicles, although exceptions exist.

F I G UR E 5 . 4 A modern digital tachograph from VDO

SOURCE: government document https://movingon.blog.gov.uk/do-you-use-a-digital-tachograph/

The mode of work is of particular interest. This records the history of when
a driver drives, rests and works, and is available every minute. Strict limits
on maximum driving time and minimum resting time are stipulated in
European Union regulation EC 3821/85, and updated to EC 561/2006.
Within the UK, penalties for breaking these limits are non-trivial for both
the drivers and their operator.
As well as laws on tting and using tachographs, there are also laws to
ensure the data is downloaded, stored and analysed. Compliance is monitored
by the DVSA (formally VOSA) who employ their right to raid companies
and check their record keeping (Tachomaster, 2015).
The tachograph takes input from a speed sensor located in the gear box,
and input from the drivers. Data is stored internally, and also written to the
driver’s card (Figure 5.5). A standard smart-card reader is used to read the
card, and a download tool is used to retrieve the data from the tachograph.
Data is also available directly from the tachograph. A K-Line interface (ISO,
2015) and private CAN broadcast data continuously. A complete driving
history can also be obtained through the CAN using a complex protocol,
involving unlocking the tachograph using a company card.
120 E-Logistics for Transport Modes and Nodes

F I G UR E 5 . 5 Specimen digital driver card

SOURCE: government-produced training card

From the perspective of telematics, the tachograph offers a good source of

data. The requirements for tting and using tachographs are mature and
robust, and therefore high-quality information is available. Published EU
documents are available explaining how to extract and interpret the data
(Europa, 2015).
Tachographs offer two types of data, both of which are available from
the K-Line and CAN:

● Live data:
– odometer;
– speed;
– driver(s) numbers and names;
– driving mode;
– information on compliance with regulations for driving (DDS).
● Historical data:
– driving history for past two months on driver’s card;
– history for several years within tachograph;
– speed data for last 24 hours of driving, to one-second accuracy.

What this means to the data analyst is that the current driver may be identi-
ed in a vehicle, and the driving completed by that driver may be identi ed;
the speed data, acceleration and braking rates can be calculated, as well as
adherence to speed limits.
Some issues with tachograph data exist. Older tachographs sometimes do
not broadcast information correctly, or at all. Tachographs do not broadcast
information when the ignition is off. Although, oddly, the tachograph never
powers off, it just refuses to share data. Therefore, if a driver were to record
a period of rest without ignition, this data would be lost to any telematic
 ICT for Efficient Road Freight Transport 121

system. This has consequences for the telematic company, since valid rest
allowing further driving cannot be ascertained. Solutions to this issue are
becoming available.

Global positioning system

Global positioning system (GPS) telematics have gone from specialist products
to an almost universal feature on commercial vehicles. The availability and
accuracy of the GPS system, and almost insigni cant cost of mobile data,
has ensured that a wide variety of quality products are possible. The GPS
system was a product from the US military, activated in 1995. Originally
GPS was available to the military with high accuracy, and civilian users with
low accuracy, being broadcast from 24 satellites, ensuring that every part of
the planet had line of sight to several satellites simultaneously. In 2000 the
high-accuracy signal became available to all users. Other systems include
Galileo from Europe, GLONASS from Russia and COMPASS from China,
which are already available in the UK, or will be coming soon.
GPS is now such an integral part of so many systems that it would be
hard or even dangerous to discontinue this service. Car navigation, aviation,
asset management, shipping, traf c data, hiking, space ight, even shopping
via Google: all have found essential uses for GPS. Most modern computer
systems and mobile phones contain some form of GPS, even if the user is not
aware of it. Telemetry in vehicles nds its roots in GPS. This was initially
limited not by GPS technology, but by the dif culty of sending data back to
the of ce. Only when mobile phone technology matured did costs begin to
fall dramatically.
The frequency and amount of data sent back has expanded dramatically.
Latitude and longitude (lat/long), together with complete CAN and tachograph
data, may be sent to the cloud several times a minute whilst keeping the data
costs below £10 per month. However, the ability to plot the position of a
vehicle is not the ‘killer’ application for lat/long data. A competent system
may provide much more useful data such as:

● recording arrival and departure from known locations (de ned by

polygonic geofences);
● monitoring the route taken by the vehicle and alerting when
deviating from given route;
● recording infringement to speed on the current road;
122 E-Logistics for Transport Modes and Nodes

● analysing fuel usage against other metrics: for instance, the driver or
the vehicle type;
● advising on expected arrival times of vehicle to its destination, and
alerting when predicted to be late.

When evaluating GPS systems, it is vital to ensure it gives those features

required to make the system an asset for the customer.

Transport management systems

The transport management system (TMS) keeps information about individual
vehicle jobs, for example:

● the job that the vehicle and driver are currently undertaking;
● the start and end locations of that job, and at what times the vehicle
should be, and actually does, arrive and leave those locations;
● the manifest of goods carried by the vehicle;
● the link to the order processing of the job, therefore the state of a
customer’s order.

This information gives context to other telematic data, for instance, exception
reporting where the vehicle position does not match the actual position.
Telematic data can also link back to the TMS by advancing the job status
when the vehicle is known to be en route and has arrived at the destination
described by the current job. It is common for this data to be used in appli-
cations such as KPIs. For instance, the percentage of jobs completed on time
would be used as a KPI to judge the quality of a contract between haulier
and vendor. This may be linked to bonuses or penalties.
Another area of symbiosis between the TMS and telematic data is planning.
For instance, the daily work sheets for drivers and vehicles must utilize the
available driver working hours and vehicles effectively. A quality planning
tool should be able to utilize telematic data in order to plan the daily work
for each driver and vehicle. For instance, tachograph data shows the amount
of driving time that a driver can complete during their shift. If a job exceeds
this time, it cannot be completed. If a driver is left with time to spare at the
end of their shift then this reduces ef ciency. Likewise with vehicles, ef cient
use will reduce fuel, and therefore CO2 and running costs. It can therefore
be appreciated that effective integrated telematics goes a long way beyond
simply displaying live vehicle locations.
 ICT for Efficient Road Freight Transport 123

IT system development
In the days before cloud computing, a transport operator would typically
buy a software package loaded onto a personal computer or a network
of PCs. These tended to be standalone systems, which made the task of
integrating with other IT systems dif cult to achieve. The development
of widespread internet connectivity made it easier and cheaper for multiple
locations to join onto the same network and work together, but the task of
integrating different systems was still a slow process. The turning point
came with the growing popularity of cloud-based systems and ‘software as
a service’ packages. These systems allowed transport operators to use a
booking system, a telematics system and a tachograph system that were
fully integrated with each other and made available over the internet. It was
still necessary to use just one IT supplier for all three packages but it was
easier to make the integration work because it was done at the developers’
end and made available as a cloud service. However, integrating different
supplier systems was still a problem even when using cloud-based systems.
IT providers are very keen to lock their customers into their systems – generally
speaking most IT providers will avoid integrating their system with another
supplier and try to sell the transport operator their own version of alternative
products.
Occasionally the integration of systems will stall (Figure 5.6). An example
of the stall in systems integration can be found by looking at the different
vehicle manufacturers’ own telematics offerings. A transport operator may
have a mix of vehicles in their eet; for example they may have Volvo,

F I G UR E 5 . 6 IT systems development
d
ou
Cl
&
n
t io
rag
te
Productivity

In

Stall
s
ys tem
ls
ua
di vid
of in
ss
gre
Pro
IT systems development
124 E-Logistics for Transport Modes and Nodes

Mercedes and Scania trucks. Each of these vehicle manufacturers has their
own in-house telematics systems, and these will not integrate with each
other. However, all of these telematics products by the vehicle manufacturers
are essentially the same. They consist of a small computer and modem tted
to the truck, which sends information to a web-based telematics system for
the transport operator to use. In a fully integrated world, the transport
operator would be able to use just one of the web-based telematics products
to view the hardware installed in the Volvo, Mercedes and Scania vehicles,
but this is not provided as standard by the vehicle manufacturers. As was
shown in the Malcolm Group case study, it is possible to get each vehicle
manufacturer’s web data sent to one data service, but the different hardware
components on each vehicle will still not communicate with anything other
than the vehicle manufacturer’s own system.
It should be quite simple for vehicle manufacturers to integrate their vehicle
hardware with each other. As we saw earlier, there is a common standard for
the data that is collected from vehicles. The FMS interface is a standard
interface agreed in 2002 by the six main manufacturers (DAIMLER AG,
MAN AG, Scania, Volvo (including Renault), DAF Trucks and Iveco). So the
data that are collected from trucks is an agreed standard and the hardware
tted to trucks are all essentially the same thing: a computer and a modem.
So why doesn’t the hardware integrate with other hardware? The answer
may be that the vehicle manufacturers see their own individual telematics
systems as an asset to help them sell their trucks. There may be a feeling that,
if the transport operator likes a particular vehicle’s telematics system then
the operator will be more likely to buy only that particular manufacturer’s
trucks. The desire to ‘lock’ customers into systems is causing a stall in the
development of IT systems for the transport sector. This will not be an easy
issue to address. The suppliers of IT systems are competing with each other
in a very competitive marketplace and, generally speaking, they see no bene t
from sharing their systems knowledge or data with other IT suppliers.
However, there is a real need to fully integrate systems.
Taking a simple truck journey as an example, the whole journey from the
starting point, through the various stages of the journey and back to the
starting point, will be recorded in some form of booking system (Figure 5.7).
The booking system will know which customers the vehicle will be working
for, how much to charge for each section of the journey and exactly what
the vehicle will need to deliver and collect. So at the start of the journey all
of the information needed is recorded in the booking system, but once the
vehicle gets under way the vehicle may encounter a delay. This delay infor-
mation may be recorded in a separate telematics system and the information
 ICT for Efficient Road Freight Transport 125

F I G UR E 5 . 7 Simplified transport journey

Start

Delay

eg
yl
pt
Em
Delivery

Delivery
ty leg
Emp
Reload

about the delay will need to be sent to the delivery point. Information about
the delay will also be needed back at the booking system, because the original
delivery may not still be possible and the reload details will almost certainly
need to be changed. At the end of the day, what was originally booked needs
to be changed and the information about these delays and changes are
recorded differently in different IT systems. While there are clear bene ts to
be gained from fully integrated systems there are still no ‘open’ standards for
this integration to take place between different IT suppliers.
Another obstacle to the full integration of different transport IT systems
is the quality of the data. Some systems will provide poor data that a better
quality supplier may well be reluctant to integrate. Continuing with the
example of the telematics system and considering, for example, the fuel data
that these systems report: some telematics system suppliers will receive fuel
data from the vehicle’s on-board CAN bus. Generally speaking this is a good
way to obtain fuel data and will provide the transport operator with fairly
accurate fuel-consumption information. However, it is quite expensive for
the telematics supplier to interface correctly with the vehicle’s CAN bus, so
some telematics suppliers take shortcuts. Instead of interfacing to the vehicle’s
CAN bus, their on-vehicle units will use a built-in accelerometer chip to
register how the vehicle is being driven, roughly or smoothly, and then use
an algorithm to calculate the vehicle’s supposed fuel consumption. This
method is just an educated guess about fuel consumption, as opposed to a
system that obtains its fuel information from the vehicle’s CAN bus. Fuel
can be half of the operating cost of a vehicle, so the transport operator will
want more accurate information rather than just an educated guess
126 E-Logistics for Transport Modes and Nodes

provided by a cheap telematics systems. Very often, the vehicle operator is

completely unaware of where the telematics system is getting the fuel
information from.
There are several ways to get the CAN data but it is legally questionable
for the telematics supplier to wire directly into the J1939, J1708 or J11992.
The FMS port is a sort of rewall that can be connected to without causing
system problems for the vehicle manufacturer. However, now that many
vehicle manufacturers are trying to sell their own versions of telematics
systems, they have started to charge the transport operators for providing
the vehicle with an FMS port. This is somewhat disingenuous because, as
has already been shown, the FMS port was originally developed as an open
system that all truck manufacturers agreed on, but now that the vehicle
manufacturers want to sell their own equipment they are charging up to
£700 to provide the open port that an independent telematics company will
need. This could be viewed as a £700 surcharge from the vehicle manufacturer,
made if the transport operator wants to use an independent telematics
supplier instead of the vehicle manufacturer’s own system, which will not
need an FMS port.
The pressure is on now for telematics suppliers to provide quality systems
with accurate data. Many telematics suppliers have a long way to go.
Interestingly, as we have already alluded to, the quality of telematics data
improves when telematics systems are integrated with the vehicle’s on-board
digital tachograph system. The transport operators are also demanding that
any potential telematics supplier is also capable of providing a link to the
vehicle’s digital tachograph data. There are very practical reasons why
the transport operators want the telematics and digital tachograph systems
working together. EU regulations require that a vehicle’s digital tachograph
is downloaded every 56 days and that the drivers’ cards are downloaded
every 28 days. In practice this means that the transport operator will have
to go to each truck, every 56 days, and manually download the digital
tachograph data onto a memory stick. This data will then need to be stored
or uploaded to a tachograph analysis system. If the truck has a competent
telematics system, then the telematics system should be able to remotely
download and store the digital tachograph data, therefore making sure that
the legal requirements are satis ed and also saving the transport operator a
great deal of time and effort.
The vehicle’s telematics system will be constantly sending position and
CAN bus data back to the operator. The operators will also bene t from a
constant update from the digital tachograph system being sent to them at
 ICT for Efficient Road Freight Transport 127

the same time but, once again, this will mean that the telematics providers
will need to integrate their systems with the vehicle’s digital tachograph. At
the moment there is some confusion in the market: telematics buyers are not
sure which systems integrate properly, and telematics sellers have tended to
underestimate the complexity of integrating their respective products.
Vehicle manufacturers are also offering to download digital tachograph
data as an add-on service to their own telematics systems, although they
are charging heavily for a very limited offering. Vehicle manufacturers only
offer to download the digital tachograph data on a monthly basis in line
with the legal minimum download requirements. Proactive transport operators
will want the digital tachograph data much more frequently than this, and
it is more likely that the transport operators will want the digital tachograph
data on a daily basis; they may even require a constant live feed to the vehicle’s
tachograph so that they can remotely monitor the drivers’ hours in real
time.
TMSs, or bookings systems, also need to integrate but these systems tend
to be more isolated from the rest of the world. There is a great deal of
dedicated integration between TMSs and the transport operators’ customers
and subcontractors, but not on an open basis. There are of course web
services that offer backloads, or even run a type of auction service to get the
cheapest price for sending a pallet of goods somewhere, but it is likely that
these open services will remain quite small. There is normally quite a lot of
bespoke work involved when integrating transport operators’ systems and
their customers’ systems, and the development of a large online transport
portal is unlikely to occur in the near future. There will, of course, always be
online back-loading systems, and some organizations still like the idea of
running online auctions for potential carriers to bid on, but these are likely
to remain quite a small part of the industry for the time being.
The real gains are to be found when all of the computer systems in a
supply chain are closely integrated and therefore large manpower savings
can be made. The ef ciencies that are made by closely linking the systems in
a supply chain far outstrip the rather doubtful bene ts of getting cheaper
quotes through an online auction. The linking together of TMSs with the
rest of the supply chain also offers greater visibility to all parties. So, for
example, when a vehicle is delayed en route and the vehicle’s on-board
telematics systems reports the delay to the TMS, that information can be
relayed to everyone else who will potentially be affected by the delay, allowing
the original plans to be changed or amended as necessary. The point has
been reached where most individual systems are quite good, but the real
gain in productivity can only be obtained when all of these individual systems
128 E-Logistics for Transport Modes and Nodes

talk to each other effectively. This is the next big task and it is not just a
technical challenge. Individual software providers and vehicle manufacturers
are focused on their own market share and do not see the value of spending
too much time integrating their products with what they see as competitors.

Big data
The term ‘big data’ can mean different things to different people. The most
common reference to big data is in the advertising world, where lots of
information about internet users can be pooled together to allow the
advertiser of goods to speci cally direct their adverts to the people who are
most likely to buy their goods. There is also quite a fan base for big data
who advocate searching enormous amounts of data to provide answers to
complex questions, the idea being that there are answers hiding in all of this
data that we need to tease out. But another use of the big data term could be
to describe the growing trend for systems to talk to each other and share
information. Some people refer to this as the ‘internet of things’, but perhaps
it should be called ‘not quite so big data’ because it refers to smaller data
quantities that are much more speci c. The trend for these smaller quantities
of speci c data sets to be integrated is much more interesting than the usual
references for big data. But perhaps another proviso should be added; the
big data that should also be referred to as ‘accurate data’. Accurate and
timely data are very valuable, especially in the logistics world. There are real
savings to be had when organizations share accurate data.

Conclusion: the need for greater

collaboration?
As of 2015 there are thousands of transport organizations using their own,
mainly bespoke computer bookings systems. They are also using proprietary
telematics systems that do not fully integrate. Not even the large vehicle
manufacturers can agree to make their respective telematics systems integrate
with each other. There is an EU legal requirement for transport operators to
gather large amounts of data about a driver’s hours and store it for two
years. This compliance data is also incredibly valuable management data.
So the transport and logistics sector is awash with data but it is all held in
different systems, and used for different reasons, and there is an ongoing
reluctance for commercial motives to integrate and share this data. The
 ICT for Efficient Road Freight Transport 129

question that needs to be asked is just how much more ef cient the logistics
industry could be if a point was reached where companies were willing and
able to fully share their data. The full visibility of the trucks on our roads,
the number of hours that each driver has available and the next destination
for that particular truck is indeed valuable information, and it is standard
information that our current technology has made available – it just is not
shared.
The ability to create closer collaboration between transport operators
and share resources is limited because of the sort of contracts that the transport
operators work under. It is quite common for a transport operator to have
standard nes levied against them and built into their contracts for vehicles
that are late, or even early, at a delivery site. Under these circumstances it is
no wonder that a transport operator is reluctant to share their resources or
suggest a more eco-friendly way of running their vehicles. It may be extremely
ef cient, for example, for a vehicle to complete a delivery for Tesco and then
a collection for Asda, but this can only work if both Tesco and Asda agree
to be exible. The question here is: can we create exible contracts that will
allow large-scale collaboration between transport operators to become a
reality? Systems integration and exibility between procurement and transport
operators are the minimum requirements for this collaboration to begin.
There are examples of collaboration between logistics organizations but
these are tiny compared to the potential of what can be achieved if IT systems
were ever truly integrated. Is this level of integration just a pipe dream? Will
it prove too dif cult to renegotiate individual commercial contracts to allow
for fully integrated systems? Will procurement departments recognize the
value of integrated data and be prepared to pay a little more for consolidated
systems? These are the questions that will take us through to the next cycle
of development in the transport industry’s IT systems.

References
CIA (2015) [accessed 9 November 2015] Can in Automation, CIA [Online]
http://www.can-cia.de
Dyna eet (2015) [accessed 9 November 2015] Dyna eet [Online]
http://www.dyna eetonline.com
Europa (2015) [accessed 9 November 2015] Commission Regulation (EC)
No 1360/2002, Of cial Journal of the European Communities [Online]
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2002:207:0001:02
52:EN:PDF
130 E-Logistics for Transport Modes and Nodes

Falcon Tracking (2015) [accessed 9 November 2015] Vehicle Tracking [Online]

http://falcontracking.co.uk
ISO (2015) [accessed 9 November 2015] ISO 9141:1989 Road vehicles –
Diagnostic systems – Requirements for interchange of digital information, ISO
[Online] http://www.iso.org/iso/catalogue_detail?csnumber=16737
Kedmey, D (2014) Hackers leak photos of more than one hundred celebrities,
Time, 1 September 2014
Malcolm Group (2015) [accessed 9 November 2015] Malcolm Group [Online]
http://www.malcolmgroup.co.uk
Masternaut (2015) [accessed 9 November 2015] Masternaut Mobile Resource
Management [Online] http://www.masternaut.co.uk
Meczes, R (2013) [accessed 9 November 2015] Fuel trial spurs Malcolm
Group to buy 40 new tractive units, Motor Transport, 5 May 2013 [Online]
http://motortransport.co.uk/blog/2013/05/05/fuel-trial-spurs-malcolm-group-to-
buy-40-new-tractive-units/
Microlise (2015) Fleet Performance – Unrivalled Vehicle and Driver Insight,
Microlise [Online] http://www.microlise.com/products/ eet-performance/
Road Tech (2015) [accessed 9 November 2015] Road Tech – Innovate, Integrate,
Secure [Online] http://roadtech.co.uk
Skylark (2015) [accessed 9 November 2015] Skylark [Online]
http://www.skylarkgps.com
Tachomaster (2015) [accessed 9 November 2015] Tachomaster [Online]
http://www.tachomaster.co.uk/documentation/wikidoc
TomTom (2015) [accessed 9 November 2015] TomTom Telematics [Online]
http://business.tomtom.com
Wikipedia (2015a) [accessed 9 November 2015] CanBus [Online]
http://en.wikipedia.org/wiki/CAN_bushttp://en.wikipedia.org/wiki/
CAN_bushttp://en.wikipedia.org/wiki/CAN_bus
Wikipedia (2015b) [accessed 9 November 2015] Fleet Management System
[Online] http://en.wikipedia.org/wiki/Fleet_Management_System