On-board units (OBU)

In the building of the on-board unit (Figure 153) the important aspects are a heavy-duty design (EMC protection, shake protection, fluctuation of environmental temperature, etc.) and modularity. Therefore one should use a system that is built up of individual units. The connection of these by a series communication connection is worth realizing for the sake of simplicity and easy expansion.

Figure 14.2. General architecture of the on-board unit

The on-board unit is made up of the following main units:

GSM/GPS module, central unit,

human interface device, diagnostic adapter, I/O module,

power supply unit and background batteries.

The basic on-board units are often referred to as AVL. The abbreviation of AVL stands for Automatic Vehicle Locator[138], most commonly called as vehicle tracking device. There are GPS and/or GLONASS based positioning systems integrated together with an industrial GSM/UMTS modem, which sends the positioning information on-line to a central computer server. AVL devices may be extended with vehicle technical information like fuel tank level, engine revolution, fuel used, and so on.

4.1.1. In-Vehicle Data Acquisition

The most important and most complex function of the on-board unit is the exact acquisition of the vehicle data with special regard to the fuel consumption.

There are two ways to collect the necessary data:

sensor retrofit

in-vehicle communication buses

Formerly the first alternative was used generally because of the low penetration and hard reachability of the in-vehicle communication buses. This solution has several drawbacks, such as high cost, low reliability and accuracy, safety and warranty problems etc.

The other solution is generally based on the CAN bus technology, see [139]. CAN stands for Controller Area Network, meaning a computer network formulated by the vehicle‘s electronic control units (ECU). CAN was primarily developed for automotive applications but later - due to its simplicity, reliability and electromagnetic immunity - it appeared also in industrial (CANopen), military (MilCAN), aerospace (CANaerospace) and nautical (SeaCAN) applications.

CAN bus is an asynchronous (time-shifted) serial bus system, originally developed by Robert Bosch GmbH from 1983 to interconnect electronic control units (ECU) in motor vehicles and was introduced in different steps to reduce cable harnesses and thereby weight. Instead of using an electrical circuit for each transmitted signal, the "bus" is based on a communication platform that regulates the relaying of messages between several devices.

In a practical context, the process is as follows: While the rear light was actuated by means of guiding a current to the rear light, the bus system only relays a message: "Light switch to rear light: Switch on!" Translating all control signals into messages requires a "greater intelligence" of the connected devices, at the same time this implies that many devices can exchange information, virtually at same time, using a very limited number of cable connections. (Source: [140])

All the necessary vehicle data is reachable on one of the vehicle CAN buses. There are great numbers of vehicle manufacturers having different types of vehicles on the market. They all have specific in-vehicle communication systems. To be able to ―understand‖ each vehicle, one has to learn all these specific ―languages‖. Practically that means the developers of the Fleet Management Systems cannot interpret the data on the vehicle‘s CAN bus. It is caused by the lack of the standardization of the CAN messages or the slight of the standards by the vehicle manufacturers.

In 2002, six major truck manufacturers (Volvo, Scania, Iveco, MAN, DAF, Mercedes-Benz) decided to create a standardized vehicle interface for these GPS based tracking systems, called the Fleet Management System Standard (FMS Standard). Since the establishment of the FMS Standard, there is no need to learn just one

―language‖. No matter which OEM produced a vehicle, if it was equipped with an FMS interface (FMS Gateway), there is the same output for all vehicles. The standard itself was a huge step forward in fleet management, since telematics devices (AVL) could access vehicle technical information without the need of vehicle specific developments.

FMS Standard versions:

FMS Standard 1.0 (Initial standard issued in 2002)

Bus FMS standard (Ver. 00.01 issued in 2007, specialized standard for buses and coaches including specific signals like door openings, etc. Since then the original ―FMS Standard 1.0‖ was also referred as ―Truck FMS Standard‖)

FMS Standard 2.0 (extended standard issued in 2010. This standard took over some signals from the Bus FMS Standard, but FMS Standard 2.0 was still handled separately for Trucks.)

FMS Standard 3.0 harmonized Bus and Truck standard (issued in 2012). From now on there is only FMS Standard 3.0, but there are separated sections inside for buses and trucks.

The development of FMS-standard is now under the umbrella of the European Automobile Manufacturers‘

Association (ACEA). The dedicated working group ―Heavy Truck Electronic Interface Group‖ meets regularly to discuss the needs of the FMS-standard. (Source: [141])

Now third-party solutions can be reached on the market for CAN-based data acquisition for vehicles without FMS interface. For example Inventure FMS Gateway which is an intelligent and cost-effective CAN bus interface with aim to monitor fuel consumption and other vehicle parameters. It helps to prevent fuel theft, avoid unnecessary operational expenses and protect the environment while driving smarter. Inventure FMS Gateway connects to the vehicle communication network, collects, processes using high precision algorithms and transfers vehicle related technical information to GPS based fleet management (AVL) systems. Inventure FMS Gateway can replace expensive and time consuming manufacturer‘s FMS interface installation and activation. It represents general solution for all types of vehicles. It supports multiple output protocols such as CAN (FMS Standard compatible), serial (RS232) and Bluetooth. (Source:[142])

4.2. Communication

By the on-line fleet management systems the data have to be transferred with high reliability and integrity.

At present the fleet management systems use the public GSM network for data transmission. There are three possible technologies for this task:

SMS based, circuit-switched and packet-switched.

Nowadays the packet-switched communication is used most frequently. The most widespread is the GPRS (General Packet Radio Service), and EGPRS (Enhanced GPRS) which ensures larger bandwidth. In the 3G networks the UMTS and HSDPA can be used, but these techniques haven‘t come into general use in fleet management systems because of the low covering and high prices of the devices.

The advantages of the packet switched technologies are the following:

continuous connection, larger bandwidth, data amount based costs, low prices.

The SMS based data transmission can be a backup in case of GPRS service‘s unavailability and it can be used for special purposes, for example sending alerts directly to mobile phones.

An example communication system can be built up by OSI model [143] as shown on Table 4.

Table 14.1. Communication system

Application layer XML based protocol

There are several other possibilities elaborating the communication system. The first 3 layers are given when using GPRS networks. In the transport and session layers the UDP (User Datagram Protocol) or TCP (Transmission Control Protocol) can be used. UDP uses a simple, connectionless transmission model with a minimal protocol mechanism[144]. It has no handshaking process, thus any unreliability of the underlying network protocol devolves to the user's program. There is no guarantee of delivery, ordering, or duplicate protection. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram. The TCP provides reliable transport layer above the IP, and also a session layer (TCP socket). The key features that set TCP [145] apart from User Datagram Protocol:

three-way handshake

The presentation and application layers can be divided into two main groups:

simple byte-stream with a special packet structure,

markup language (e.g. XML) or other human-readable text format (e.g. JSON).

The first alternative is a modern, easy to handle solution which is primarily used in web-based communication systems. The advantages are the human-readability, the easy expandability and the off-the-shelf development tools. The main disadvantages are the verbosity and the unnecessary redundancy.

The byte-stream based protocols are widespread in Fleet Management Systems, because of the low-computing requirement and low amount of data. Nowadays the functions of the Fleet Management Systems are continuously expanding, thus the byte-stream based protocols become more difficult to handle by the developers and to integrate them into the modern web-based solutions.