Estimation of Delay using Sensor Data for Reporting through Business
Intelligence
Victor Molano and Alexander Paz
Howard R. Hughes College of Engineering, University of Nevada, Las Vegas,
4505 Maryland Parkway, PO Box 454007, Las Vegas, U.S.A.
Keywords: Business Intelligence, Delay, Sensor Data, Intelligent Transportation Systems.
Abstract: This study proposes a simple method to estimate delay using sensor data with the final objective of
processing and reporting the information through Business Intelligence. The method involves three main
tasks: determination of the Peak Period, definition of seasons used by FAST, and the calculation of delay. A
small portion of the Las Vegas Roadway network is used to illustrate results. Functional requirements for
Business Intelligence are proposed.
1 INTRODUCTION
Congestion and incident management require the
involvement of multiple stakeholders who need
reliable and easy access to data and analytics to
make adequate planning and operational decisions.
Business Intelligence (BI) involves the use of
informatics to provide access to data and associated
analytics. That is, BI involves the processing of data
to provide meaningful and easy to use information
(NEDELCU, 2013). BI with its real time reporting
and automated capabilities at different organization
levels has become an important management and
tracking tool in developed countries (Nofal and
Yusof, 2013). BI solutions have been proposed for
transportation systems. Sampaio P., et al. (2011),
provided an application to public transportation.
An alternative to BI is the use of traditional
standalone applications. As part of the Regional
Transportation Commission of Southern Nevada
(RTCSN), the Freeway and Arterial System of
Transportation (FAST) plays a major role in
monitoring and reporting freeway incidents using a
web-based dashboard, Performance Monitoring and
Measurement System (PMMS)
(http://bugatti.nvfast.org/). PMMS data is collected
through sensors such as radar detectors, cameras,
and Bluetooth devices (Xie and Hoeft, 2012). The
information is stored in a databased and retrieved
through Structured Query Language (SQL) queries.
This study proposes a simple but very practical
algorithm for reporting day using sensor data
collected by RTCSN. Currently, there is data
available for 449 sensors. Information from four
sensors along the US 95 corridor in Las Vegas for the
2014 Spring season was used in this study. The data is
constantly updated for display on the dashboard.
With the objective of developing a BI dashboard
for the Nevada Department of Transportation
(NDOT) the percent of days in a season with a daily
peak period delay that does not exceed the average
delay by more than 10% is considered in this study.
This performance measure is of particular interes to
NDOT. The calculation of this measure involves
three main tasks: determination of Peak Period,
definition of seasons used by FAST, and the
calculation of delay.
2 METHODOLOGY
2.1 Determination of Peak Period
Generally, Department of Transportation (DOTs)
define two peak periods per day; one in the morning
and one in the afternoon. However, this static
definition could miss important information about
non-recurrent and nocturnal events. In Las Vegas
area, it is observed that there are often two or more
periods depending on the location and season.
Therefore, a more detailed analysis is required for
the estimation of the peak periods.
This methodology recommends to define the
peak periods based on a definition provided by the
Molano, V. and Paz, A.
Estimation of Delay using Sensor Data for Reporting through Business Intelligence.
In Proceedings of the International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2016), pages 99-103
ISBN: 978-989-758-185-4
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
99
Federal Highway Administration (FHWA) Office of
Operations, where congestion thresholds are
estimated and the duration of the congestion is used
as the peak period.
“Measuring congestion by times of the day and
days of week has a long history in transportation. A
relatively new twist on this is the definition of a
weekday "peak period"—multiple hours rather than
the traditional peak hour. In many metropolitan
areas, particularly the larger ones, congestion now
lasts three or more hours each weekday morning and
evening. In other words, over time, congestion has
spread into more hours of the day as commuters
leave earlier or later to avoid the traditional rush
hour” (FHWA, 2015).
This phenomena together with the characteristics
of the Las Vegas commutes and tourism makes
undesirable to define a static peak period. To
identify the congested periods, FHWA defines
thresholds using the hours in which the speeds are
less than 90% of the free-flow speed.
“Congested Hours are computed as the average
number of hours during specified time periods in
which road sections are congested — speeds less than
90 percent of free-flow speed” (FHWA-UCR, 2015).
To estimate average free flow speed, data from
the Highway Performance Monitoring System
(HPMS) can be used.
2.2 Definition of Seasons
The definition of seasons used by FAST are:
Beginning of year, Holiday, Fall, Summer, Early
Summer, and Spring. The detailed definition of the
seasons is provided in Table 1. For this study Spring
of 2014 is considered.
Table 1: FAST Definition of Seasons.
Season Description
Beginning
of year
First day of CCSD school following holiday
break through a Friday in mid-March
Holiday
Monday before Thanks giving to day before
CCSD school begins
Fall
F
irst day of CCSD school following summer
vacation to Sunday before Thanksgiving
Summer
Final weekend of CCSD high school
graduations through Sunday before the new
school year begins
Early
Summer
A Monday in mid-April through the
last weekend of CCSD school activity and
graduation ceremonies
Spring
A Saturday in mid-March through a
Sunday in mid-April
2.3 Delay Calculation
The National Cooperative Highway Research
Program (NCHRP) proposes a methodology to
calculate delays for a segment (NCHRP, 2008).
Equation 1 provides the corresponding formula.
  =
 


 
(1)
where,
 = the total delay for a segment
(persons-minutes)
 = Actual travel time in minutes


= Travel time under free flow
speed or posted speed (minutes)
 = Vehicle volumes (number of vehicles)
 = Vehicle occupancy (persons/vehicle)
The FAST sensors do not capture the occupancy
in terms of persons per vehicle. Therefore, from
Equation 1, the occupancy is removed and the Total
Delay is reported in vehicle-minutes. This
modification does not affect the calculation of the
performance measure required by NDOT.
3 TEST SAMPLE
A test example, for a 1.6 miles segment along the
US-95 Corridor in Las Vegas, was performed.
Information from four sensors for the 2014 Spring
season was used in this example. The location of the
sensors and the segment is illustrated in Figure 1.
The analysis includes only the southbound located
sensors.
Figure 1: Location of the Test Example Sensors.
The results from the test example are shown in
Table 2. The identification number and the length of
the segments where the detectors are located is
provided. The percent of days in a season that have a
daily peak period delay that does not exceed the
VEHITS 2016 - International Conference on Vehicle Technology and Intelligent Transport Systems
100
average delay by more than 10% for each detector is
provided in column, ‘Percentage’. In total, for the
1.6 miles segment, 39.78 % of days in spring of
2014 have a daily peak period delay that does not
exceed the average delay by more than 10%. This
value is estimated by calculating a weighted average
of percentages using Vehicle Miles Traveled (VMT)
as the weights.
Table 2: Sample Test Results.
Detector Length (mi) VMT (veh-mi) Percentage
204_1 0.28 5585837.989 81%
204_2 0.42 8501308.598 28%
210_1 0.52 10940883.45 47%
210_2 0.38 5806442.714 3%
TOTAL 1.60 30834472.75
In addition to the required performance measure,
the data can be queried based on the facility, a
selected region, year, month, weekdays, and
weekend days. As an example, Table 3 shows the
summary of the calculation for the week and
weekend days in spring of 2014. These capabilities
can be implemented in BI with ease in addition to
the requested performance measures.
Table 3: Sample Test Results for Week and Weekend
Days.
Detector Percentage
(Week days)
Percentage
(Weekends days)
204_1
75%
92%
204_2
0%
75%
210_1
25%
92%
210_2
0%
10%
In total, for the 1.6 miles segment, 22.46% of the
weekdays and 71.87% of the weekend days in spring
of 2014 have a daily peak period delay that does not
exceed the average delay by more than 10%. This
value is estimated by calculating a weighted average
of percentages using the Vehicle Miles Traveled
(VMT) as the weights.
To calculate the required performance measure,
the following steps are proposed:
1. Calculate the length of the segments from the
network geometry used by FAST.
2. Estimate the free-flow speed using geometrical
characteristics from the HPMS database. This
step requires integration between the HPMS and
FAST networks. The procedure in the 2010
Highway Capacity Manual for basic freeways
was used (HCM, 2010) in this study.
3. For each sensor and day in the season, average
the speeds and aggregate the volumes to hourly
values.
4. For each sensor, determine the peak period’s
where the actual averaged speeds are less than
90% of the free-flow speed. Using the free-flow
speed and the actual speed, a Boolean variable
was created to flag the peak periods. Illustrations
of the peak period’s estimation for different
sample days of the season are shown in Figure 2
and 3. Figure 2 shows one peak period interval
for the detector 204_1 during April 10th of 2014.
Figure 3 shows two peak periods, one in morning
and one in the afternoon for detector 204_2
during April 7th of 2014. The algorithm detected
days in the season when there was none peak
period. In contrast, days where found when the
congestion kept constant throughout the day.
Figure 2: Peak Period Sensor 204_1.
Figure 3: Peak Period Sensor 204_2.
5. For each sensor, determine the average delay in
the season. Delays for each hour where
calculated using the NCHRP methodology.
6. For the corresponding flagged hours from Step 4,
if the hourly delays do not exceed the average
Estimation of Delay using Sensor Data for Reporting through Business Intelligence
101
delay by more than 10 %, then flag the day.
Figure 4 and Figure 5 shows that for the peak
periods, the actual delay exceeded the average
delay for at least one hour for the sensor 204_1
and 204_2. For some days in the season the
delay exceeded the average delay, however, the
speed threshold showed that there was not a peak
period.
Figure 4: Delay Sensor 204_1.
Figure 5: Delay Sensor 204_2.
7. For each sensor, count the number of days that
meet the condition in Step 6.
8. Determine the total number of days in the season.
9. For each sensor, using the number of days from
Steps 7-8, compute the percentage of days in the
season that do not exceed the average delay by
more than 10%.
10. Calculate the associated VMT for each sensor
and season.
11. Using the VMTs from Step 10, calculate a
weighted average of the percentages in Step 9.
The average represents the required performance
measure.
4 FUNCTIONAL
REQUIREMENTS
This study recommends a dashboard to display the
results from the proposed methodology. The
recommendations for functional requirements of the
dashboard proposed in this study are:
1. The BI dashboard will provide pie charts and
tables with percentages from the delay analysis.
2. A section be provided with various prompts to
allow users to query the data based on corridor,
year, month, day, and season.
3. Users have the ability to set the peak hour
threshold, using drop down menus or range
selectors. This will improve the dynamic
functionality of this dashboard. However, this
capability is likely to be computationally
intensive. Implementation is required to have a
better idea about performance.
4. Dashboard should provide a table with detailed
information about each day. This table will be
filtered based on the selections in a prompts
section. The table cells can be color-coded to
denote higher delays and peak hours.
5. To have the ability to generate a map using the
roadway geometry information. This map will be
color-coded to represent the delays for each
segment. It can be filtered based on the
selections in the prompts section. From this map,
users can drill down to a segment or corridor
information.
6. To provide charts and tables with aggregated
traffic values based on facilities. The aggregated
values include speeds, volumes, and travel times.
This chart will be filtered based on the selections
in the prompts section.
7. To acquire location information to display the
sensors on a map in BI. This map will be color-
coded to represent the delays for each sensor. It
can be filtered based on the selections in the
prompt section. From this map, users can drill
down to get sensor information.
5 CONCLUSIONS
This paper proposes an algorithm for reporting delay
as required by NDOT. Eleven steps were proposed
0
200
400
600
800
1 3 5 7 9 11 13 15 17 19 21 23
Delay (min-veh)
Hours
Delay: April 10th, 2014 (204_1)
Actual Delay
Average Delay+10%
Peak Period
0
50
100
150
200
250
300
1357911131517192123
Delay (min-veh)
Hours
Delay: April 7th, 2014 (204_2)
Actual Delay
Average Delay+10%
Peak Period
Peak Period
VEHITS 2016 - International Conference on Vehicle Technology and Intelligent Transport Systems
102
to evaluate dynamically daily peak periods and
delays. A test sample from Las Vegas highway
system was presented from which the percentage of
days in a season that do not exceed the average
season delay for more than 10%. The test sample
showed that the proposed algorithm is able to define
congestion periods for multiple traffic conditions. In
addition, the methodology can be extended to
multiple corridors by using the average of the
performance measures found with the Vehicle Miles
Traveled as weight. Moreover, additional
performance measures based on volumes or
densities can be added to the methodology. A set of
seven functionalities are proposed for the
implementation of a dashboard. The proposed
functionalities consider the capabilities and current
available data.
Thresholds and formulation proposed by the
Federal Highway Administration were used to
define the peak periods and delay (FHWA, 2015;
FHWA-UCR, 2015). Future studies involve the
development of a methodology for the estimation of
recurrent and non-recurrent peak periods and delays
using a mathematical framework tailored for the
problem.
ACKNOWLEDGEMENTS
The authors are very grateful with the Nevada
Department of Transportation for sponsoring this
project. Authors would like to express deep gratitude
to Regional Transportation Committee of Southern
Nevada for providing the data and support during
the development and testing component of this
study.
REFERENCES
Xie, G., Hoeft. B. (2012). Freeway and Arterial System of
Transportation Dashboard Web-Based Freeway and
Arterial Performance Measurement System,
Transportation Research Record: Journal of the
Transportation Research Board.
Highway Capacity Manual(HCM): Volume 2:
Uninterrupted Flow. (2010). Transportation Research
Board of the National Academy of Sciences.
NCHRP. (2008). Cost-Effective Performance Measures
for Travel Time Delay, Variation, and Reliability.
Report 618. Transportation Research Board of the
National Academics.
Nedelcu, B. (2013). Business Intelligence Systems.
Database Systems Journal, IV(4).
Nofal, M., Yusof, Z. (2013). Integration of Business
Intelligence and Enterprise Resource Planning within
Organizations, Procedia Technology, 11, 658-665.
Practical Traffic Incident Management. (2011). National
Rural ITS Conference. Retrieved from
http://nationalruralitsconference.org/downloads/Presen
tations11/SessionC3_Brohman.pdf. Accessed on
September, 2015.
Sampaio P., Pereira, G., Carvalho, M., Telhada, J.,
Paisana, A., Paixao, P., Fonseca, A. (2011). A
Business Intelligence Solution for Public Sector.
European Concurrent Engineering Conference, 27-32.
United States Department of Transportation. (2015). The
Urban Congestion Report (UCR): Documentation and
Definitions. Federal Highway Administration: Office
of Operations. Retrieved from http://www.
ops.fhwa.dot.gov/perf_measurement/ucr/documentatio
n.htm.
United States Department of Transportation. (2015).
Traffic Congestion and Reliability: Trends and
Advanced Strategies for Congestion Mitigation.
Federal Highway Administration: Office of
Operations. Retrieved from http://www.ops.fhwa.dot.g
ov/congestion_report/chapter2.htm.
Estimation of Delay using Sensor Data for Reporting through Business Intelligence
103