CHAPTER 3

DRIVING FEATURES ABSTRACTION

Naturalistic driving data experiment represents real-time driving data collected under
naturalistic conditions. Drivers under naturalistic experiment drive their vehicles as per their
travel habits and preferences. These scenarios, thus, will include traveling data on various
road types under different traffic congestion. Vehicles, nowadays, are often instrumented
with devices such as On-board Diagnostic (OBD) to capture integrated driving data from
vehicles. Driving data collected via OBDs is to be understood and correlated with
environmental context for appropriate inferencing and features abstraction.
In this Chapter, analysis of dataset for problem domain is done to assess how it can be pre-
processed to be fed as input to machine learning based advanced computational models. It
also elaborates how driving behaviour can be correlated with environmental context to make
meaningful inference of data. Section 3.1 discusses factors and types of models considered
for driving data collection. Section 3.2 explains the overall process of driving feature
abstraction. Section 3.3 details various types of sensors fitted in vehicles that help in driving
data collection. Section 3.4 explains about dataset and data pre-processing steps. It also maps
features to different source sensors from which data is collected and elaborates how
environmental context is defined and how driving data is mapped to environmental context.
Section 3.5 summarises the Chapter.

3.1 Models for driving features extraction

Data extraction models from OBD devices can be classified based on transparency and data
scale. In this Section, pros and cons of different models based on computational transparency
have been discussed. Different types of models based on data granularity or scale are also
elaborated.
Models based on transparency
a. White-box models
White-box models are based on physical or mathematical theory based assumptions and
underlying specifications of systems such as vehicle’s engine specification. Few models are
data-driven and require a good understanding of working of mechanical components of
connected vehicles. For example, the vehicle longitudinal model describes various forces
acting on the vehicle which affects the longitudinal movement of the vehicle and specifies

33
vehicle dynamics affecting forward motion [2][7][20]. Forces that resist the vehicle’s
movement in a forward direction are shown with downward arrows in Figure 3.1. It includes
aerodynamic forces, front and rear tire rolling resistance and gravitational forces due to road
inclination. Forces that help in vehicle’s forward movement i.e., vehicle traction force which
causes front and rear wheels to rotate and move in a forward direction are indicated via
upwards arrows in Figure 3.1. As per Newton’s second law, vehicle forward movement can
be described by Equation 3.1 where ‘m’ is mass of the vehicle and ‘a’ is acceleration of the
vehicle, Ft, Fa, Fg, Fr are traction, aerodynamic, gravitational, and rolling resistance forces
respectively. Traction force causes front and rear wheels to apply rotational forces as
specified in Equation 3.2, where FrotF and FrotR are wheel rotational forces for front wheels
and rear wheels respectively.
= + + (3.1)
=( + ) (3.2)

Figure 3.1: Vehicle Longitudinal Model – Physical Model

Vehicle longitudinal models find out how much power is required to move a vehicle
forward with a certain vehicle velocity and acceleration and generate required torque by
engine [2][20][28][33][34]. Power demand for vehicles keeps changing according to
driving behaviour such as vehicle’s acceleration or deceleration. Furthermore, increased
power requirement results in increased fuel consumption. Hence, driving behaviour is not
only linked with vehicle driving safety but also with fuel economy.
Drawbacks of physical models include extensive computation involved in estimating
energy required to move vehicles forward on real time data. Most of these models require
accurate estimation for vehicle specific and other physical parameters such as vehicle’s
mass, acceleration.

34
 b. Black-box models
Black-box models do not include any computational or logical details about underlying
processing. These models process inputs to generate output without understanding the
theoretical background or computation involved. They normally require training of
models using large amounts of data and might suffer from model overfitting if
representative data is not sampled. Statistical models and machine learning approaches
come under this category. This type of model includes machine learning based models
that map inputs such as engine speed, acceleration, speed, deceleration to either fuel
consumption or driving risk. One example is detection of six driving patterns using
acceleration/orientation data by applying SVM [25]. Neural networks, support vector
machine, random forest and decision tree are some of machine learning based black-box
models applied to vehicular data analysis domain.
c. Grey-box models
Grey-box models include partial details about the concerned system model. They
combine experimental quantitative data with underlying qualitative system models.
Artificial intelligence-based models are examples of grey-box models which utilize
current data as well as underlying contextual knowledge. Fuzzy logic based soft
computing models for driving risk analysis come under the grey-box model that is
intuitive rather than a complete black-box or white-box model [25].
Models based on data granularity
Driving models can be classified into three different types based on granularity of data being
considered as follows: -
Microscopic models deal with time series based information of data gathered at
fixed interval, such as vehicle speed, and acceleration per second. Models
considering microscopic data are computationally extensive. Vehicle specific models
that derive emission rate and fuel consumption by analysing the various parameters
received at frequency of 1 HZ are examples of microscopic models. Instantaneous
fuel consumption using LSTM presented in [7] is a microscopic approach as per
second data has been considered.
Macroscopic models consider average values of different attributes of data across a
larger period such as considering average value of fuel consumed for a trip. These
types of models work on aggregated data and cannot be used to predict the accurate

35
 value of a variable in real time. These are mostly suitable for long-term analysis done
for driver profiling based approaches[13][15-16][24][28][34][36-37]. The
approaches which calculate fuel consumption considering average values of speed
and acceleration would be referred to as macroscopic models [34] [36-37].
Mesoscopic models combine the advantages for microscopic and macroscopic
models. These models take appropriately scaled data that is not as resource intensive
as microscopic data and is not as coarse-grained as macroscopic models considering
just average values. Mesoscopic models provide accuracy of model by using
appropriate scale of data.
There can be different combinations of models based on transparency and granularity. For
example, a white box model can be microscopic, macroscopic, or mesoscopic based on level
of granularity. Similarly, a microscopic model can be black-box model, for example, neural
networks processing time series data for every second are examples of microscopic black-
box models.
As part of proposed work, a mesoscopic model has been developed where the model
processes aggregated data at a lesser frequency instead of processing data at every second.
The proposed work makes use of mixed approaches, grey-box models based on artificial
intelligence and mixed Bayesian Nash equilibrium gaming and black-box models based on
machine learning and deep learning computational models.

3.2 In-vehicle sensors, OBD, controller area network in a connected car

Telematics in the automotive domain is a technology that enables communication from
sensor to vehicle and vehicle to infrastructure via wireless or GPS-based communication
mechanisms.
Table 3.1: In-Vehicle Sensors for Connected Cars

Sr # Type of Sensor Description

S-1 Global Navigation Satellite Captures accurate latitude/longitude of vehicle via Global position
System (GNSS) System (GPS) satellite

S-2 Wheel odometry sensors Tracks wheel’s speed and distance travelled by vehicle is reflected
in odometer reading.

S-3 Throttle pressure sensor Monitors the throttle opening rate and its relative position. It is
located on spindle/shaft to monitor the position of the throttle.

S-4 IMU - Gyroscope Measures angular velocity in degrees per second.

36
 S-5 IMU - Accelerometer Measures vehicle acceleration displacement vector in x, y, and z
directions

S-6 IMU - Magnetometer Measures magnetic field strength on each axis to detect heading

S-9 Fuel level sensor Measures level of fuel in tank by monitoring movement of float.

There are multiple types of sensors used in connected cars to gather various types of data
related to location, direction of movement, lateral/angular speed, lateral/angular acceleration
or deceleration, and throttle paddle statistics, as mentioned in Table 3.1. Controller Area
Network (CAN) is a high-speed bus protocol to broadcast all the traffic to all nodes on a
given bus. OBD (On-board Diagnostics) is a device that connects to the car's OBD-II
connector and gets access to values from Electronic Control Units (ECUs) and different
sensors such as Global Position System(GPS), General Packet Radio Service(GPRS) via
Controller Area Network (CAN). CAN bus helps to broadcast sensor measured values for
vehicle’s location, speed, engine RPM, fuel level to ECUs and OBD logger. Initially, the use
of OBD devices was limited to the vehicle’s health diagnosis and reporting any malfunction
indicator. OBDs retrieve raw data gathered by electronic control units by connecting to
CAN.

OBD
IMU
TPS

Fuel Level Sensor

Wheel Odometry Sensors

Figure 3.2: In-Vehicle Sensor Placement

In Figure 3.2, different in-vehicle sensors that may be installed in a connected vehicle are
shown.
Global Navigation Satellite System (GNSS)

37
 Global Navigation Satellite System provides accurate vehicle location via Global
position System (GPS) satellite. Accuracy of location mentioned by GNSS system may
get affected by signals being obstructed by monumental buildings and mountains. If the
GPS signal is unavailable, then the previous location, acceleration, and direction value
are utilized to compute the estimated current vehicle’s location.
Wheel Odometry
Wheel odometry sensors track the wheel’s speed, and distance travelled by vehicle is
reflected in odometer reading.
Throttle Pressure sensor
The throttle pressure sensor measures the throttle opening rate and its relative position.
The position of the accelerometer pedal is sent to the engine control unit for controlling
the power supplied to it.
Inertial Measurement Unit (IMU) - accelerometer, gyroscope, magnetometer
IMU combines multiple outputs from accelerometer, gyroscope and magnetometer and
tracks the movement and angular orientation of the vehicle. The accelerometer embedded
in IMU, measures vehicle acceleration displacement vector in x, y, and z directions.
Gyroscope measures angular velocity in degrees per second. The magnetometer measures
magnetic field strength on each axis and helps to detect heading.
Fuel Level Sensor
It measures fuel-level in the fuel tank by combining value received from fuel level sensor
with GPS values and helps to calibrate fuel consumed within each sampling time.

3.3 Dataset used in current study

For the studies carried out in this thesis, anonymized representative data for hatchback cars
are gathered from multiple sources. One of them is a private dataset provided by one of
companies that deals with fitting OBD into vehicles and is under non-disclosure agreement.
For easy reference, this private dataset is referred to as ‘Dataset A’.
Table 3.2: Dataset Statistics – Dataset ‘A’

Trip % of trips Average Maximum Average Duration in % Night

Category Distance Speed in Speed in hours Trips
based on (Kilometres) KMPH KMPH
Kilometres
driven

< 100 37% 25 100 25 1 57%

38
 100-200 26% 126 106 25 5.6 40%

> 200 37% 275 108 46.5 5.9 28.50%

Some statistics of ‘Dataset A’ is described in Table 3.2 as per broad categories based on the
distance covered, average trip distance, maximum speed, average speed, average duration in
hours and average percentage of trips during the night. The dataset includes trips to highways
as well urban areas across multiple cities within different time ranges.
Sample value of raw data that includes timestamp, latitude, longitude, altitude, direction
from GPS, Fuel Level, throttle position percentage, gyroscope, and accelerometer readings
for few samples of data as shown in Figure 3.3.

Figure 3.3: Snapshot of Raw Data as in Dataset-A

Other attributes such as road type, congestion information and time of travel are derived by
analysing the timestamp information and Lat/Long information using Here map API as
explained in step iii of Section 3.4. The details about driving behaviour events identification
have been elaborated in Chapter 5, Section 5.3.3.
Table 3.3: Dataset Statistics – Dataset ‘B’
Attribute Description Range & units
Fuel_consumption It provided instantaneous value for fuel 0-10000, cubic millimeter (mcc)
consumed.
Throttle_position It provided throttle relative position. 1-100, percentage
Engine_speed It specified the number of revolutions per minute 0-6253 RPM
by engine.
Vehicle_speed It represented the current vehicle speed of the 0-130 KM/Hour
vehicle
Acceleration_X Acceleration of vehicle in longitudinal direction -10 to 8.1 m/s2
Acceleration_Y Acceleration of vehicle in longitudinal direction -10 to 8.1 m/s2
DriverID Identification of driver “A” to “J”
PathOrder Order of path from source to destination 1 – University to stadium
2 – Stadium to university

39
Another dataset is the dataset corresponding to AI/ML based driver classification challenge
track in '2018 Information Security R&D dataset challenge' in South Korea, referred as
‘Dataset B’ [1]. On Board Diagnostics 2 (OBD-II) was used to gather per second data from
a KIA recent model. This dataset included 4 different round trips between Korea university
and SANGAM World cup stadium of about 23 hours of driving. Some salient parameters
about this study have been described in Table 3.3.
This experiment was conducted from 8 p.m. to 11 p.m. on weekdays on one fixed route by
different drivers. The vehicle was driven by 10 different drivers labelled from “A” to “J”
and covered a distance of about 46 kilometres for 3 road types namely, city way, motor way,
and parking space. Sample value of raw data that includes engine RPM, fuel level, throttle
position percentage, accelerometer readings, driver ID and order of path for few samples of
data as shown in Figure 3.4.
Fuel_consumption Throttle_position Engine_speed Vehicle_speed Acceleration_X Acceleration_Y Time(s) DriverID PathOrder
537.6 8 1450 21 -0.2 -0.1 56 A 1
512 8 1306 21 -0.2 0.2 57 B 1
486.4 8 1262 21 -0.2 0.1 58 C 1
2176 100 1898 21 1.1 0.4 66 D 1
2252.8 100 1956 22 1.1 0.2 67 E 1
2316.8 100 2010 23 1.1 0 68 F 1
2393.6 100 2076 25 1.1 0.1 69 J 1
2483.2 100 2129 26 1.1 0.1 70 A 2
2534.4 93.4 2180 28 1.1 0.1 71 B 2
1600 16 2028 29 0.6 0.3 72 C 2
742.4 9.9 1830 28 0 0.1 73 D 2
819.2 11.3 1797 27 0.1 -0.3 74 E 2
857.6 11.3 1776 26 0.1 -0.3 75 F 2
1049.6 14.6 1824 27 0.3 0.3 76 J 2

Figure 3.4: Snapshot of Raw Data as in Dataset-B

As location of route has not been specified for each timestamp, it has been approximated
using google map route for doing effective analysis. Speed limits for Korea city and highway
have been considered according to route from Korea university to stadium.

3.4 Process for abstraction of driving features

The process of abstracting driving features in a meaningful manner requires several steps, as
elaborated in Figure 3.5. First step involved identification of different sensors that help in
the collection of raw data as detailed in Section 3.2. Raw data collection of sensor values is
done via OBD, and CAN and information is sent to the cloud server for conversion to
meaningful values as mentioned in step i.
In the second step, different types of features about trip, vehicle, environmental context, and

40
driving behaviour are identified by analysing raw information. Raw information is converted
into quantifiable features that can be processed by computational models as referred in step
ii.

START

1. Capture and collect raw data using onboard sensors (3.4 i)

2. Define Feature types and identify raw data for each feature (3.4 ii)

3. Define driving contexts in correlation with driving behaviour (3.4 iii)

4. Abstraction of sub-trip level Driving Context (3.4 iv)

END

Figure 3.5: Process for Abstraction of Driving Features

In third step iii, features of environmental context and driving behaviour are defined. It is
explained how different environmental conditions affect interpretation of driving behaviour.
Fourth step defines different sub-trips of varying intervals for each unique environmental
context as mentioned in step iv. Sub-trip level abstraction of driving features helps in fine-
grained meaningful analysis of driving data.

OEM Provided Information

1. Detect driving
behaviour
2. Identify
sensor Context
OBD CAN SIM WIFI signal Cloud 3. Map driving
behaviour to
context
4. Analyze
attributes via
CONNECTED CAR computational
models for
safety and fuel
economy
Figure 3.6: Process Flow for Data Processing
Various steps involved in abstraction of driving features have been detailed as below.
i.Data collection using onboard sensors as shown in Figure 3.6, vehicle data for GPS,

41
 accelerometer, velocity, and fuel level is sensed via different sensors. Values received
from vehicles are broadcasted by CAN to various ECUs and vice-versa. OBD-II gathers
information from OBD-II port and transmit the same to cloud via cellular connection or
wi-fi connection. Raw sensor signals are converted to actual attribute values by applying
sensor fusion and pre-processing techniques by OEM.
ii.Feature extraction from raw data - The processed attributes received from OEM are
analysed to extract attributes corresponding to driving behaviour, environmental context
and mapped together. Contextually mapped attributes are processed via different
computational models to predict fuel consumption, assess driving risk, identify
anomalies, and provide driver assistance to plan further driving actions. Table 3.4
elaborates various features extracted from the datasets while mapping features to their
respective sensor sources. Trip-related features included total distance covered in
kilometres, trip duration in hours, and vehicle speed in kilometres per hour.
Table 3.4: Features Referred in Current Study

Category of Feature Feature Name Source Sensor

1. Trips by a driver Distance covered between two GNSS, Wheel Odometry, TPS,
subsequent data samples APS IMU

Duration between two subsequent Timestamp

data samples

Speed of vehicle between two GNSS, Wheel Odometry, TPS,

subsequent data samples APS

2. Vehicle parameters Mileage observed between two Fuel Level sensor

subsequent data samples

Vehicle Model Hatchback car

3. Environmental Context Road Type for a particular Here map API

parameters sample

Traffic Congestion for a Here map API

particular sample

Travel Time for a particular Timestamp Difference

sample

4. Driving Behaviour Harsh Acceleration distance & Throttle Pressure Sensor, IMU
parameters duration

Harsh Deceleration distance &

duration

42
 Overspeed distance & duration Wheel Odometry, Here map API

Sharp Turn distance & duration Angular velocity using steering

sensor and gyroscope

iii.Environmental context and its correlation with driving behaviour – Environmental

context is defined based on current driving conditions like road type, traffic congestion
and time of day for an ongoing trip. The parameters of environmental context are
elaborated in Table 3.5.
1) Road Type - For each captured trip, Here map Application Programming
Interface (API) [43] is invoked to provide information on road type and associated
speed limit using the current GPS location of the vehicle. Speed limit considered for
national/express highways is 90 km/h+, state highways (70–90 km/h), city flyovers
(50–70 km/h), and regular city traffic as (<50 Km/h). Value of this attribute is
assigned value numbers 1-4 as shown in the first row of Table 3.5. Vehicle speed
exceeding the road's speed limit is considered as overspeed. More significant
percentage of overspeed leads to increased driving risk owing to overspeed[11].
Table 3.5: Categorization of Environmental Context Features

Features Categories

Road Type 1 - national highways & express highways (90+ km/h)

2 - state highways (70–90 km/h)
3 - city flyovers (50–70 km/h)
4 - regular city traffic (<50 Km/h)

Traffic Congestion 1 - free-flowing

2 - a steady flow
3 - severe congestion
4 - congestion

Time of Travel 1 - night (20:00– 7:00 IST)

2 - morning hours (7:00 – 11:00 IST)
3 - day (11:00 – 17:00 IST)
4 - evening hours (17:00 – 20:00 IST)

Speed limits are defined by government road transport regulatory authorities according to
85 percentile of actual speed distribution on that road. The structure of request and response
for Here map speed limit is shown as below.

43
 Request
curl \
-X GET \
-H 'Content-Type: *' \
--get https://route.ls.hereapi.com/calculateroute.json" \
--data-urlencode "app_id=$APP_ID_HERE" \
--data-urlencode "app_code=$APP_CODE_HERE" \
--data-urlencode 'waypoint0=geo!$Src_Lat,$Src_Long' \
--data-urlencode 'waypoint1=geo!$Dst_Lat,$Dst_Long' ' \
--data-urlencode 'mode=fastest;car;traffic:enabled' \
--data-urlencode 'legattributes=li' \
| jq '.'

The “legattributes=li” attribute in request helps to get route link attribute

“speedLimit” in the response that include speed limit details.
Response
"link": [
{
"linkId": "+1217666399",
"shape": [
],
"speedLimit": 20,
"_type": "PrivateTransportLinkType"
},
Speed limit provided by REST API is returned in meters per second and it is converted
to kilometres per hour by multiplying it with 3.6.
2) Traffic congestion - Depending upon flow of traffic, traffic congestion has been
classified into four categories represented by numbers 1-4, referring to the second
row of Table 3.5 [2][13][20-21][29-30]. Congestion reduces inter-vehicular distance
and requires frequent vehicle manoeuvring actions by the driver[8]. Congestion
affects driving speed and may trigger non-fuel-economical driving actions. Hence, it
requires more attention on the driver's part to timely respond according to the driving
pattern of other vehicles.
3) Time of Day is an important feature affecting driving behaviour[8][22][30][33].
It has also been assigned numbers 1-4 depending upon travel time as described in the
third row of Table 3.5. Driving during night affects visibility, hence affecting driving
speed. Travelling during peak hours may lead to slow driving speed due to
congestion.
Environmental context can be divided into 64 different combinations based on different
values for road type (RTi), traffic congestion (TCj), and time of day (TDk). The value for
context identifier (CTX) is specified by Equation 3.3 where concatenate function appends

44
the value of road type (RTi), traffic congestion (TCj), and time of day (TDk) for different
values of i, j, and k respectively.
= , , (3.3)
Driving behaviour is classified into three categories based on intensity and frequency of
aggressive driving behaviour, as described in Table 3.6.
Table 3.6: Classification of Driving Behaviour Features

Features Values

Harsh Driving Behaviour Harsh Acceleration; Harsh Deceleration; Overspeed

Frequent Negative Frequent Halt; Frequent Acceleration; Frequent Deceleration

Behaviour

Negative Turn Behaviour Sharp Turn; Aggressive Acceleration/Deceleration during a turn

Driving Behaviour is a reflection of a driver’s driving as good or bad based on current driving
practices. Example scenarios that describe driving behaviour are listed below.
How harshly or frequently does the driver accelerate or decelerate?
How often does a driver overspeed as per road speed limit?
Whether the driver takes sharp turns with high acceleration?
Whether the driver has to apply an emergency brake to avoid crashing into an adjacent
vehicle?
Details about each type of aggressive driving behaviour and how it would be captured will
be explained in Chapter 4. Some scenarios highlight the importance of mapping driving
behaviour to an environmental context and depict the correlation between them.
Driving speed of 90 km/hour can be considered safe on the highway. However,
it would be considered as risky for urban roads.
Slight acceleration for a high-speed vehicle can be dangerous but can be
considered safe for a low-speed vehicle.
A driver may need to adjust his speed and acceleration frequently under high
congestion but can drive smoothly under low congestion.
Low visibility during the night may affect driving safety.
Cruising improves fuel economy; however, it can be unsafe if the driver does
not slow down on crossing.

45
 Sometimes harsh braking is required to avoid an accident; however, it is safe and
fuel-economical to maintain proper headway from adjacent vehicles and apply
brakes slowly.
Driving events are classified into different kinds of negative driving events based on
velocity, acceleration, and throttle position by applying contextual rules. As shown in the
first row of Table 3.7, if vehicle speed is 60 kilometres per hour on city roads, it is considered
as overspeed as the speed limit for city roads is 50 kilometres per hour. On the other hand,
the speed of 60 kilometres per hour on the highway is not taken as overspeed.
Table 3.7: Driving Event Detection Based on Road Type
Acceleration
Road Type Speed Limit (KM/h) Vehicle Speed (KM/h) Driving Event
(m/s2)
City 50 60 1.22 Overspeed
Highway 90 60 1.22 Harsh Acceleration
City 50 40 -0.75 Normal Deceleration
Highway 90 60 -0.75 Harsh Deceleration

An acceleration of 1.22 m/s2 on highway roads is considered as harsh acceleration (as per
second row of Table 3.7) as slight acceleration on high speed vehicles may be hazardous,
whereas it may be considered normal acceleration for vehicles running at low speed (1st row
of Table 3.7).A deceleration of 0.75 m/s2 for high-speed vehicle (4th row of Table 3.7) may
result in jerk, hence it is considered as “harsh deceleration”, whereas same deceleration at
low speed of 40 kilometres per hour may not result in jerk(3rd row of Table 3.7). Thus, the
impact of driving behaviour depends on contextual parameters and must be evaluated in
correlation with environmental context.
iv.Sub-trip level abstraction of driving contextual data - Driving behaviour abstraction
includes correlating environmental context and driving data for meaningful analysis of
safe and fuel-economical driving. Driving data is divided into different sub-trips
according to the same contextual features, road type, traffic congestion, and travel time
for mapping driver behaviour to environmental context. A context ID is generated by
concatenating contextual feature labels for road type, traffic condition and time of day.
One example of the generation of contexts has been shown in Table 3.8.
Table 3.8: Example of a Sub-trip and Associated Driving Behaviour
Duration Environmental Context as per Duration of
Sub- of Sub- Table 3.5 driving
Trip trip in Time of Road Conges CTX Driving behaviour in
ID millisecon Travel Type tion ID Behaviour milliseconds

46
 ds
City Steady
Frequent
1 210000 Morning-2 Road - Flow - ‘242’ 18000
Stop
4 2
Morning-2 City Steady
Frequent
1 210000 Road - Flow - ‘242’ 68000
Braking
4 2
Morning-2 City
Conges Frequent
2 37000 Road - ‘244’ 8000
tion - 4 Stop
4
Morning-2 City Free
3 56000 Road - Flow - ‘241’ Overspeed 18000
4 1
Morning-2 City Free
Frequent
3 56000 Road - Flow - ‘241’ 5000
Braking
4 1
Morning-2 City
Steady Frequent
4 24000 Road - ‘242’ 18000
Flow-2 Braking
4

If the value of any contextual parameter changes, a new context ID is generated. In the
example shown above, the context is getting changed from ‘242’ to ‘244’ in the third row,
hence new sub-trip ‘2’ is generated. There can be multiple driving behaviour observations
within same sub-trip. Each driving behaviour is analysed in the context of different
environmental conditions. The distance and duration of driving behaviour during a particular
context is noted down to evaluate effect of driving behaviour in light of contextual
parameters.

3.5 Chapter summary

A detailed process for abstraction and quantification of driving features at the sub-trip level
helps obtain relevant contextual mapped features that can be analysed in a meaningful way
and serve as input to computational models. It enabled fine-grained measurement and
tracking of driving behaviour features to provide instantaneous feedback to drivers, but it is
not computationally intensive.

47