Tool for post-processing and analysis of 06/2017 recorded ... · which describes the procedure of recording, collecting, post-processing and analysis of recorded driving cycles, while

D.T2.3.1

Tool for post-processing and analysis of

recorded driving cycles of city bus transport

Version 1

06/2017

WPT2

Innovative Tools to increase acceptability and effectiveness of low-carbon

mobility policies for city centers.

Activity A.T2.3

Development of models and ICT tool for planning of city bus transport

electrification.

Page 1

Table of Contents

1. INTRODUCTION ..................................................................................... 2

2. OVERVIEW OF THE BUS TRANSPORTATION SYSTEMS IN THE SOLEZ TARGET CITIES .................. 4

2.1. DRIVING ROUTES DATA RECORDING ............................................................... 4

2.2. DUBROVNIK (CROATIA) CITY BUS TRAFFIC SYSTEM ............................................... 6

2.3. ŽILINA (SLOVAK REPUBLIC) CITY BUS TRAFFIC SYSTEM .......................................... 11

3. SOFTWARE APPLICATION STRUCTURE .............................................................. 15

4. DATA PROCESSING MODULE (DPM) ................................................................ 17

4.1. INSERTING OF RECORDED DRIVING CYCLE DATA INTO DATABASE ................................. 18

4.2. ASSIGNMENT OF THE RECORDED DRIVING DATA TO THE DRIVING CYCLES ......................... 19

4.3. DATA INTERPOLATION .......................................................................... 24

4.4. CALCULATION OF VEHICLE PARKING TIME ....................................................... 30

4.5. CALCULATION OF BASIC STATISTICS ............................................................. 33

4.6. CALCULATION OF MAXIMUM VELOCITY AND ACCELERATION CURVES .............................. 38

5. DATA VISUALISATION MODULE ..................................................................... 44

5.1. PLOT EDITOR ................................................................................... 45

5.2. GENERAL STATISTICS ........................................................................... 47

5.3. VEHICLE ROUTES................................................................................ 49

5.4. LIMIT CURVES ................................................................................... 54

6. CONCLUSION ...................................................................................... 57

APPENDICES .......................................................................................... 59

Page 2

1. Introduction

Due to environmental concerns, there is a strong tendency of electrifying the existing

road transport system, which mainly relies on internal combustion engine (ICE)-based

propulsion technology. Battery electric vehicles (EV) are meant to be most viable

solution for the replacement of the ICE-propelled vehicles. Apart from reducing

pollutant and CO2 emissions, EVs are characterised by substantially reduced noise

pollution, lower operating costs (including energy and maintenance cost) and generally

better driving characteristics; while on the other hand, slow battery charging, limited

driving range, and higher investment cost inhibit their faster proliferation. In order to

encourage and accelerate replacement of conventional vehicle fleets with electric ones,

detailed techno-economic analyses comparing the conventional and EV fleets should be

conducted. A natural candidate for electrification relates to city bus fleets, aiming at

improvement in city air quality and reduction of noise. Since the city bus operation is

highly determined (i.e. known in advance) and intermittent, the range- and charging-

related issues may be overcome to a significant extent by combining fast charging at end

stations and slow charging in depot centre.

The SOLEZ work package WPT2.3 deals with models and related ICT tools for planning

the city bus transport electrification. The overall work is organised into four activities:

(i) post-processing and analysis of recorded driving cycles, (ii) developing and simulating

conventional and e-bus fleet models, (iii) e-bus fleet charging optimisation, and (iv)

techno-economic analysis. The subject of this report is activity (i) (i.e. Task 2.3.1),

which describes the procedure of recording, collecting, post-processing and analysis of

recorded driving cycles, while other activities are the subject of forthcoming project

reports.

First, all routes on which a conventional bus fleet operates should be analysed, and the

most relevant ones to be covered by EV buses (e.g. routes in city centres) should be

identified. Then, driving cycle data (e.g. vehicle velocities, GPS positions, elevation,

etc.) and powertrain data (e.g. engine speed and torque, gear ratio, wheel speed,

cumulative fuel consumption, vehicle mass, etc.) should be recorded and collected in

real time for the buses that operate on the selected routes, based on installation of a

GPS/GPRS tracking device to be built into conventional buses. In order to cover all

typical operations of the considered bus fleet, the driving data should be recorded over

24-hour time periods for characteristic days during a week (i.e. working and weekend

days), and for characteristic periods of a year (e.g. winter and summer seasons). Then,

the recorded driving data should be post-processed and analysed in order to reveal the

main characteristics of the considered fleet, with the aim to give first insights into the

possibilities and benefits of bus fleet electrification. The driving characteristics in terms

of traction capacity and drivability performance, which can be extracted from the

recorded data, should be posed as target specifications to be fulfilled by the e-bus fleet.

The post-processed driving cycles (velocity vs. time and road slope vs. travelled

distance) represent key inputs to be used in computer simulations of conventional and e-

Page 3

bus fleets, aimed at calculation of related operational costs and defining proper

charging system structure and management.

The emphasis of this report is on development of the software tool aimed at post-

processing and analysis of recorded driving data. The software tool functionality is

demonstrated by using the driving data recorded for the case of electric scooters

deployed on the roads of the SOLEZ target city of Dubrovnik, since there have been no

available recorded data for a city bus fleet at this stage yet. This is meant to be a

consistent approach because same driving data is planned to be recorded by using the

same tracking equipment for the real city bus fleets within the pilot studies to be

carried out in the next year of the project (under the work package WPT3.3).

The report is organised as follows. Section 2 describes the public bus transport systems

of SOLEZ target cities (the city of Dubrovnik, Croatia, and the city of Žilina, Slovakia),

and define the vehicle-tracking hardware equipment and driving data (signals) to be

recorded on conventional buses. Section 3 describes the architecture of the developed

software tool for post-processing and analysis of recorded driving data. Sections 4 and 5

describe the software tool modules related to the data processing and data visualisation

functionalities, respectively. Concluding remarks are given in Section 6.

Page 4

2. Overview of the bus transportation systems in the

SOLEZ target cities

2.1. Driving routes data recording

Methodology of recording the driving routes and taking measurements of relevant driving

parameters/variables for public-bus fleet is based on utilizing the telemetry electronic

tracking module (STM-Eagle unit, manufactured by Artronic, Croatia, see Fig. 1a), which

is equipped with GPS receiver, GPRS communication line and CAN communication with

vehicle powertrain. Tracking STM module requires 24V DC voltage power supply,

regularly available on buses. The GPS antenna needs to be mounted on the bus chassis.

The STM electronic module comprises embedded CAN interface that enables online

measurements of the relevant vehicle data, readily available on the vehicle CAN bus

(e.g. the engine speed and torque variables, transmission status information, traveled

distance, cumulative fuel consumption, etc.). The measured data is transmitted over

the GPRS communication line to the central fleet tracking server database located on a

dedicated centralized server or in a cloud (see Fig. 1b).

Figure 1: STM telemetry electronic tracking module a) and overview of the SkyTrack tracking

system b)

On-line measurements of the vehicle 3D coordinates in the local geodetic coordinate

frame enable reconstruction of the driving route configuration (including the road slope)

and calculation of the traveled distance. The vehicle horizontal velocity measurements

provide the key information about the driving cycle. The road grade can be

reconstructed from the rate of change in elevation (i.e. height over the sea level) as a

function of traveled distance. Velocity profiles, traveled distance, and road grades are

critical driving cycles parameters required for simulation and analysis of the

requirements regarding the electrification of transport.

The above mentioned tracking module has been successfully used by Artronic for

tracking a number of different fleets of conventional vehicles. It was utilized by the

UNIZAG team in the research related to a pilot study of the electric scooter sharing

system in Dubrovnik (GreenGo project; see photos shown in Fig. 2). The tracking data,

Page 5

specified in Table 1, were recorded on three electric scooters over the pilot period of

three months. Since this deliverable relates to development of software tool for data

post-processing and analysis, and the bus pilot is to be conducted within WPT3 starting

in 2018, the data collected on the electric scooters are employed in this report for

verification of the software tool. As same tracking module is anticipated to be used on

the city buses, the software tool will readily be adapted for the aimed pilot study

application. Most of the measured variables will remain the same, while those related to

electric vehicles (i.e. battery SoC, current, and voltage) will be replaced with the ones

relevant for the conventional vehicles (i.e. engine speed, torque, and cumulative fuel

consumption).

Figure 2: Electric scooter tracking system: STM-5 Eagle electronic module a), installed

tracking module with connections to scooter power supply and CAN bus system b),

placement of GPS antenna c), and Govecs S2.6 GO! electric scooter with installed tracking

equipment d)

Page 6

Table 1: STM tracking module measurement data on electric scooters

Data Period [ms] Resolution

Govecs (Artronic) Data sending mode

SoC [%] 1000 1 % (1 %) On change

Temperature [°C] 1000 0.1 °C (1 °C) Synchronized with SoC

data transmission (averaged value sent)

Current [A] 1000 0.0625 A (0.1 A) Synchronized with GPS

data transmission (averaged value sent)

Voltage [V] 1000 0.046 V (0.1 V)

Accelerator handle deflection [-]

1000 1/32767 = 3.52e-5

ECO mode ON 1000 -- On change

POWER ON 1000 -- On change

e-scooter speed (GPS) [km/h]

1000 (0.1 km/h) Standard package

(depends on transmission tariff

model)

XGPS [deg] -- (1e-7 deg)

YGPS [deg] --- (1e-7 deg)

Elevation [m] --- (0.1 m)

Traveled distance ODO [km]

1000 100 m (1 km) 1 km increment

2.2. Dubrovnik (Croatia) city bus traffic system

This section provides an overview of the public bus transport in the city of Dubrovnik

(Croatia), population of 42.600, including bus lines description, time-tables, and

information regarding the bus-operator fleet.

Dubrovnik public bus transport network, operated by Libertas, consists of 17 bus lines,

among which the major lines are: 1a, 1b, 2, 2a, 3, 3a, 4, 5, 6, 7, 8, 9, and 17. The

overview of the bus lines is given in Fig. 3, while the timetables and stops are listed in

Appendix A, in Figs. A2-A8.

The longest and most frequent bus lines are 1A, 1B, 3, 4, 6, and 8. Line 17 connects the

small village Bosanka, situated within the city urban area, on the slopes of the hill Srđ, 4

km away from the city center in the north-east direction.

Page 7

Figure 3: Dubrovnik (Libertas) city bus lines - overview

In Table 2 the operating hours, number of departures/arrivals per day, and bus

departure interval for all bus lines (1-17) are summarized. The largest number of buses

runs on line 6. In the summer period six buses runs simultaneously on the line 6, while

one remains in depot in case of need for reinforcement, while in the winter season this

number is reduced by half (i.e. 3 active buses plus one in depot). The highest number of

buses in the city public transport (i.e. up to 35 vehicles) is deployed during the summer

period, when the traffic is intensified due to the tourist season. Table 3 summarizes the

operating hours, number of round trips per day (No), and averaged bus departure rate (i)

for different lines, during working days, on Saturday, and on Sunday and public holidays.

Page 8

Table 2: Overview of the number of deployed buses per line in winter and summer period

Legend: Red. Br. No. Linija broj Line designator Naziv linije Line description Broj autobusa po liniji Number of buses per line Zima Winter

Ljeto Summer Pojačanja Reinforcements RD Working days SUB Saturday N. i BL. Sunday and Holidays

Table 3: Overview of operating hours, number of round trips per day (No), and averaged bus

departure rate (i) for bus lines

Legend: Red. Br. No. Linija broj Line designator Radni dan Working day

Subota Saturday Nedjelja I blagdan Sunday and Holidays Radno vrijemeOperating hours

Page 9

Libertas operator has a fleet of 117 buses (68 buses are utilized in urban area transport,

and 49 buses deployed in the suburban areas), as shown in Table 4. The buses in the

fleet are of different models and manufacturers, but the most common bus in a fleet,

deployed in urban transport is the Lion's City by MAN (32 vehicles in total, of which 16

have been manufactured in the period from 2007 to 2009, while the others have been

manufactured in the period from 2013 to 2016). Therefore, this model is most likely

candidate for recording the bus lines driving cycles (i.e. to be equipped with the

tracking measurement module).

Table 4: Dubrovnik (Libertas) public bus fleet

Type of bus Production

year Deployment Air conditioning

Number of vehicles

MAN SL 222 1996 1999

urban urban

no no

2 2

MAN SU 220 1981 1985 1988

urban urban urban

no no no

3 7 1

MAN SU 313 2004 2005 2007

suburban suburban suburban

no yes yes

2 10 3

MAN SL 263 2004 suburban no 5

MAN SL 283 2005 urban no 5

LION'S CITY 2007 2009 2013 2016

urban urban urban urban

yes yes yes yes

6 10 6 10

LION'S REGIO 2016 suburban yes 2

ISUZU 2002 2005 2007 2008 2012 2012 2015 2015

suburban suburban suburban suburban suburban

urban suburban

urban

yes yes yes yes yes yes yes yes

2 11 3 5 2 8 4 2

FORD TRANSIT 2002 2007 2008

urban urban urban

no yes yes

3 2 1

According to the information obtained from the Libertas representatives, each bus is

periodically switched to operate on all bus lines. Therefore, it is possible to cover all the

lines and record the required driving cycle measurements by utilizing only a few buses

equipped with the necessary tracking electronic modules. The minimal number of buses

required for the measurements, is yet to be determined, and it depends on duration of

this switching period and the available time for performing the measurements (e.g. if

lesser number of buses is to be equipped with measurement equipment in order to

minimize the costs, the measurement time will be increased). It is anticipated that at

least three buses will be equipped with the tracking module. Furthermore, according to

obtained information the ISUZU buses should be excluded from the consideration for

driving cycles measurement in this project (c.f. they operate mostly in suburban area).

Page 10

In order to make measurements on all road segments by which buses run, the driving

cycles should be measured on buses operated at least on lines 1A, 2, 3, 4, 6, 8, and 17.

Based on the information obtained from MAN, regarding the possibilities of the

connection of the third party measurement equipment to the bus CAN system, the

special interface A-CAN module that enables such connection should be installed on the

bus. By evaluating the available CAN data for aimed LION’S CITY bus model specified in

the operating manual1, the variables list in Table 5 has been defined as a relevant for

the planned pilot study.

The bus driving routes measurements are expected to be conducted as a part of the

pilot study in 2018 for the period of approximately 12 months, so both over winter and

summer season.

Table 5: Selected signals of MAN, LION’S CITY bus to be recorded from A-CAN bus system by

using FMS 1.0 and FMS 2.0 interconnection modules

A-CAN massages Description FMS

(1.0)

FMS

(2.0) Available data

Veh_distance X X

(1) High resolution total vehicle distance

[tot_veh_dist] - km;

(2) Daily kilometer counter (high resolution trip

distance) [trip_distance] - km;

Veh_weight

EBS/ECAS X X (1) Axle weight [axle_weight] – kg;

CCVS Cruise Control/

Vehicle speed X X

(1) [veh_speed_FFR] – km/h;

(2) [clutch_switch];

(3) [brake_switch];

EEC1 Electronic eng.

controller X X

(1) Actual engine torque [act_eng_torque] - %;

(2) Engine speed [engine_speed] – rpm;

Fuel_consumption X X (1) Total fuel used [total: fuel_used] – l;

Amb_Cond - X (1) Barometric pressure [barometric_press] – mbar;

(2) Ambient air temperature [amb_air_temp] - °C;

1 [1] MAN Guidelines to fitting bodies Truck: ZDR-KSM (Step2) Edition 2016 V1.0

Page 11

2.3. Žilina (Slovak Republic) city bus traffic system

This section provides an overview of the public bus transport in the city of Žilina (Slovak

Republic), population of 85.000, including bus lines description, time-tables, and

information regarding the bus-operator fleet.

Žilina public bus transport network, operated by DPMŽ s.r.o., consists of 8 trolleybus

lines (lines: 1, 3, 4, 5, 6, 7, 14, and 16) and 10 bus lines (lines: 20, 21, 22, 24, 26, 27,

29, 30, 31, and 67) during a day. The outline of the lines map is given in Fig. 4. The

single night bus line (line 50) operates from 11 p.m. until 5 a.m. (the line map is given in

Appendix B, in Fig. B2). DPMŽ operator has a fleet of 41 buses, of different

manufacturers and models. The most common bus model in a fleet is Karosa B952 (17

vehicles).

With regard to the public transport electrification goal, only conventional (Diesel) bus

lines are of interest for the analysis, because the trolleybuses are already electric. Thus,

only the bus time tables for those lines are given in Appendix B, in Figs. B3-B12.

The lines 21, 22, 24, and 26 are lines with highly frequent departures (over 20 and up

to 39, during the work days), while other lines are less frequent. Žilina city transport has

three operating regimes that correspond to: working days, holydays, and weekends as

well as public holydays. During the working days 32 buses are deployed in the public

city transport while during the holiday season 30 buses are running. Holiday season (for

year 2017) includes summer vacations from 3th July to 31th August, 30th and 31th

October, and winter holidays from 23th December to 5th January. On weekends and

public holydays only 9 buses are deployed.

Page 12

Figure 4: Žilina trolleybus and bus lines map

DPMŽ operator has a fleet of 41 Diesel buses, of different manufacturers and models, as

listed in Table 6. The most common bus model in the fleet is Karosa B952 (17 vehicles)

and Solaris Urbino 12 is second by number (5 vehicles).

Page 13

Table 6: Žilina (DPMŽ) public Diesel bus fleet

Type of bus Number of seats

Number of standings

Engine power [kW]

Number of vehicles

Solaris Urbino 12 33 65 204 5

Irisbus Citelis PU09D1 41 116 213 2

Irisbus Citelis Line PS09D2

41 55 213 1

Irisbus Citelis PS09D1 29 88 180 3

Renault City bus PS09D1 31 69 182 3

Karosa B961 46 122 213 3

Karosa B952 32 68 180 17

Karosa B932 32 63 175 4

Karosa B732 32 63 155 3

According to the information obtained from the bus operator, the buses mainly operate

on the designated bus line, but due to the average age of the buses they are

occasionally switched between the lines. Moreover, all diesel buses are equipped with

CAN interface what makes possible to gain data for a third party. Communication

protocol, data structure, and quantity of obtained driving parameters depend on the

given type of the bus. In the Karosa B952 model CAN interface is according to FMS 1.0

standard and in the case of Solaris Urbino 12 model CAN interface is according to FMS

2.0 standard (similar as in the case of MAN Lion City buses). In both buses CAN ports are

easily accessible and can be connected to the data logging device. Picture of

compartment with CAN ports in the Solaris Urbino 12 is given in the Fig. 5.

The vehicle parameters that are anticipated to be recorded from Karosa buses’ CAN bus

include: engine speed, engine torque, distance traveled, cumulative fuel consumption,

vehicle weight and ambient temperature. Additional information is expected to be

available for Solaris Urbino buses, and can include data specified in Table 5 for MAN Lion

City buses, because both buses comply with FMS 2.0 standard. Sampling time of CAN

parameters recording is anticipated to be internally 0.1 second, while the GPRS data

transfer will be based on the sampling time of 1 second. Other than CAN variables, data

logging device will also log the GPS variables such as vehicle absolute position and

vehicle velocity in the longitudinal direction with the sampling time of 1 second (see

Subsection 2.1).

It is worth noting that the board computer already installed on the buses records basic

driving related data and saves them in a text log file for the purpose of off-line analyses.

A sample of the data log file and the related list of recorded data variables are given in

Fig. 6. However, the CAN data is not available on on-board computer. Data processing of

the on-board computer file would require some effort due to somewhat unusual

formatting, but it can be carried out if necessary. However, it is anticipated that all

necessary data for the purpose of the bus route and driving parameters measurements

will be obtained from the tracking electronic module to be installed in the vehicle, i.e.

that the on-board computer recorded data would not be needed (they will mostly be

Page 14

redundant). Therefore, the software tool described in the next sections relates only to

post-processing of tracking module-collected data.

Figure 5: Compartment with CAN ports in the Solaris Urbino 12 bus

Figure 6: Onboard computer driving data recording: a) list of recorded data and

b) the example of the text log file

Page 15

3. Software application structure

The software application aimed for analysing the scenarios of replacing conventional

vehicle fleets with electric ones is planned to consist of the following tools: (i) DPPM

(Data Post-processing Module) tool for post-processing and analysis of recorded driving

cycles, (ii) EBSM (E-bus Simulation Module) tool for simulation of various bus models

(e.g. conventional, hybrid and electric ones), (iii) COM (Charging Optimisation Module)

tool for electric vehicle (EV) fleet charging optimisation, and (iv) TEAM (Techno-

Economic Analysis Module) tool for techno-economic analysis related to the replacement

of conventional vehicle fleet with electric one (see Fig. 7). The listed tools are organised

within the application as independent modules, achieving in this way the great flexibility

for upgrading the existing tools and adding new tools. DPPM module consists of two sub-

modules, one for data processing and one for data visualisation (DPM - Data Processing

Module and DVM - Data Visualisation Module); and a separate connection to the central

database (for the detailed description of the database tables see Appendix C).

Figure 7: Modular structure of the application

When launching the application, a main window, which offers the tool selection

functionality, starts as it is shown in Fig. 8. Further, by pressing one of the buttons (e.g.

"Run DPPM"), a new window related to the selected module is opened. The description

Module

described in

this report.

Page 16

of the respective module is shown in "Module Description" section by moving the mouse

over the button area. The fields which have a question mark ("Module Slot"), represent

empty slots where new tools can be added and thus integrated within the application (in

Fig. 8 only two empty slots are shown for the illustration purposes, while there is no

limitation on number of modules that can be added to application).

Figure 8: Application main window offering the tool selection functionality

The focus of this report is the DPPM tool whose processing- and visualisation-related

sub-modules are described in details in the sequel of this report, while the tools listed

under bullets (ii), (iii) and (iv) will be described in the following project reports

(D.T2.3.2, D.T2.3.3, D. T2.3.4).

Fields that

can be used

for future

application

extensions.

Page 17

4. Data processing module (DPM)

The DPM module aimed for recorded raw driving cycle data processing is a sub-module

of DPPM module defined in Section 3 under (i), which consists of the following elements:

• Control board – which guides an user through the entire procedure of data

manipulation and processing. The whole process is performed sequentially,

meaning that each operation shown can only be executed after the previous step

has been executed, starting from the loading of files that contain recorded

driving cycles data (see Fig. 9, left panel).

• Console log - a text field which displays status of the data processing along with

the errors and warnings that program encounters (see Fig. 9, right panel)

Figure 9: Graphical user interface (GUI) of the data processing module (control board on the

left, and console log on the right)

Each operation constains "Options" button that displays the dialog containing the

corresponding settings with the initial default set values. The current progression level

of the operation is graphically displayed by the progress bar located within the "Status"

section. A detailed sequence of operation executions ("step-by-step") is shown in Fig. 10.

Page 18

Figure 10: Sequential order of performing operations over recorded driving cycle data

4.1. Inserting of recorded driving cycle data into database

Pressing the "Browse" button opens the dialog for selection of files that contains

recorded driving cycles data in CSV format (see Fig. 11).

Figure 11: File load dialog along with the detailed process of insertion of recorded data into

database

Page 19

First, a selection of one or more desired files is needed, and followed with the click on

the "Open" button. Once the files are loaded, the status of the "File path" field will

change the value to the absolute path of the selected file (e.g. "C: \ ... \ input_file.csv")

or to "Multiple files selected ...", if multiple files are selected.

Then, by pressing the "Insert" button, the process of inserting the recorded driving cycle

data into database starts. By inserting the data, program checks validity of the files and

the existence of duplicate data within them, and in the case of invalid file format or

duplicated data displays the corresponding error or warning message in the "Console Log"

(see Fig. 12).

Figure 12: Messages printed into console during insertion of the recorded data into the

database

4.2. Assignment of the recorded driving data to the driving cycles

By pressing the "Detect Drive Cycles" button, the process of assigning the previously

recorded data to the driving cycles starts. The following criterium is taken for

completing of one driving cycle and starting another: the corresponding vehicle have to

be parked for a certain period of time at some predefined position (station/depot area).

The minimum parking time (supposed to be in seconds) is an input parameter which can

be set by user within the graphical user interface (see Table 7). Once the operation is

completed, an unique driving cycle number (CycleID) is assigned to each data record as

shown in Fig. 14.

Table 7: Input parameters of driving cycle detection algorithm on the side of the graphical

user interface (see Fig. 13)

Input parameter name

Label Unit Initial value

Description

Min. time at station Tstation,min [s] 600 Minimum parking time at station.

Page 20

Figure 13: The procedure of assigning the recorded data to the driving cycles along with the

corresponding settings

Figure 14: The example of recorded data shown along with the assigned driving cycle

numbers

Description of a computer algorithm:

The input data for the algorithm include the series of absolute times (epoch time2) and

the recorded geographical longitudes (GPS X-coordinates), from which the parking time

2 Unix time, or epoch, is simply said, the number of seconds passed since midnight on 1 January 1970 by UTC (Universal Time Code).

Page 21

intervals are obtained (due to the fact that vehicle stops sending data to the server

when turned off, see Fig. 15).

The algorithm works in such a way that by passing through the recorded vehicle data for

each point, recorded time and position (GPS-X coordinate), respectively, it first checks

whether the vehicle is within the radius of the depot, whose center is determined by

averaging all recorded GPS positions (see Eq. 1 and 2) for which the condition 𝑡(𝑘 + 1) −

𝑡(𝑘) > 10 ℎ is fulfilled, and determines the following:

• If an entrance into the depot zone is detected (vehicle is in the current k-th time

step located within the radius of the depot, and in the previous k−1 step it was

outside the radius (see Eq. 3), and the condition that the vehicle was turned off

for a certain time is met (𝑡(𝑘 + 1) − 𝑡(𝑘) > 𝑇𝑠𝑡𝑎𝑡𝑖𝑜𝑛,𝑚𝑖𝑛, necessary to penalize

cases in which the numerous vehicle entrances and exits from the zone are

detected in a relatively short time interval, which are caused by noise in the

recorded data), the vehicle arrival to the depot is registered.

• If an exit from the depot zone is detected (the vehicle in the current k-th step is

located outside the radius of the depot, and in the previous k−1 step it was within

the radius, see Eq. 4), and the condition that the vehicle did not stopped

immediately, but continued to drive is fulfilled (𝑡(𝑘 + 1) − 𝑡(𝑘) < 60 𝑠, necessary

to penalize the outliers, i.e. the cases in which the vehicle exits from the zone

for a couple of seconds were detected), the vehicle departure from the depot is

registered.

𝑋𝑆𝑇𝐴𝑇𝐼𝑂𝑁 =1

𝑁∑ 𝑋𝑖

𝑁

𝑖=1

; 𝑁 = 1, … , 𝑙𝑒𝑛𝑔𝑡ℎ(𝑋𝑖) (1)

𝑌𝑆𝑇𝐴𝑇𝐼𝑂𝑁 =1

𝑀∑ 𝑌𝑖

𝑀

𝑖=1

; 𝑀 = 1, … , 𝑙𝑒𝑛𝑔𝑡ℎ(𝑌𝑖) (2)

(𝑋𝐺𝑃𝑆(𝑘) − 𝑋𝑆𝑇𝐴𝑇𝐼𝑂𝑁)2 + (𝑌𝐺𝑃𝑆(𝑘) − 𝑌𝑆𝑇𝐴𝑇𝐼𝑂𝑁)2 ≤ 𝑅𝑆𝑇𝐴𝑇𝐼𝑂𝑁2 (3)

(𝑋𝐺𝑃𝑆(𝑘) − 𝑋𝑆𝑇𝐴𝑇𝐼𝑂𝑁)2 + (𝑌𝐺𝑃𝑆(𝑘) − 𝑌𝑆𝑇𝐴𝑇𝐼𝑂𝑁)2 > 𝑅𝑆𝑇𝐴𝑇𝐼𝑂𝑁2 (4)

Once the time instants of arrivals and departures from the depot for each vehicle are

determined, a unique cycle number (CycleID) is assigned to each data recorded within

these time intervals.

Page 22

Figure 15: Detected time instants of vehicle (CarID=1001541) arrivals and departures from

the depot for all associated driving cycles

Figure 16: Detected times and positions of vehicle (CarID=1001541) arrivals and departures

from the depot for one driving cycle (detail from the Fig. 15)

The time intervals in which the

vehicle has been turned off for a

long time are clearly visible by

reducing the recorded data to the

absolute time axis.

Vehicle departure

from the depot.

Vehicle arrival to

the depot.

There are many short intervals during which

the vehicle did not send any data between

the points of vehicle arrival and departure

from the depot. These intervals will be

further processed by the algorithm for

vehicle parking time detection at locations

outside of the depot.

Tparking

Page 23

Figure 17: Locations (GPS coordinates) of vehicle departures and arrivals at the depot

Figure 18: Trajectories of detected driving cycles

All points of vehicle arrival at the depot are within

the radius of the depot, while some of the

departure points are not strictly close to the depot

zone boundary. The possible explanation for this is

that the vehicle starts to send data after a certain

period of time after it is turned on.

Depot zone

Page 24

Figure 19: Detected driving cycles in time domain

4.3. Data interpolation

By pressing the "Interpolate Data" button, the data interpolation starts both in time and

travelled distance domains, and followed by insertion of the calculated data into the

database (see Figs. 20, 21 and 22). The input parameters defineable by user through the

graphical user interface are shown in Table 8.

Figure 20: The procedure of the recorded data interpolation along with the corresponding

settings

Page 25

Table 8: Input parameters of data interpolation algorithm on the side of the graphical user

interface (see Fig. 20)



Description

Interpolation type:

Linear - - - Interpolate data with the first order curve (initially set).

ZOH - - - Zero order hold.

Find Nearest - - - Nearest value.

Parameters for altitude filter:

Order nbutter,alt - 2 Order of Butterworth filter.

Cut-off frequency

ωbutter,alt - 0.01

Cut-off frequency of Butterworth filter (0 ≤ 𝜔𝑛 ≤ 1, where 1 is the Nyquist frequency, 𝜋/𝑇𝑠𝑎𝑚𝑝𝑙𝑒).

Parameters for road grade filter:

Road grade filter order

nbutter,grade - 2 Order of Butterworth filter.

Road grade filter cut-off

frequency ωbutter,grade - 0.01

Cut-off frequency of Butterworth filter (0 ≤ 𝜔𝑛 ≤ 1, where 1 is the Nyquist frequency, 𝜋/𝑇𝑠𝑎𝑚𝑝𝑙𝑒).

Parameters for outlier filter:

Number of elements

nOF,elem - 100

Number of vector elements whose sum of distances from the current point must be less than the defined threshold value vOF,tresh (see Appendix D).

Treshold value vOF,tresh - 100

Threshold value representing distance of the current point from the previous nOF,elem points (see Appendix D).

Page 26

Figure 21: Database table in which the data interpolated over time is stored

Figure 22: Database table in which the data interpolated over travelled distance is stored

(more details on the method of calculating the profile of travelled distance is given below)

Page 27


Interpolation of data in time domain is performed as follows: (i) all of the recorded data

contained inside database tables GPS1 and GPS2 (see Appendix C) is selected, (ii) for

each point in the table GPS1, the value of the altitude from the table GPS2 is

interpolated with respect to its recorded time instants.

Figure 23: Interpolated altitude, vehicle velocity and GPS X and Y positions in time domain

Interpolation of data in travelled distance domain is performed as follows (see Fig. 24):

• The start and end value of the vehicle total distance travelled are linearly

interpolated from the data recorded by the odometer (𝑑𝑜𝑑𝑜,𝑠𝑡𝑎𝑟𝑡 and 𝑑𝑜𝑑𝑜,𝑒𝑛𝑑) in

relation to the start and end times of its driving mission (𝑡𝑑𝑟𝑖𝑣𝑒,𝑠𝑡𝑎𝑟𝑡 and 𝑡𝑑𝑟𝑖𝑣𝑒,𝑒𝑛𝑑),

and the current value of the total distance travelled (𝑑𝑡𝑜𝑡𝑎𝑙) is set to 𝑑𝑜𝑑𝑜,𝑠𝑡𝑎𝑟𝑡.

• For each time interval 𝑡𝑘 recorded between two adjacent points measured with

odometer [𝑑𝑖𝑛𝑡,𝑠𝑡𝑎𝑟𝑡, 𝑑𝑖𝑛𝑡,𝑒𝑛𝑑], a vehicle travelled distance is calculated by

integrating velocity in time (𝑑𝑘 = 𝑑𝑘 + 𝑣𝑘 · 𝑡𝑘, 𝑘 = 1, 2, … , 𝑁), and its value is

added to the vector 𝒅𝑖𝑛𝑡 = [𝑑1, 𝑑2, … , 𝑑𝑁]. Once the end of the interval is detected

(for which respective distances are calculated), the vector that contains its

calculated distances 𝒅𝑖𝑛𝑡 is normed so that 𝑑𝑖𝑛𝑡,𝑠𝑡𝑎𝑟𝑡 and 𝑑𝑖𝑛𝑡,𝑒𝑛𝑑 are taken as

boundary values (see Eq. 5). This procedure results in a finer distribution profile

of the vehicle travelled distance (𝑑𝑖𝑛𝑡,𝑠𝑐𝑎𝑙𝑒𝑑) than that obtained with an odometer,

which is considered to be absolutely accurate, but with a relatively low resolution

of one kilometer.

𝑑𝑖𝑛𝑡,𝑠𝑐𝑎𝑙𝑒𝑑 =𝒅𝑖𝑛𝑡 − 𝑑𝑖𝑛𝑡,𝑠𝑡𝑎𝑟𝑡

(𝑚𝑎𝑥(𝒅𝑖𝑛𝑡) − 𝑑𝑖𝑛𝑡,𝑠𝑡𝑎𝑟𝑡)∙ (𝑑𝑖𝑛𝑡,𝑒𝑛𝑑 − 𝑑𝑖𝑛𝑡,𝑠𝑡𝑎𝑟𝑡) + 𝑑𝑖𝑛𝑡,𝑠𝑡𝑎𝑟𝑡 (5)

Values of position, altitude and

velocity are assigned to each time

instant (absolute time).

Page 28

• Once the normalized values of travelled distance for each discrete time moment

have been obtained, along with the corresponding altitude data and GPS X and Y

coordinates, the profile of travelled distance (𝒅𝑒𝑞 = [𝑑𝑒𝑞,1, 𝑑𝑒𝑞,2, … , 𝑑𝑒𝑞,𝑁]) with

equidistant intervals of 1 m is generated. Finally, for each value inside the

generated vector 𝒅𝑒𝑞, an altitude, velocity and time are linearly interpolated.

Figure 24: The method of scaling the travelled distance profile obtained by the integration

of the velocity in time with data measured with the odometer

Figure 25: Initial and final values of total travelled distance for each driving cycle of the

given vehicle (CarID=1001541) along with the values of travelled distances recorded with

the odometer

Values of travelled distances

for which the recorded GPS

data were invalid, and therefore

not taken into account (an

incorrect format of MoveTime

field was detected during

insertion of data into database).

Travelled distance

measured with odometer

[dint,start, dint,end]

Final value of the travelled distance of the

current interval is set as the starting point

for calculation of the travelled distance

profile of the next interval.

NEXT

INTERVAL

Page 29

Due to the large noise in recorded data, before calculation of the road slope profile, an

altitude was first filtered by an "outlier" filter (see Appendix D), and then by a low-pass

double-sided Butterworth second order filter. The road slope (𝛼) is then derived from

the filtered altitude (∆ℎ𝑓𝑖𝑙𝑡) and the difference in distance traveled between the two

points (Δd), and calculated as follows:

𝛼[%] = 100 ∙ tan (arcsin (∆ℎ𝑓𝑖𝑙𝑡

∆𝑑)). (6)

In order to reduce the noise in the resulting road slope profile, this signal is additionally

filtered by a lowpass double-sided Butterworth filter (𝛼𝑓𝑖𝑙𝑡). For the purpose of

validation of the 𝛼𝑓𝑖𝑙𝑡 road slope profile, an altitude profile ℎ𝑟𝑒𝑐𝑜𝑛𝑠𝑡𝑟 is reconstructed as

follows:

ℎ𝑟𝑒𝑐𝑜𝑛𝑠𝑡𝑟(𝑘) = ℎ𝑟𝑒𝑐𝑜𝑛𝑠𝑡𝑟(𝑘 − 1) + ∆𝑑(𝑘) ∙ (𝛼𝑓𝑖𝑙𝑡

100); k=1, 2,...,dim(∆𝑑) (7)

and is compared with the recorded signal. If the difference between the recorded and

reconstructed altitude signal is small, it can be concluded that the quality of the

reconstructed signal is satisfactory (see Fig. 28).

Figure 26: Interpolated and filtered altitude profiles in relation to the travelled distance for

all driving cycles of the given vehicle (CarID=1001541)

The outlier filter excluded all signals in which a

sudden jump in altitude was detected, as well as the

occurrence of strong oscillations in these locations

when filtering the curve with Butterworth filter.

The most evident transitions

are located at the edges of

the driving cycles.

Page 30

Figure 27: Interpolated and filtered road slope profiles in relation to the travelled distance

for all driving cycles of a given vehicle (CarID=1001541)

Figure 28: Recorded and reconstructed altitude profiles in relation to the travelled distance

for all driving cycles of the given vehicle (CarID=1001541)

4.4. Calculation of vehicle parking time

By pressing the button "Calculate Parking Data" the process of vehicle parking detection

starts (when, where and how long the vehicle has been being parked). Input parameters

on the side of the graphical user interface are given in Table 9. The output data of the

algorithm that is stored into database is shown in Fig. 30.

Due to the large differences in the altitude values between the

adjacent points after filtration, there are still severe jumps in road

slope profile becouse of the sensitivity of the harmonic functions

that are used in its calculation (especially arcsin).

Page 31

Table 9: Input parameters of vehicle parking detection algorithm on the side of the graphical

user interface (see Fig. 29)


Label Unit initial value

Description

Time treshold Tpark,min [s] 90 Vehicle minimum parking time.

Figure 29: The procedure for vehicle parking time calculation together with the

corresponding settings


The vehicle parking detection algorithm works as follows:

1. First of all, a vehicle parking start time instants (𝑡𝑝𝑎𝑟𝑘,𝑠𝑡𝑎𝑟𝑡) are determined, so

that all points for which condition 𝑡(𝑘 + 1) − 𝑡(𝑘) > 𝑇𝑝𝑎𝑟𝑘,𝑚𝑖𝑛 is equal to true are

extracted. Therefore, it is considered that the vehicle was parked if it was turned

off for more than in this case own chosen time interval of 𝑇𝑝𝑎𝑟𝑘,𝑚𝑖𝑛 = 90 𝑠.

2. Afterwards, for each detected starting point, the first next point for which

𝑡(𝑘 + 1) − 𝑡(𝑘) = 1 𝑠 equals true is sought, which is a necessary condition

indicating that the vehicle is currently in motion (vehicle is sending data to the

server in equidistant time intervals), and this point is proclaimed as end of

vehicle parking state (𝑡𝑝𝑎𝑟𝑘,𝑒𝑛𝑑).

3. Once the start and end points of the vehicle parking are defined, the parking

times are calculated as 𝑇𝑝𝑎𝑟𝑘𝑖𝑛𝑔 = 𝑡𝑝𝑎𝑟𝑘,𝑒𝑛𝑑 − 𝑡𝑝𝑎𝑟𝑘,𝑠𝑡𝑎𝑟𝑡.

Page 32

Figure 30: An database table that stores vehicle parking information

Figure 31: Detected vehicle parking start and end times (detail of one driving cycle)

Outliers that was avoided, which

would otherwise be proclaimed

as "fake" parking start/stop times.

Page 33

4.5. Calculation of basic statistics

By pressing the button "Calculate Basic Statistics", the process of calculating of basic

statistics for entire fleet, individual vehicles and their respective driving cycles starts,

followed by the subsequent insertion of the obtained results into the database. Input

parameters on the side of the graphical user interface are given in Table 10.

Table 10: Input parameters of the basic statistics calculation algorithm on the side of the

graphical user interface (see Fig. 32)



Description

Parameters for cumulative distribution filters:

Altitude treshold SCDF ,alt [%] 99

Threshold values in percentage for the altitude and road slope filters (denotes the amount of elements that would be taken into account during filtering of the input vector, for a detailed description see Appendix E).

Road grade

treshold SCDF,grade [%] 99

Parameters for vehicle number of stops detection:

Time bound -

lower Tmin,stop [s] 0 Time interval [Tmin,stop, Tmax,stop] which

indicates the minimum and maximum idle time of the vehicle that would be taken into account.

Time bound -

upper Tmax,stop [s] 30

Velocity bound -

lower vmin,stop [m/s] -0.1 Velocity interval [vmin,stop, vmax,stop]

which determines the velocity range for which is considered that vehicle has stopped (𝑣 ≈ 0).

Velocity bound -

upper vmax,stop [m/s] 0.1

Parameters for vehicle ide time detection:

Time bound -

lower Tmin,idle [s] 15 Time interval [Tmin,stop, Tmax,stop] which

indicates the minimum and maximum idle time of the vehicle that would be taken into account.

Time bound -

upper Tmax,idle [s] 60

Velocity bound -

lower vmin,idle [m/s] -0.1 Velocity interval [vmin,stop, vmax,stop]

which determines the velocity range for which is considered that vehicle is idle (𝑣 ≈ 0).

Velocity bound -

upper vmax,idle [m/s] 0.1

Parameters for vehicle ide time detection:

Velocity treshold ϵ [m/s] 0.1

The maximum deviation threshold for the absolute value of the difference between velocity vector maximum and minimum value (see Eq. 11).

Min. number of

points np,cruise - 5

The minimum number of points (elements) that the velocity vector must contain so that certain velocity interval can be declared constant.

Page 34

Figure 32: The process of basic statistics calculation together with corresponding settings

The output data of the algorithm is defined in the following table:

Table 11: Basic statistics data of individual driving cycles, vehicles and entire fleet (CarID=0)

Field name Field description

CarID / CycleID Unique number of vehicle or driving cycle

TravelDist1 [km] Total distance traveled measured with odometer

TravelDist2 [km] Total distance traveled calculated by integrating the

velocity in time

TravelDist3 [km] Total distance traveled obtained with haversin method for

calculation of distance between two points given in the form of longitude and latitude (see appendix F).

VelMin [m/s] Minimum recorded vehicle velocity

VelMax [m/s] Maximum recorded vehicle velocity

VelMean [m/s] Mean value of recorded vehicle velocities

VelStd [m/s] Standard deviation of recorded vehicle velocities

AccMin [m/s2] Minimum vehicle acceleration

AccMax [m/s2] Maximum vehicle acceleration

AccPozMean [m/s2] Mean value of vehicle positive accelerations

AccNegMean [m/s2] Mean value of vehicle negative accelerations

AccPozStd [m/s2] Standard deviation of vehicle positive accelerations

Page 35

AccNegStd [m/s2] Standard deviation of vehicle negative accelerations

AltMin [m] Minimum recorded altitude

AltMax [m] Maximum recorded altitude

AltMean [m] Mean value of recorded altitudes

AltStd [m] Standard deviation of recorded altitudes

NumStops [-] Number of vehicle stops

NumStopsPerKm [1/km] Number of vehicle stops per kilometer

IdleTime [s] Total time in which vehicle speed was zero

IdleTimePerc [%] Percentage of time in which the vehicle speed was zero

CruiseTime [s] Total amount of time the vehicle was traveling at constant

speed

CruiseTimePerc [%] Percentage of time the vehicle was traveling at constant

speed

DeltaLMin [m] Minimum value of the traveled distance between adjacent

recorded data

DeltaLMax [m] Maximum value of the traveled distance between adjacent

recorded data

DeltaLMean [m] Mean value of the traveled distances between adjacent

recorded data

DeltaLStd [m] Standard deviation of the traveled distances between

adjacent recorded data

DeltaAltMin [m] Minimum value of difference in altitude between adjacent

recorded data

DeltaAltMax [m] Maximum value of difference in altitude between adjacent

recorded data

DeltaAltMean [m] Mean value of difference in altitudes between adjacent

recorded data

DeltaAltStd [m] Standard deviation of difference in altitudes between


DeltaTMin [s] Minimum time value between adjacent recorded data

DeltaTMax [s] Maximum time value between adjacent recorded data

DeltaTMean [s] Mean value of times between adjacent recorded data

DeltaTStd [s] Standard deviation of times between adjacent recorded

data

ParkDurMin [s] Minimum value of vehicle parking time

ParkDurMax [s] Maximum value of vehicle parking time

ParkDurMean [s] Mean value of vehicle parking time

ParkDurPerc [s] The percentage of time the vehicle was parked

GradeMin [˚/100 m] Minimum value of road slope

GradeMax [˚/100 m] Maximum value of road slope

GradeMean [˚/100 m] Mean value of road slope

GradeStd [˚/100 m] Standard deviation of road slope

Page 36


A) Vehicle number of stops calculation

Algorithm works by first allocating all the time instants where the value of the vehicle

velocity was approximately equal to zero (𝑣 ≈ 0). After that, for each isolated time

moment, it checks whether in the previous time step 𝑡(𝑘 − 1) vehicle velocity was

greater than zero and whether the vehicle has stopped only briefly (𝑡(𝑘 + 1) − 𝑡(𝑘) <

𝑇𝑚𝑎𝑥,𝑠𝑡𝑜𝑝). If both conditions are fulfilled for a certain time instant, it is proclaimed as

vehicle stop point.

Total number of vehicle stops (𝑛𝑠𝑡𝑜𝑝𝑠) is calculated by incrementing the counter for each

time instant in which the above conditions were fulfilled. Number of vehicle stops per

kilometer is obtained by dividing the total number of vehicle stops (𝑛𝑠𝑡𝑜𝑝𝑠) with total

traveled distance (𝑑𝑡𝑜𝑡𝑎𝑙):

𝑛𝑠𝑡𝑜𝑝𝑠_𝑝𝑒𝑟_𝑘𝑚 =𝑛𝑠𝑡𝑜𝑝𝑠

𝑑𝑡𝑜𝑡𝑎𝑙[1/𝑘𝑚] (8)

Figure 33: Detected stop points for driving cycle no. 1 (detail)

B) Vehicle idle time calculation

Algorithm works by first allocating all the time instants where the value of the vehicle

velocity was approximately equal to zero (𝑣 ≈ 0). After that, for each isolated time

instant, it checks whether the vehicle stopped for a short time (𝑡(𝑘 + 1) − 𝑡(𝑘) <

𝑇𝑚𝑎𝑥,𝑖𝑑𝑙𝑒), eg. the vehicle was waiting at traffic lights. If the above condition is fulfilled

for the time moment 𝑡(𝑘), the time between that moment and the next recorded

𝑡(𝑘 + 1) is proclaimed as interval in which the vehicle was idling (∆𝑇𝑖𝑑𝑙𝑒,𝑘 = 𝑡(𝑘 + 1) −

𝑡(𝑘)).

Only those points where

vehicle stopped for a

short time were taken

into account.

Vehicle is parked

for a long time

Page 37

Total time in which the vehicle was in idle state (𝑇𝑖𝑑𝑙𝑒,𝑡𝑜𝑡𝑎𝑙) is calculated by summing all

of detected idle times (∆𝑇𝑖𝑑𝑙𝑒,𝑘) whose number is marked with N𝐼.

𝑇𝑖𝑑𝑙𝑒,𝑡𝑜𝑡𝑎𝑙 = ∑ ∆𝑇𝑖𝑑𝑙𝑒,𝑘

𝑁𝐼

𝑘=1

(9)

Percentage of time when vehicle was in idle state (𝑇𝑖𝑑𝑙𝑒,𝑝𝑒𝑟𝑐) is obtained by dividing the

vehicle total idle time (𝑇𝑖𝑑𝑙𝑒,𝑡𝑜𝑡𝑎𝑙) with total driving time (𝑇𝑑𝑟𝑖𝑣𝑒):

𝑇𝑖𝑑𝑙𝑒,𝑝𝑒𝑟𝑐 =𝑇𝑖𝑑𝑙𝑒,𝑡𝑜𝑡𝑎𝑙

𝑇𝑑𝑟𝑖𝑣𝑒[%] (10)

Figure 34: Detected times when the vehicle was idle for driving cycle no. 1 (detail)

C) Vehicle cruise time calculation

Algorithm for detection of intervals in which the vehicle is traveling at constant velocity

operates as follows:

• The first recorded velocity data is selected as the starting point (𝑣𝑠𝑡𝑎𝑟𝑡) and an

empty vector (𝒗𝑘), along with the vector which contains all recorded velocities

(𝒗𝑟𝑒𝑐) are initialized.

• Then, in each step 𝑘 = 1,2, … , 𝑙𝑒𝑛(𝒗𝑟𝑒𝑐) vector 𝒗𝑘 is filled with velocities (𝒗𝑘 =

[𝑣𝑠𝑡𝑎𝑟𝑡, … , 𝒗𝑟𝑒𝑐(𝑘)]) until the absolute value of the difference between the

maximum and the minimum velocity within it does not become larger than some

predefined values ε (see Eq. 11). Once the above condition is satisfied, along with

the condition that the vector 𝒗𝑘 contains minimum 𝑛𝑝,𝑐𝑟𝑢𝑖𝑠𝑒 elements (velocities),

∆Tidle,1 ∆Tidle,2

Page 38

the current velocity value is set as next starting point (𝑣𝑠𝑡𝑎𝑟𝑡 = 𝒗𝑟𝑒𝑐(𝑘)) while the

respective interval is declared as cruise interval (∆𝑇𝑐𝑟𝑢𝑖𝑠𝑒,𝑘).

|max(𝒗𝑘) − min(𝒗𝑘)| > 𝜖; 𝜖 ≪ (11)

Total vehicle driving time at constant speed (𝑇𝑐𝑟𝑢𝑖𝑠𝑒,𝑡𝑜𝑡𝑎𝑙) is calculated by summing all of

detected cruise times whose (∆𝑇𝑐𝑟𝑢𝑖𝑠𝑒,𝑘) number is marked with 𝑁𝐶.

𝑇𝑐𝑟𝑢𝑖𝑠𝑒,𝑡𝑜𝑡𝑎𝑙 = ∑ ∆𝑇𝑐𝑟𝑢𝑖𝑠𝑒,𝑘

𝑁𝐶

𝑘=1

(12)

Percentage of vehicle cruise time is obtained by dividing the total vehicle cruise time

(𝑇𝑐𝑟𝑢𝑖𝑠𝑒,𝑡𝑜𝑡𝑎𝑙) with total driving time (𝑇𝑑𝑟𝑖𝑣𝑒):

𝑇𝑖𝑑𝑙𝑒,𝑝𝑒𝑟𝑐 =𝑇𝑖𝑑𝑙𝑒,𝑡𝑜𝑡𝑎𝑙

𝑇𝑑𝑟𝑖𝑣𝑒[%] (13)

Figure 35: Detected time intervals in which the vehicle was traveling at a constant speed for

the driving cycle no. 1 (detail)

4.6. Calculation of maximum velocity and acceleration curves

Pressing the button "Calculate Limit Curves" starts the process of calculation of following

curves:

1. Maximum acceleration relative to velocity.

2. Maximum acceleration relative to road slope.

3. Maximum velocity relative to road slope.

∆Tcruise,1 ∆Tcruise,2

Page 39

Input parameters on the side of the graphical user interface are given in a Table 12.

Table 12: Input parameters of the limit curves calculation algorithm on the side of the

graphical user interface (see Fig. 36)



Description

Degrees of interpolation polynomials:

Max. acceleration vs velocity

npoly,AV - 4

Degrees of the interpolation polynomials for the respective curves.

Max. acceleration vs road grade

npoly,AG - 4

Max. velocity vs road grade

npoly,VG - 4

Parameters for cumulative distribution filters:


LCDF,AV - 99 Threshold values in percentage for the acceleration and road slope filters (denotes the amount of elements that would be taken into account during filtering of the input vector, for a detailed description see Appendix E).


LCDF,AG - 99


LCDF,VG - 99

X-axis resolutions:


RAV [km/h] 2.0 Resoulutions of velocity in km/h and road slope in ᵒ that determine the width of intervals for which the local maximums or minimums are calculated (depending on whether the lower or upper limit curve is concerned, see the description of the computer algorithm for a detailed explanation).


RAG [ᵒ] 0.5


RVG [ᵒ] 0.5

Output data of algorithm (see Fig. 37, 38, and 39) contains values of x-axis (velocities or

road slopes) in chosen resolution, values of local minima/maxima for given intervals,

values of interpolation polynomials in those points, and values of boundary points whose

determining method is given in the computer algorithm description section.

Page 40

Figure 36: The process of calculating the maximum velocity and acceleration curves along

with the corresponding settings

Figure 37: Table containing maximum acceleration vs road slope data

Page 41

Figure 38: Table containing maximum acceleration vs velocity data

Figure 39: Table containing maximum velocity vs road slope data

Page 42


Maximum acceleration vs vehicle velocity curve

Maximum acceleration curve in dependence on the velocity is obtained as follows:

• First, the vector of velocities with the selected resolution of 𝑅𝐴𝑉 = 2 𝑘𝑚/ℎ is

initialized (𝒗𝑎𝑟𝑟 = [𝑣𝑎𝑟𝑟,1 = 1, 𝑣𝑎𝑟𝑟,2 = 3, … , 𝑣𝑎𝑟𝑟,𝑛 = 𝑣𝑚𝑎𝑥]).

• After that, for each velocity interval 𝒗𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝑖 = [𝑣𝑎𝑟𝑟,𝑖 −𝑅𝐴𝑉

2, 𝑣𝑎𝑟𝑟,𝑖 +

𝑅𝐴𝑉

2] all of

corresponding accelerations 𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝑖 = [𝑎𝑚𝑖𝑛, … , 𝑎𝑚𝑎𝑥] are taken and sorted from

the least to the highest, and are further filtered with the cumulative distribution

filter with its treshold value set to 𝐿𝐶𝐷𝐹,𝐴𝑉 (all accelerations whose values deviate

significantly from the others are filtered, for detailed description see Appendix

E). Once a vector of filtered accelerations 𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝑓𝑖𝑙𝑡 is obtained for the current

interval, the required points are obtained by calculating its maximum or minimum

as follows:

𝒂𝑝𝑜𝑠,𝑚𝑎𝑥 = max (𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝑓𝑖𝑙𝑡, for each 𝑎 > 0) (14)

𝒂𝑛𝑒𝑔,𝑚𝑎𝑥 = min (𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝑓𝑖𝑙𝑡, for each 𝑎 < 0) (15)

This step also determines the upper and lower limit values of the maximum

acceleration intervals for a particular data filtering range (see Fig. 56, gray

colored area) as follows: (i) vector of accelerations 𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙 is passed through a

cumulative distribution filter with a threshold value of 𝐿𝑈𝐵 = 1.0 for the upper

bound (all accelerations are taken into account) and 𝐿𝐿𝐵 for the lower bound (see

Eq. 16), thus resulting in respective vectors of filtered accelerations 𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝑈𝐵 =

𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙 and 𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝐿𝐵; (ii) by calculating their maximum or minimum, the values

of upper and lower bounds are obtained (see Eq. 17-20 and Fig. 40).

𝐿𝐿𝐵 = 2𝐿𝐶𝐷𝐹,𝐴𝑉 − 1.0 (16)

𝒂𝑝𝑜𝑠,𝑈𝐵 = max (𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝑈𝐵, for all 𝑎 > 0) (17)

𝒂𝑝𝑜𝑠,𝐿𝐵 = max (𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝑈𝐵, for all 𝑎 > 0) (18)

𝒂𝑛𝑒𝑔,𝑈𝐵 = min (𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝐿𝐵, for all 𝑎 < 0) (19)

𝒂𝑛𝑒𝑔,𝐿𝐵 = min (𝒂𝑖𝑛𝑡𝑒𝑟𝑣𝑎𝑙,𝐿𝐵, for all 𝑎 < 0) (20)

• After 𝒂𝑝𝑜𝑠,𝑚𝑎𝑥 and 𝒂𝑛𝑒𝑔,𝑚𝑎𝑥 are determined for all velocity intervals, their values

are interpolated by polynomial (for positive and negative acceleration separately)

of desired order (𝑛𝑝𝑜𝑙𝑦,𝐴𝑉, initialy set to 4), thus resulting in top and bottom

curves of maximal acceleration in relation to velocity.

Page 43

Figure 40: An example of calculating the upper and lower limit values of the maximum

acceleration for one velocity interval using a cumulative distribution filter with 𝑳𝑪𝑫𝑭,𝑨𝑽 =

𝟎. 𝟗𝟗 (𝑳𝑳𝑩 = 𝟎. 𝟗𝟖, 𝑳𝑼𝑩 = 𝟏. 𝟎)

Remark: All other curves are obtained by the same procedure.

98 % accelerations

99 % accelerations

100 % accelerations

"gray zone" (see Fig. 56)

a

p

o

s

,

U

B

a

p

o

s

,

L

B

Page 44

5. Data visualisation module

Module for data visualisation DVM is a sub-module of DPPT module mentioned in Section

3 under (i). It is separated into four main sections necessary to display all relevant data

characteristics (see Fig. 41) that was previously stored into database with the help of

the data processing module (DPM).

Figure 41: Sections/tabs of the data visualisation module (DVM)

• Plot Editor: Allows the user to plot arbitrary diagrams by choosing the desired

data and settings. User can select any data that is stored inside associated

database.

• General Statistics: Containts bar diagrams of the most important statistical

features such as total distances traveled obtained by different methods, velocity

and acceleration characteristics, number of vehicle stops, etc.

• Vehicle Routes: Allows the user to display all routes (driving cycles) for the

selected vehicle along with the corresponding statistics in the tabular form. Also

contains the buttons that displays one of the following diagrams for the currently

selected vehicle or driving cycle:

1. Velocity vs Time

2. Acceleration vs Time

3. Distance vs Time

4. Altitude vs Distance

5. Road Grade vs Distance

• Limit Curves: Allows the user to display the following curves for the selected

vehicle or the entire fleet:

1. Maximal acceleration vs velocity

2. Maximal acceleration vs road grade

3. Maximal velocity vs road grade

4. Maximal acceleration vs velocity for grade interval [grademin, grademax]

Page 45

5.1. Plot editor

It consists of a toolbar that contains controls for adding and deleting line and bar

graphs, and of a central panel that includes all the added diagrams along with the

corresponding options (see Fig. 42). Detailed explanation of all controls is given in Table

13.

Table 13: List of all plot editor controls along with the corresponding description

Control name Control description

Add Line Chart Adds a line chart to the central panel.

Add Bar Chart Adds a bar chart to the central panel.

Clear All Deletes all diagrams contained in the central panel.

PLOT Draws the data selected inside the "OPTIONS" dialog.

CLEAR Deletes plotted data inside the corresponding graph.

DELETE Deletes the selected diagram (entire "graph panel").

OPTIONS Displays a dialog that contains all chart settings.

Figure 42: Plot editor structure

Diagrams

are added

vertically

one after

another.

Page 46

The following options are offered to the user (see Fig. 43) before plotting data:

• Car ID: selection of the desired vehicle or the entire fleet (option "ALL") for which

the data will be drawn.

• Cycle ID: selection of the desired driving cycle of the chosen vehicle (option is

enabled only if selected database table owns assigned numbers of the driving

cycle).

• Data Table: selection of desired database table (content of the "Data X-axis" and

the "Data Y-axis" dropdown menus is changed to corresponding field names during

table change).

• Data X-axis: desired x-axis data selection (eg. time).

• Data Y-axis: desired y-axis data selection (eg. vehicle velocity).

• Title: entry of desired graph title.

• Label X-axis: entry of desired x-axis label.

• Label Y-axis: entry of desired y-axis label.

• Range X-axis: range of a x-axis values that will be displayed (in the format [Xmin,

Xmax]).

• Range Y-axis: range of a y-axis values that will be displayed (in the format [Ymin,

Ymax]).

• Scale X-axis:x-axis scaling factor.

• Scale Y-axis:y-axis scaling factor.

• Legend Label: the label of the current plot in the legend of the graph.

• Grid: display the grid - YES or NO.

• Line Style: desired line style (solid, dashed, dashdot, dotted, etc.)

• Line Width: desired line width.

• Marker Style: desired marker style (pixel, triangle, diamond, square, star, etc.)

• Marker Size: desired marker size.

Page 47

Figure 43: Line chart settings

5.2. General statistics

A) Total distance traveled - An overview of total distance travelled for individual

vehicles and the entire fleet for all three methods of its calculation (Haversin,

integration of velocity in time, total distance traveled measured with odometer, see Fig.

44, left). For a detailed description of the calculation of distance between two points

using the Haversin method, see Appendix F.

B) Velocity characteristics - display of the velocity characteristics (vehicle maximum

velocity along with its mean value and standard deviation) for the individual vehicles

and the entire fleet (see Fig. 44, right).

C) Acceleration characteristics - display of the acceleration characteristics (vehicle

minimum and maximum accelerations, along with mean value and standard deviation of

positive and negative accelerations, separately) for the individual vehicles and the

entire fleet (see Fig. 45, right).

D) Number of stops per kilometer - display of the number of stops per kilometer for

each individual vehicle and the entire fleet (see Fig. 45, right).

E) Idle time percentage - display of the percentage of time the vehicle was idling for

individual vehicles and the entire fleet (see Fig. 46, left).

Page 48

F) Cruise time percentage - display of the percentage of time in which the vehicle

velocity was approximately constant for each vehicle and the entire fleet (see Fig. 46,

right).

By reviewing the characteristics of A-F, the fleet operator gains insight into the state of

the vehicle (total distance travelled can be an indicator for the necessary vehicle

service), driver characteristics (detection of driving at excessive speed and forcing of

the gas handle), and the traffic characteristics (a more intense number of vehicle stop

times and time intervals the vehicle was idling might point to driving in urban areas,

etc.).

Figure 44: Total distances traveled (left) and velocity characteristics (right) for individual

vehicles and entire fleet

Figure 45: Acceleration characteristics (left) and number of stops per kilometer (right) for

individual vehicles and entire fleet

Page 49

Figure 46: The percentage of idle time (left) and the percentage of time in which the vehicle

speed was approximately constant (right) for individual vehicles and the entire fleet

5.3. Vehicle routes

Within this section, the user is offered an overview of all traveled routes for the

selected vehicle and desired driving cycle (see Fig. 47). During selection of a desired

vehicle and a driving cycle, entire fleet can be selected (ie. all driving cycles), but no

legend will be drawn if there are more than fifteen of them.

Figure 47: Tab for vehicle routes visualisation and analysis

Page 50

By pressing the "PLOT" button, the route of the selected vehicle or the driving cycle is

plotted, along with the station/depot zones and the vehicle arrival and departure points

(see Figs. 47 and 48).

Figure 48: Display of a route (CycleID=2) along with a station/depot zone and vehicle

departure and arrival points (zoom)

Pressing the "SHOW CORRESPONDING STATISTICS" button opens a new window with a

tabular overview of all the statistical features for the selected vehicle, driving cycle or

the entire fleet (see Fig. 49).

Pressing the "Velocity vs Time", "Acceleration vs. Time", "Distance vs. Time" buttons

opens a new window that contains a graphical representation (plot) of the selected

feature. In the case of the "Altitude vs. Distance" and "Road Grade vs. Distance"

characteristics, their filtered values are also plotted (see Figs. 50-54). Figure 53 further

shows an altitude profile reconstructed from filtered profile of road slope

(𝑎𝑙𝑡𝑟𝑒𝑐𝑜𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑒𝑑, see Subsection 4.3, Eq. 7) so that the user gains insight into the quality

of data processing by filtering.

Page 51

Figure 49: Corresponding statistics of individual vehicle (CarID=1001541) and its associated

driving cycles

Figure 50: Window for graphical display of the vehicle velocity versus time

Page 52

Figure 51: Window for graphical display of the vehicle acceleration versus time

Figure 52: Window for graphical display of the vehicle total distance traveled versus time

Page 53

Figure 53: Window for graphical display of the altitude versus vehicle distance traveled

Figure 54: Window for graphical display of the road slope versus vehicle distance traveled

Page 54

5.4. Limit curves

Within this section, the user can view calculated curves of maximum acceleration and

velocity for individual vehicle or entire fleet. Each diagram consists of a cloud of

recorded points (either acceleration or velocity), and of the associated approximation

polynomials along with points of local maximum/minimum for each interval defined by

the selected resolution (Data Processing Module -> Calculate Limit Curves -> Options).

The approximation with a polynomial of a certain order is introduced in order to smooth

out the maximum acceleration curve that is represented by points of local maxima and

minima.

Plotting process consists of three major steps (see Fig. 55):

1. Selection of a vehicle for which curves would be plotted (select option "ALL" for

the entire fleet).

2. Entry of minimum and maximum values for road slope interval (necessary for

calculation of the vehicle maximum acceleration vs velocity curve for a certain

road slope interval).

3. Data plotting by pressing the button "PLOT".

Figure 55: Section for displaying of vehicle maximum velocity and acceleration curves

The resulting curves are shown in Figs. 56, 57, 58, 59. Gray colored area represents the

interval between boundary values whose method of calculation is shown and explained

Page 55

in detail in the description of a computer algorithm for calculation of vehicle maximum

acceleration vs velocity (see Subsection 4.6). Since the main curve is very close to the

lower boundary curve and relatively far from the upper curve, it can be concluded that

the main curve very well covers a large majority of dots, while it filters rare points that

deviate quite a bit from the majority of recorded points.

Figure 56: Maximum acceleration vs velocity curve for CarID=1001541

Figure 57: Maximum acceleration vs road slope curve for CarID=1001541

Page 56

Figure 58: Maximum velocity vs road slope curve for CarID=1001541

Figure 59: Maximum acceleration vs velocity curve for the given road slope interval

(CarID=1001541)

Page 57

6. Conclusion

In this report the developed software tool and related methodology for post-processing

and analysis of the recorded driving data has been described. Apart from the post-

processing and analysis tool itself, the hardware equipment and driving data to be

recorded have been defined, and the public bus transport systems of the city of

Dubrovnik and the city of Žilina have been overviewed.

The developed methodology is implemented through a Python-based software tool,

which is aimed to be one of the basic modules of a comprehensive software application

to be developed under the work package WPT2.3. The overall software application

architecture was designed to have a modular structure, in order to readily adopt new

software tools to be developed (those for simulations of conventional and e-bus fleets,

e-bus fleet charging management optimisations, and techno-economic analyses), where

a unique database is shared among different software tools. Furthermore, each software

tool is planned to consist of two basic sub-modules, the first one for data processing and

the second one for data visualisation.

The functionality of the developed software tool has been demonstrated by using the

driving data recorded for three electric scooters operating on roads of the city of

Dubrovnik. Since same data is planned to be recorded for the case of city buses, the

developed software tool can be readily adapted and used in the pilot studies of city bus

transport system electrification for the cities of Dubrovnik and Žilina in WPT3.3. In order

to deal with the missing GPS signals and the noise in the recorded data, the data

processing module includes options of outlier filtering, signals filtering, and signal

interpolation, whose parameters are set to be tuneable by users. The special focus is

given to the reconstruction and validation of the road grade signal profiles from the

recorded altitudes, because these profiles are of crucial importance from the

perspective of accurate bus fleet simulations, in addition to the vehicle velocity time

profiles that are directly recorded. The software tool outputs can be divided into three

groups: (i) signal profiles given in either time or travelled distance domain, (ii) driving

characteristics, and (iii) statistical indicators. The most important signals from the group

(i) include vehicle velocity and road grade profiles; the most relevant characteristics

from the group (ii) relate to maximum acceleration vs. velocity, maximum acceleration

vs. road grade, and maximum velocity vs. road grade characteristics; while the major

statistical indicators from the group (iii) include travelled distance, maximum and

average velocity, maximum and minimum and average acceleration, parking duration,

all given for each recorded driving cycle. The outputs from the group (i) are demanded

as inputs for the simulations of conventional and EV models; the outputs from the group

(ii) are intended to be used for choosing most appropriate electric vehicle configurations

considered to replace the conventional one, while being capable of providing the same

acceleration- and velocity-related performance; while the outputs from the group (iii)

can be used as the first indicators related to electrification of the considered fleet (e.g.

the travelled distance distribution can be an indicator for selecting an EV type capable

Page 58

of providing the observed range, parking duration can be an indicator for choosing an

appropriate charging method, e.g. slow or fast charging).

It should be emphasized that the methodology and the corresponding software tool

developed and described in this report are not strictly limited for the bus fleet-related

applications, but it may be used for any other conventional vehicle fleet considered to

be replaced by electric one (e.g city delivery fleet).

Page 59

Appendices

Appendix A

Dubrovnik city bus lines map and timetables

Figure A1: Dubrovnik (Libertas) city bus lines – overview

Page 60

Figure A2: Dubrovnik (Libertas) city bus lines 1A and 1B

Figure A3: Dubrovnik (Libertas) city bus lines 2 and 2A

Figure A4: Dubrovnik (Libertas) city bus lines 3 and 3A

Page 61

Figure A5: Dubrovnik (Libertas) city bus lines 4 and 5


Page 62


Figure A8: Dubrovnik (Libertas) city bus line 17

Page 63

Appendix B

Žilina city bus map and timetables

Figure B1. Žilina trolleybus and bus lines map

Page 64

Figure B2. Žilina night bus line map

Figure B3: Timetable and stations of Žilina public bus line 20

(Bytčica-Rajecká-Vlčince-Rajecká-Bytčica)

Page 65


(P.Chlmec-Budatín-Závodie-Bánová,colnica a späť)


(Bytčica-Rajecká-Žel.st.-Budatín-Brodno a späť)

Page 66


(Trnové-Rosinky-centrum-Strážov a späť)


(Kamenná-Závodie-centrum-Rosinská,VÚVT a späť)

Page 67

Figure B8: Timetable and stations of Žilina public bus line 27 (Hájik-centrum-Budatín-Zádubnie-Zástranie a späť)

Figure B9: Timetable and stations of Žilina public bus line 29 (Žilin. Lehota-Priemyselná-centrum-Budatín a späť)

Page 68

Figure B10: Timetable and stations of Žilina public bus line 30 (Vranie-Budatín-Žel. stanica-Žil. univerzita a späť)

Figure B11: Timetable and stations of Žilina public bus line 31 (Mojšová-Lúčka-centrum-Novýcintorín a späť)

Page 69

Figure B12: Timetable and stations of Žilina public bus line 67 (Hájik-Závodie-Hliny-Solinky-Vlčince-Vodnédielo a späť)

Appendix C

Database table definition

Table: GPS1

Field name Field type Field description

CarID INT Unique number of the vehicle

MoveTime TIMESTAMP Time moment of sending data

MoveX REAL Value of GPS-X coordinate

MoveY REAL Value of GPS-Y coordinate

MoveSpeed REAL Vehicle velocity

CycleID INT Unique number of driving cycle

ClusterID INT Unique number of cluster

Page 70

Table: GPS2



MoveTime TIMESTAMP Time moment of sending data

MoveAlt REAL Altitude

MoveAccelMin REAL Minimum vehicle acceleration

MoveAccelMax REAL Maximum vehicle acceleration


ClusterID INT Unique number of cluster

Table: Odometer



TotalTime TIMESTAMP Time moment of sending data

TotalKm INT Vehicle total distance travelled in

kilometers

Table: InterpolatedDataTime



AbsTime REAL Absolute time (epoch time)

gpsX REAL Value of GPS-X coordinate

gpsY REAL Value of GPS-Y coordinate

Vel REAL Vehicle velocity

Alt INT Altitude


Table: InterpolatedDataDist



AbsTime REAL Absolute time (epoch time)

Dist REAL Vehicle distance traveled


Acc REAL Vehicle acceleration

Alt REAL Altitude

Grade REAL Road slope

VelFilt REAL Filtered vehicle velocity

AccFilt REAL Filtered vehicle acceleration

AltFilt REAL Filtered altitude

GradeFilt REAL Filtered road slope


Page 71

Table: AccelVelLimit




AccPos REAL Value of the interpolation polynomial for a certain vehicle velocity (for all a> 0)

AccNeg REAL Value of the interpolation polynomial for a certain vehicle velocity (for all a< 0)

PolyPos REAL Value of the maximum acceleration for a

certain vehicle velocity (for all a> 0)

PolyNeg REAL Value of the maximum acceleration for a

certain vehicle velocity (for all a< 0)

ConfPosTop REAL Value of the upper boundary of the gray

colored area interval (for all a> 0)

ConfPosBtm REAL Value of the lower boundary of the gray


ConfNegTop REAL Value of the upper boundary of the gray

colored area interval (for all a< 0)

ConfNegBtm REAL Value of the lower boundary of the gray


Table: AccelGradeLimit




AccPos REAL Value of the interpolation polynomial for

a certain road slope (for all a> 0)

AccNeg REAL Value of the interpolation polynomial for

a certain road slope (for all a< 0)


certain road slope (for all a> 0)


certain road slope (for all a< 0)









Page 72

Table: VelGradeLimit




VelPos REAL Value of the interpolation polynomial for a certain vehicle velocity (for all v> 0)

VelNeg REAL Value of the interpolation polynomial for

a certain road slope (for all v< 0)


certain road slope (for all v> 0)


certain road slope (for all v< 0)


colored area interval (for all v> 0)


colored area interval (for all v> 0)


colored area interval (for all v< 0)


colored area interval (for all v< 0)

Table: SyntheticCycles


SynCycleID INT Unique number of the synthetic driving

cycle

ClusterID INT Unique number of the cluster

SynDist REAL Distance traveled

SynVel REAL Velocity

SynAcc REAL Acceleration

SynGrade REAL Road slope

Table: BasicStatisticsCars

Field name Field type

Field description


TravelDist1 REAL Total distance traveled measured with

odometer

TravelDist2 REAL Total distance traveled calculated by

integrating the velocity in time

TravelDist3 REAL

Total distance traveled obtained with haversin method for calculation of distance

between two points given in the form of longitude and latitude (see appendix F).

VelMin REAL Minimum recorded vehicle velocity

VelMax REAL Maximum recorded vehicle velocity

Page 73

VelMean REAL Mean value of recorded vehicle velocities

VelStd REAL Standard deviation of recorded vehicle

velocities

AccMin REAL Minimum vehicle acceleration

AccMax REAL Maximum vehicle acceleration

AccPozMean REAL Mean value of vehicle positive

accelerations

AccNegMean REAL Mean value of vehicle negative

accelerations

AccPozStd REAL Standard deviation of vehicle positive

accelerations

AccNegStd REAL Standard deviation of vehicle negative

accelerations

AltMin REAL Minimum recorded altitude

AltMax REAL Maximum recorded altitude

AltMean REAL Mean value of recorded altitudes

AltStd REAL Standard deviation of recorded altitudes

NumStops INT Number of vehicle stops

NumStopsPerKm REAL Number of vehicle stops per kilometer

IdleTime INT Total time in which vehicle speed was zero

IdleTimePerc REAL Percentage of time in which the vehicle

speed was zero

CruiseTime INT Total amount of time the vehicle was

traveling at constant speed

CruiseTimePerc REAL Percentage of time the vehicle was


DeltaLMin REAL Minimum value of the traveled distance

between adjacent recorded data

DeltaLMax REAL Maximum value of the traveled distance


DeltaLMean REAL Mean value of the traveled distances


DeltaLStd REAL Standard deviation of the traveled

distances between adjacent recorded data

DeltaAltMin REAL Minimum value of difference in altitude


DeltaAltMax REAL Maximum value of difference in altitude


DeltaAltMean REAL Mean value of difference in altitudes


DeltaAltStd REAL Standard deviation of difference in

altitudes between adjacent recorded data

DeltaTMin INT Minimum time value between adjacent

recorded data

DeltaTMax INT Maximum time value between adjacent

recorded data

Page 74

DeltaTMean REAL Mean value of times between adjacent

recorded data

DeltaTStd REAL Standard deviation of times between


ParkDurMin INT Minimum value of vehicle parking time

ParkDurMax INT Maximum value of vehicle parking time

ParkDurMean REAL Mean value of vehicle parking time

ParkDurPerc REAL The percentage of time the vehicle was

parked

GradeMin REAL Minimum value of road slope

GradeMax REAL Maximum value of road slope

GradeMean REAL Mean value of road slope

GradeStd REAL Standard deviation of road slope

Table: BasicStatisticsCycles


Field description

CycleID INT Unique number of the driving cycle

TravelDist1 REAL Total distance traveled measured with

odometer

TravelDist2 REAL Total distance traveled calculated by

integrating the velocity in time

TravelDist3 REAL

Total distance traveled obtained with haversin method for calculation of distance

between two points given in the form of longitude and latitude (see appendix F).

VelMin REAL Minimum recorded vehicle velocity

VelMax REAL Maximum recorded vehicle velocity

VelMean REAL Mean value of recorded vehicle velocities

VelStd REAL Standard deviation of recorded vehicle

velocities




accelerations


accelerations


accelerations


accelerations

AltMin REAL Minimum recorded altitude

AltMax REAL Maximum recorded altitude

AltMean REAL Mean value of recorded altitudes

Page 75

AltStd REAL Standard deviation of recorded altitudes





speed was zero





DeltaLMin REAL Minimum value of the traveled distance


DeltaLMax REAL Maximum value of the traveled distance


DeltaLMean REAL Mean value of the traveled distances


DeltaLStd REAL Standard deviation of the traveled

distances between adjacent recorded data

DeltaAltMin REAL Minimum value of difference in altitude


DeltaAltMax REAL Maximum value of difference in altitude


DeltaAltMean REAL Mean value of difference in altitudes


DeltaAltStd REAL Standard deviation of difference in

altitudes between adjacent recorded data

DeltaTMin INT Minimum time value between adjacent

recorded data

DeltaTMax INT Maximum time value between adjacent

recorded data

DeltaTMean REAL Mean value of times between adjacent

recorded data

DeltaTStd REAL Standard deviation of times between


ParkDurMin INT Minimum value of vehicle parking time

ParkDurMax INT Maximum value of vehicle parking time

ParkDurMean REAL Mean value of vehicle parking time

ParkDurPerc REAL The percentage of time the vehicle was

parked





Page 76

Table: SynCyclesStatistics


Field description

SynCycleID INT Unique number of the synthetic driving

cycle

ClusterID INT Unique number of the cluster

TravelDist REAL Total distance travelled calculated by

integrating velocity in time

VelMin REAL Minimum vehicle velocity

VelMax REAL Maximum vehicle velocity

VelMean REAL Mean value of vehicle velocities

VelStd REAL Standard deviation of vehicle velocities




accelerations


accelerations


accelerations


accelerations









speed was zero





Page 77

Appendix D

Outlier filter algorithm

Let 𝒗𝑥 and 𝒗𝑦 be the input vectors that contain the x and y axis values of the curve

which is to be filtered:

𝒗𝑥 = [𝑥1, 𝑥2, … , 𝑥𝑛], (21)

𝒗𝑦 = [𝑦1, 𝑦2, … , 𝑦𝑚], (22)

where n and m represent the number of points contained within the vectors 𝒗𝑥 and 𝒗𝑦.

The filter passes through each point 𝑥𝑖 , 𝑖 = 1,2, … , 𝑛 of the vector 𝒗𝑥 and takes a value 𝑦𝑖

along with 𝑛𝑂𝐹,𝑒𝑙𝑒𝑚 (see Table 8) preceding points (elements) of vector 𝒗𝑦, thus

generating vector 𝒗𝑖𝑛𝑡 = [𝑦𝑖−𝑛𝑂𝐹,𝑒𝑙𝑒𝑚, … , 𝑦𝑖]. Afterwards, it checks whether the sum of

absolute values of the distances of the current point𝑦𝑖 from the all others contained

within the vector 𝒗𝑖𝑛𝑡 is less than some specified threshold value vOF,tresh (see Eq. 23). If

this condition is not met, point (𝑥𝑖 , 𝑦𝑖) is declared as a outlier and is not added to the

vector of filtered values 𝒗𝑓𝑖𝑙𝑡.

∑ |(𝒗𝑖𝑛𝑡,𝑘 − 𝑦𝑖)| <

nOF,elem

k=1

vOF,tresh (23)

Figure D1: Results obtained by filtering the altitude profile with the outlier filter

All points whose values deviate significantly

from the others are filtered (filtering strength

depends on the parameter vOF,tresh).

Page 78

Appendix E

Cumulative distribution filter

The cumulative distribution filter algorithm works as follows:

i. Input vector 𝒗 = [𝑣1, 𝑣2, … , 𝑣𝑛] is partitioned into intervals with a resolution of 0.1,

thus generating vector 𝒗𝑥 = [𝑣𝑥,1 = min(𝒗) , 𝑣𝑥,2 = min(𝒗) + 0.1, … , 𝑣𝑥,𝑚 = max (𝒗)].

ii. An empty vector 𝒗𝑛𝑜𝑟𝑚 whose dimension is equal to 𝒗𝑥 is initalized.

iii. For each value contained within vector 𝒗𝑥,𝑖, 𝑖 = 1, 2, … , 𝑚, an vector 𝒗𝐶𝐷,𝑖 =

[𝑣𝐶𝐷,𝑖,1, 𝑣𝐶𝐷,𝑖,2, … , 𝑣𝐶𝐷,𝑖,𝑘] which contains all elements of vector 𝒗 whose values are

less than or equal to 𝒗𝑥,𝑖 is generated. Afterwards, the contribution of elements

(𝑁𝑖) contained within vector 𝒗 which are less than equal to value 𝒗𝑥,𝑖 is obtained

by norming the number of elements contained within vector 𝒗𝐶𝑆,𝑖 with the number

of elements contained within vector 𝒗, and is added to a vector of normed values

𝒗𝑛𝑜𝑟𝑚.

𝑁𝑖 =𝑁𝐶𝐷,𝑖

𝑁𝑡𝑜𝑡𝑎𝑙=

𝑙𝑒𝑛(𝒗𝐶𝐷,𝑖)

𝑙𝑒𝑛(𝒗) (24)

iv. All elements contained within vector 𝒗𝑛𝑜𝑟𝑚 whose value is smaller than or equal

to a specified threshold value V𝑡𝑟𝑒𝑠ℎ𝑜𝑙𝑑 (initially set to 0.99, see Tables 10 and 12,

and Figs. 32 and 36 - Parameters for cumulative distribution filters) are

extracted, and the threshold value V𝑡𝑟𝑒𝑠ℎ,𝑖𝑛𝑝𝑢𝑡 for the elements within the input

vector 𝒗 is determined.

v. All elements contained within vector 𝒗 whose value is smaller than or equal to a

previously calculated threshold value V𝑡𝑟𝑒𝑠ℎ,𝑖𝑛𝑝𝑢𝑡 are taken as resulting filtered

values (see Fig. E1). In this way, all points that rarely occurs (mostly caused by a

measurement error) are filtered.

Page 79

Figure E1: Example of acceleration histogram (a), and the cumulative normed histogram (b)

for vehicle 1001541

Appendix F

Haversin method for calculation of distance between two points

It is based on the spherical shape of the Earth (ignoring the ellipsoidal effects), which

gives enough accurate results in most cases. In fact, the Earth is very mildly ellipsoidal

and the use of a spherical model usually gives errors up to 0.3%.

For calculation of the distance between two points (d), the following formulas uses an

effective earth radius (R) whose approximate value is 6378,137 km. Also, φ denotes

latitude, and λ longitude.

𝑎 = 𝑠𝑖𝑛2 (∆𝜑

2) + cos 𝜑1 ∙ cos 𝜑2 ∙ 𝑠𝑖𝑛2 (

∆𝜆

2) (25)

𝑐 = 2 ∙ atan2(√𝑎, √1 − 𝑎) (26)

𝑑 = 𝑅 ∙ 𝑐 (27)

where c represents angular distance in radians, d distance between two points, and a is

the square of half the chord length between the points.

All values of the input vector whose values of the

normed cumulative distribution is smaller or equal to

the specified threshold of vtreshold = 0.99 are taken

into account.

Values declared as outliers (mostly caused

by a measurement error).

Vtreshold = 0.99

Vtresh,input

Documents

Tool for post-processing and analysis of 06/2017 recorded ... · which describes the procedure of recording, collecting, post-processing and analysis of recorded driving cycles, while