tool for post-processing and analysis of 06/2017 recorded ... · which describes the procedure of...
Post on 16-Nov-2019
2 Views
Preview:
TRANSCRIPT
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)
Input parameter name
Label Unit Initial value
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
Description of a computer algorithm:
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)
Input parameter name
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
Description of a computer algorithm:
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)
Input parameter name
Label Unit Initial value
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
adjacent recorded data
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
Description of a computer algorithm:
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)
Input parameter name
Label Unit Initial value
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:
Max. acceleration vs velocity
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).
Max. acceleration vs road grade
LCDF,AG - 99
Max. velocity vs road grade
LCDF,VG - 99
X-axis resolutions:
Max. acceleration vs velocity
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).
Max. acceleration vs road grade
RAG [ᵒ] 0.5
Max. velocity vs road grade
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
Description of a computer algorithm:
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
Figure A6: Dubrovnik (Libertas) city bus lines 6 and 7
Page 62
Figure A7: Dubrovnik (Libertas) city bus lines 8 and 9
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
Figure B4: Timetable and stations of Žilina public bus line 21
(P.Chlmec-Budatín-Závodie-Bánová,colnica a späť)
Figure B5: Timetable and stations of Žilina public bus line 22
(Bytčica-Rajecká-Žel.st.-Budatín-Brodno a späť)
Page 66
Figure B6: Timetable and stations of Žilina public bus line 24
(Trnové-Rosinky-centrum-Strážov a späť)
Figure B7: Timetable and stations of Žilina public bus line 26
(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
Field name Field type Field description
CarID INT Unique number of the vehicle
MoveTime TIMESTAMP Time moment of sending data
MoveAlt REAL Altitude
MoveAccelMin REAL Minimum vehicle acceleration
MoveAccelMax REAL Maximum vehicle acceleration
CycleID INT Unique number of driving cycle
ClusterID INT Unique number of cluster
Table: Odometer
Field name Field type Field description
CarID INT Unique number of the vehicle
TotalTime TIMESTAMP Time moment of sending data
TotalKm INT Vehicle total distance travelled in
kilometers
Table: InterpolatedDataTime
Field name Field type Field description
CarID INT Unique number of the vehicle
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
CycleID INT Unique number of driving cycle
Table: InterpolatedDataDist
Field name Field type Field description
CarID INT Unique number of the vehicle
AbsTime REAL Absolute time (epoch time)
Dist REAL Vehicle distance traveled
Vel REAL Vehicle velocity
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
CycleID INT Unique number of driving cycle
Page 71
Table: AccelVelLimit
Field name Field type Field description
CarID INT Unique number of the vehicle
Vel REAL Vehicle velocity
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
colored area interval (for all a> 0)
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
colored area interval (for all a< 0)
Table: AccelGradeLimit
Field name Field type Field description
CarID INT Unique number of the vehicle
Grade REAL Road slope
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)
PolyPos REAL Value of the maximum acceleration for a
certain road slope (for all a> 0)
PolyNeg REAL Value of the maximum acceleration for a
certain road slope (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
colored area interval (for all a> 0)
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
colored area interval (for all a< 0)
Page 72
Table: VelGradeLimit
Field name Field type Field description
CarID INT Unique number of the vehicle
Grade REAL Road slope
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)
PolyPos REAL Value of the maximum acceleration for a
certain road slope (for all v> 0)
PolyNeg REAL Value of the maximum acceleration for a
certain road slope (for all v< 0)
ConfPosTop REAL Value of the upper boundary of the gray
colored area interval (for all v> 0)
ConfPosBtm REAL Value of the lower boundary of the gray
colored area interval (for all v> 0)
ConfNegTop REAL Value of the upper boundary of the gray
colored area interval (for all v< 0)
ConfNegBtm REAL Value of the lower boundary of the gray
colored area interval (for all v< 0)
Table: SyntheticCycles
Field name Field type Field description
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
CarID INT Unique number of the vehicle
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
traveling at constant speed
DeltaLMin REAL Minimum value of the traveled distance
between adjacent recorded data
DeltaLMax REAL Maximum value of the traveled distance
between adjacent recorded data
DeltaLMean REAL Mean value of the traveled distances
between adjacent recorded data
DeltaLStd REAL Standard deviation of the traveled
distances between adjacent recorded data
DeltaAltMin REAL Minimum value of difference in altitude
between adjacent recorded data
DeltaAltMax REAL Maximum value of difference in altitude
between adjacent recorded data
DeltaAltMean REAL Mean value of difference in altitudes
between adjacent recorded data
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
adjacent recorded data
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 name Field type
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
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
Page 75
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
traveling at constant speed
DeltaLMin REAL Minimum value of the traveled distance
between adjacent recorded data
DeltaLMax REAL Maximum value of the traveled distance
between adjacent recorded data
DeltaLMean REAL Mean value of the traveled distances
between adjacent recorded data
DeltaLStd REAL Standard deviation of the traveled
distances between adjacent recorded data
DeltaAltMin REAL Minimum value of difference in altitude
between adjacent recorded data
DeltaAltMax REAL Maximum value of difference in altitude
between adjacent recorded data
DeltaAltMean REAL Mean value of difference in altitudes
between adjacent recorded data
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
adjacent recorded data
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
Page 76
Table: SynCyclesStatistics
Field name Field type
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
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
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
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
traveling at constant speed
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
top related