Posting travel times on dms webinar 042711

Posting Travel Times on Dynamic Message Signs & 3rd Party Data… best practices & lessons learned

Welcome!Wednesday, April 27, 2011 11:00a.m. – 12:30 p.m. (Eastern Time)

Posting Travel Times on Dynamic Message Signs & 3rd Party Data Webinar


Disclaimer: Today’s webinar is being delivered at the request of several State Transportation agencies. FHWA does not endorse any of the 3rd Party Data Service providers/vendors discussed in the following presentations.


The Idaho Transportation Department’s interest in posting travel time

FHWA facilitated a teleconference for ITD with other state DOTs to learn of their approaches

Mutual assessment by the State Transportation agencies involved and FHWA that this topic was of national interest and so deserved a webinar to share lessons learned & best practices.

What prompted this webinar?


2009 MUTCD Reference Changeable Message Signs

Section 2L.02 Applications of Changeable Message Signs

G. Travel Time

We have three poll questions we would like you to respond to:


Moderator & Speaker Bios are available in the “Download Bios & Today’s Presentation Pod”

Wednesday, April 27, 2011 11:00a.m. – 12:30 p.m. (Eastern Time)

Special Guest Speakers● Jennifer PortanovaState ITS Operations EngineerNorth Carolina Department of Transportation ---● Jeff GalasTraffic Systems Center ManagerIllinois Department of Transportation---● Richard DyeCHART Systems Administrator Maryland State Highway Administration---

ModeratorBob KoeberleinMobility Services EngineerIdaho Transportation Department

We have three speakers today:


April 27, 2011

Jennifer Portanova, PENorth Carolina Department of Transportation

State ITS Operations Engineer

POLICY

• No formal policy • Guidelines

o Time of day TT will be postedo How often TT will be updatedo Priority level of message o Message Format


LOCATION

• Posting TT in urban & rural areas statewide

• Pre-determined locationso Reoccurring

congestiono Decision Point

between two routes

o Needs tweaking• Regional input on

locations


POSTING• Automated and Manual

Posting• Weekdays Peak Hours

o 6 am to 9 am o 4 pm to 7 pm

• Or if speeds drop below speed limit (automated)

• Updated every:o 10 minutes (manual)o 1 minute (automated)

• Low Message Priority

HIGH

LOWPosting Travel Times on Dynamic Message Signs & 3rd Party Data Webinar

POSTING FORMAT

• Short Segments (96 mph) • Range Vs. No Range

VS

Current format


EQUIPMENT

• Permanent signs (DMS)• Discussed stationary • Challenges with older

deviceso Number of characterso Communicationo Automation Software

Not using portable devices


DATA SOURCE: Manual

• Vehicle probe speed data

• Webpage with TT • Capped at Speed

Limit• Round up• Message updated

by operator


DATA SOURCE: Automated

• Microwave speed sensors

• Current software limits data source

• Working on software for any source


DATA RELIABILITY

• 3rd Party Microwave Sensoro Sensitivityo Maintenance

• 3rd Party Vehicle Probe Data o Missing

segmentso Mountainso Source of datao Continues to

improve


WORK ZONES & VARIABLE SPEED LIMITS

• Permanent devices• Have some TT in WZ• Not strategically posting

for a WZ, yet…• Working on WZ application• Variable speed limits

o Only in WZo Not in effect during peak

hours


MAINTAINING ASSETS

• Devices and data already existed

• Funded operator positions to post

• Webpage to make Manual TT easier

• Future Investmentso Upgrade DMS for

automated TTo Strategic

Developmento SMARTlink RFP


LESSONS LEARNED

Automated ideal – monitoring still required

Regional perspective important

Avoid ranges on small segments

Expect to make changesHave a Champion



Jeff Galas, Traffic Systems Center MangerIllinois Department of Transportation


Travel Times in the Chicago Area

Illinois Department of TransportationDistrict 1Traffic Systems Center


Network of over 2400 detectors – 168 centerline miles monitored


Combination of Detection Methods:

• Induction Loops

• RTMS microwave detectors

• Microloops (magnetometers)

• Bluetooth capture

Spaced approximately every 0.5 mile

Interfaced to the ATMS as Volume and Occupancy (presence)


42 Expressway Dynamic Message Signs14 Arterial DMS


Combination of DMS Technologies

• Flip Disk – Fiber optic enhanced

25 to 30 year old

• LED Full matrix Walk-in NTCIP compliant

More recent installations

• LED Full matrix / Full Color

Replacing the oldest of the oldMUTCD Graphics capability


Near Real Time Congestion and Travel Times

• Available to the public for over 30 years

• Distributed through local television and radio outlets

• Broadcast on Highway Advisory Radio

• Displayed on the LMIGA website

• Displayed on Dynamic Message Signs


Congestion messages displayed on DMS …. Daytime only


Challenged to start displaying Travel Times

• Use existing Travel Time algorithms

• Determine and develop new Travel Time zones

• Interface to sign controller

• Monitor operation for accuracy


Travel Time Calculation:

Each station is sending presence information in real time

20 second sample is stored

Speed is calculated using Volume and Occupancy:

Speed = 3600 (Volume) (average vehicle length) 52.8 (polling interval) (Occupancy)

Average vehicle length varies by lane (17 feet to 22 feet)

Data is normalized prior to calculation


Travel Time Calculation:

Speed is used to calculate relative time:

Travel Time = Length of segment Speed

Each segment is adjusted for actual spacing between detectors

Segment times are concatenated for longer zones

Zone travel times averaged over 5 minute periodbefore being published or displayed


ATMS Vehicle Detection Station – Estimated Speed


....DMS Travel Times


Guidelines for DMS Messages

Hierarchy of messages displayed:

1,2 Priority message (Crash, pavement failure, incident)

3 ATMS incident

4 Scheduled message (lane closures, planned events)

5 2 phase Congestion / Travel Times

6 AMBER alert

7 Travel Times

8,9 Stored message (PSA ,seat belt, DUI, etc)

10 Previous ATMS travel times


Messages refer to landmarks and destinations

DMS Travel Time zones do not exceed 10 miles

O’Hare Airport

Junction

Circle

159th street


Desire (demand) for travel times

• Public has become accustomed to travel times

• Media focus on travel time info

• When outages occur, calls come in

• Requests for system expansion

• Difficulties in construction zones

• When the loops are removed• RTMS units• Bluetooth


Construction Alternatives

“Bridge” Detection zones – short distances

Probe Vehicles

Travel times manually entered as received

RTMS units

conflict with construction stagingre-calibration based on lane configuration

Bluetooth

Fairly accurate alternative


DMS Travel Times during Construction


Investment in infrastructure

Initial installation

Approximately $250,000 per sign

Truss, Sign, power, communication

ATMS modification and software

Maintenance

Under contract - $26,000 per month for system

Additional cost for battery back-up sign - $1,000 / year


Using the I-95 Corridor Coalition Vehicle Probe data to put Automated Travel Times on Dynamic Message Signs in Maryland

Richard R. DyeCHART Systems Administrator

- As recently as December 2007, Travel Times on DMS was scheduled for FY 2012 due to lack of infrastructure to provide good data and the need to devote a major build entirely to this effort.

- In the mean Time CHART was preparing the background logic in smaller builds (System Alerts R3B1, Scheduler and Event-based Notification R3B2)


- That same month, the I-95 Corridor Coalition awarded a Travel Time contract and software development for automated messages on CHART signs was pushed forward to meet the challenge

- Work was also begun on Engineering Guidelines for Implementing Travel Times On DMS in Maryland

More Info, download Procedural Guidelines For Implementing Travel Time on DMS In CHART (PDF) at http://traffic.md.gov/readingroom/RR_ChartSWProgDocumenation.asp


- …but… developing software to implement a 3rd party interface that had been neither developed nor tested was risky (to say the least)

- This is the 1st time EVER that messages will be put on a CHART field device without the direct approval or even overt knowledge of an operator. How do we manage our risk?

- … and the FHWA “map” was not going away


Assumptions!- If the 3rd party data is good, we can

move automated travel times on DMS up to a non-dedicated build if:- Routes in CHART will be built using

links that we choose- This will allow us to avoid obvious trouble

spots for probe-based systems (e.g. welcome station on I-95 where long runs parallel to the highway may confuse the data)

- Travel Time will run during hours of day that we choose- This will allow us to avoid obvious trouble

spots for probe-based systems (e.g. low volume of probes between 2am and 4am)


Assumptions!- Travel times will be displayed

in ranges, not exact times- The currently approved

quality scores will be used to determine if a message is displayed

- A smoothing algorithm will be added to the travel time data received from The 3rd party vendor- This should mitigate the

severity of seriously outlying data points


Assumptions!

- If a maximum travel time threshold is received, the message will not be displayed and an alert will be set to the controlling Ops Center as well as notification to selected pager/email groups in the system

- Travel times below a minimum will display travel time as if the speed limit were traveled



– CHART Release 3, Build 3 was deployed in December 2009 and was composed of:

• Traveler Information Messages, including Travel Times and Toll Rates obtained via an external connection to the two different 3rd party vendors system and Vector system.

• Device Location fields to CHART devices, including DMS, TSS (Detectors), HAR, SHAZAM, and Cameras allowing the system to show devices close to traffic events to aid in event response.

• External Event Import including External Event Alert

• External DMS and TSS import from RITIS.

• Capability to manage geographical area definitions

• Direct TCP/IP communication for DMS and TSS

Timeline

More Info, download CHART R3B3 Detailed Design.pdf at http://traffic.md.gov/readingroom/RR_ChartSWProgDocumenation.asp

How Did It Turn Out?

– Privileged operators can create travel routes


How Did It Turn Out?• For maximum flexibility, DMS Message Templates are

used to define the format and layout of messages used to show travel times and/or toll rates on DMSs. Message templates target DMSs of a specific size (rows /columns) to allow layout features such as column data and to ensure messages created with the template match the layout specified by the template designer.

• Templates may contain both text and data fields. Data fields will be replaced with actual data from one or more Travel Routes when a template is used for a DMS

message.


– Any Operator can see• The name and length of the route • The current travel time for the route • The current travel time trend• The current average speed on the

route • The current toll rate for the route • The devices using the travel route• The roadway route(s) that are

included in the travel route.• The roadway direction(s) that are

included in the travel route.• The Counties that are included in the

travel route

How Did It Turn Out?


• Travel Time started on I-95 between the beltways in January 2010

• Travel Times run 5am to 9pm weekdays


• Travel Time expanded to both beltways in March 2010


• Travel Time expanded westward and to the eastern shore in Late 2010

August 2010 – Senior Management Weighs in

- All signs displaying travel time need to also display the distance to the destination(s). - The distance as displayed on single destination signs to read XX MINUTES on line 3 if there is room. XX MIN otherwise. - For multiple destination signs, the sign should display XX MI between the destination and the travel time. - In a few cases, the destination description is too long for XX MI to fit on the same line. In these cases the message should be revised to report travel time to a single destination.


What Can the Operators See?


What Makes up a Route?

Links that we receive from the 3rd party vendor and build into a Route


And general settings (max displayable time, min travel time, who to alert when things go wrong – remember the assumptions?)


…and a Dynamic Message Sign!


What Does the Public See?


What if Travel Time is Exceeded?

What Does the Operator See?


What if Data Quality is too Low?

What Does the Operator See?


What if there is a Conflict?What Does the Operator See?



What Does the Public See?



Good To be determined

CHART is ecstatic how well the software has come out

We have expanded in phases from the original 6 to 57 active travel routes since January 2010

10 – 20 – 30 Seems to work but we have seen some 20’s in the middle of a bunch of 30’s that look like they were historic. This concerns us on short routes and we are looking into it.

We will be looking to implement the 1 – 100 scale once we learn more about it.

The connection between The 3rd party vendor and State through internet seems pretty reliable

There have only been a hand full of unplanned outages

Not a huge amount of public comment, but what there is seems much more positive than negative

When there are documented “concerns” from public that messages are unreasonably slowing traffic, we review before and after data and have removed TT on DMS on a case by case basis.

Experience So Far


Thank You!

http://ops.fhwa.dot.gov/1201/ Bob Rupert, FHWA, 202-366-2194, [email protected]

FHWA Real-Time System Management Information ProgramSAFETEA-LU, Subtitle B, §1201 Provisions of the Rule – 23 CFR Part 511

http://ops.fhwa.dot.gov/FHWA Operations

Ray Murphy, ITS SpecialistOffice of Technical [email protected], 708-215-1301

Any Questions for our Speakers?

Technology

Posting travel times on dms webinar 042711