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

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

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

75%

210_1

25%

92%

210_2

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

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

100

150

200

250

300

1357911131517192123

Delay (min-veh)

Hours

Delay: April 7th, 2014 (204_2)

Actual Delay

Average Delay+10%

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