CARS-Delay

Concept of Operations Functional Requirements System Design

Prepared by: Castle Rock Associates

Prepared for: Minnesota Department of Transportation

Last Revision: June 30, 2015 Document Version History

Version Author Date Change Notes 1 pd 6/29/2014 Initial draft for Idaho. 2 pd 7/14/2014 Reviewed with Dane and Sam 3 fc 8/1/2014 Added background ideas to first draft. 4 kv 8/18/2014 Reviewing initial draft. 5 pd 8/19/2014 Merging separate content for initial Iowa meeting. 6 pd 9/14/2014 Added Iowa and Minnesota inputs. 7 pd 10/30/2014 Reflecting agreed priorities and phasing. 8 pd 11/8/2014 Added many use cases from real data. 9 pd 12/6/2014 Started “build” version for Mn/DOT Innovative Ideas 10 pd 12/16/2014 Continuing “build” version for Minnesota and Idaho. 11 pd 1/7/2015 Further work on “build” version for all three states. 12 pd 1/27/2015 Build version for ITD and Mn/DOT Innovative Ideas. 13 pd 2/7/2015 San Diego corridor delays and travel times added. 14 pd 2/16/2015 Minor changes after review with developers. 15 pd 2/18/2015 Changes during and after Iowa meeting of 2/17/15. 16 pd 2/24/2015 Changes during Boise meeting of 2/24/2015 17 pd Changes during Minnesota meeting 18m du 6/30/15 Updated for MnDOT final submission

2 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Table of Contents

1. Concept of Operations ...... 5 2. Functional Requirements ...... 9 2.1 Overview ...... 9 2.2 Approach ...... 10 2.2.1 Included route designators and sections ...... 10 2.2.2 Included event phrases (CARS-Delay MU) ...... 11 2.2.3 Included event priorities (CARS-Delay MU) ...... 12 2.2.4 Included times of day (CARS-Delay MU and SD) ...... 12 2.3 Delay Assessment ...... 13 2.3.1 CARS-Delay MU ...... 13 2.3.2 Event list (CARS-Delay MU) ...... 13 2.3.3 New and edited reports ...... 15 2.3.4 Events not currently being monitored for delay (CARS-Delay MU) ...... 15 2.3.5 CARS-Delay SD ...... 15 2.4 Announcing Delays (CARS-Delay MU) ...... 16 3. CARS-Delay System Design ...... 16 3.1 CARS-Delay MU Approach ...... 17 3.1.1 Delay prediction ...... 18 3.1.2 Sticking to the monitored road—use of intermediate waypoints ...... 21 3.2 Roadways to monitor ...... 23 3.2.1 Minnesota’s suggested CD1 highways ...... 24 3.3 Phrases to be included ...... 26 3.3.1 Accident/incident phrases ...... 26 3.3.2 Roadwork phrases ...... 27 3.3.3 Lane blockage/closure phrases ...... 27 3.3.4 Traffic conditions phrases ...... 28 3.4 Grouping events ...... 28 3.5 Find delay start and end coordinates ...... 28 3.6 Directions API ...... 31 3.6.1 Efficient design ...... 31 3.6.2 Shared delay license ...... 32

3 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only

4 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only 1. Concept of Operations

This document specifies the design of a new traffic analysis software module called CARS-Delay. The module—which will use Google Directions to help assess the traffic impacts of state DOT and Waze roadway “icon” events, plus potentially (later) CARS-App user reports, where available— focuses on 511 traffic-event impact assessment. Instead of just reporting what is happening on the roads, CARS-Delay aims to allow agencies and the public to see the quantified impacts of traffic events, or (in San Diego only) to monitor corridor travel times.

A group of state and local government agencies uses CARS (Condition Acquisition and Reporting System) as a reporting tool for highway-related event and condition reports. Examples of CARS reports include accidents/incidents, roadwork, traffic delays, winter driving, special events, evacuations, and natural disasters. The CARS software maintains a current events database, and allows the exchange of event reports with other centers and subsystems. Add-on modules facilitate the sharing of traffic/travel reports with the public via 511 telephone, highway advisory radio, the Web, Apps, and email/pager/text message notifications.

An operational need has been expressed for a new CARS module that could automatically bring in delay information to CARS event databases, making 511 reports more meaningful to the public and agencies. The group’s Google Maps license and its “Directions API” allows travel times and delays to be returned in response to specific queries. The Directions API continues to be enhanced and its coverage extended as new innovations and data sources become available. CARS Summit meetings successively concurred that the Google Maps license may have potential as a cost-effective data source for integrating traffic delay data into the CARS/511 systems, starting modestly and progressively covering more highways and event types on an experimental basis.

The Google Directions API service calculates current travel time and directions between specified locations using an HTTP request. Users can search for directions via several modes of transportation—the current modes being driving, transit, cycling or walking. The CARS-Delay module will use Google’s driving mode. Direction queries specify an origin, a destination and any intermediate waypoints either as text strings (e.g. "Ames, IA") or as latitude/longitude coordinates— the method to be used in CARS-Delay. Requests without “hard” intermediate waypoints return Google delay information, at times and on routes where enough vehicles are being tracked. The data will be used to estimate current delays at CARS event locations such as roadwork and crashes.

Idaho’s BlueTOAD traffic speeds deployment—which calculates travel times for fixed roadway sections by detecting and timing passing Bluetooth IDs—originally gave rise to the original concept for CARS-Delay. While testing the delays at a road work site in Eagle, ID, it became clear that similar or perhaps even better results could be obtained through the systematic application of Google’s driving directions API. This experimental, multi-state pilot project is a direct result of that insight. In this project, each CARS-Delay query will include only one origin and one destination, with no “hard” intermediate waypoints—as required for quantified delay data to be returned by Google. At two-way traffic events, separate queries will be made for each affected travel direction.

Start-up funding for the CARS-Delay experiment was first committed by the Idaho Transportation Department (ITD), and later by the Iowa Department of Transportation (Iowa DOT) through a

5 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Year 3 Maintenance Updates (MU) task order signed in July 2014. Then, Minnesota Department of Transportation (Mn/DOT) joined the initiative through its Innovative Ideas program—a contract signed October 2014. The San Diego Council of Governments (SANDAG) has also developed and completed related, initial work on personalized travel times and delays, which are described in a separate CARS System Design Document (SDD) covering the TG-Routes module—which will therefore not be described herein. Now, in its own separate “corridor” version of the module to be termed “CARS-Delay SD”, SANDAG plans to extend its travel time monitoring to cover predefined corridors using an approach that will build on the event-based “CARS-Delay MU”.

Several other agencies were to have committed Year 3 MU funds to CARS-Delay MU, including Kentucky, Indiana, Louisiana and NYSTA. However, as of January 2015, none of these contributions have been finalized—though some positive indications have been made. The resulting uncertainty has made continuing the design of CARS-Delay very challenging, as the available budget—and therefore the number of supportable design features—remains unknown. Similarly, Sacramento has expressed a desire to support CARS-Delay MU using some of its CARS-App WatchMe funding, but currently this has yet to be freed-up from supporting SACOG’s 511 system M&O needs.

Early discussions with the first three funding agencies (ID, IA, MN) identified blue-sky wish-lists of potential “event-based” CARS-Delay MU features. In terms of expenditure plans, Minnesota’s work is most urgent (as it must be fully billed by June 30, 2015), followed by that of Idaho (Phase 1). Iowa’s spending was to have been spread into FY 2016, with a later delivery date than that of MN and ID (Phase 2). However, most of that work may now be moved to Phase 1. Depending on the level of effort that other MU states eventually commit, a 3-year phased development program is now envisioned that seeks to prioritize and implement delay measurement features one by one. This System Design Document (SDD) especially focuses on Phase 1 icon events—often known as Road Reports—in CARS-Delay MU. Other event types such as winter driving and new “clusters” of event reports may follow in later phases.

A few kinds of Road Report icon events will provide the initial targets of CARS-Delay MU. These are (1) roadwork “extent” events, including lane closures; plus accident/incident “point” events, whether (2) from CAD system inputs or (3) from Wazers (the latter in Phase 1-2). Roadwork icon events showing short to medium-length highway sections with construction are the “bread and butter” of many 511 systems during the summer months. Crash reporting is often less advanced, but a few deployments—including those of Minnesota and the California agencies—have well- developed CARS-CAD 911-import systems that create icon events at crash locations. Finally, at least two states (Iowa and Kentucky) will soon import Waze manual reports, which are real-time social media notifications of traffic problems. These manual Waze reports include the point location of the Wazer at the time the alert was sent in.

An important application of CARS-Delay MU is that of social media traffic report verification. Agencies experimenting with—or perhaps planning to try—social media/citizen reporting in new modules like CARS-Vox, CARS-Waze, and CARS-App share a common concern over the validation of citizen reporting. The issue has been summarized as “Who will guard the guards?” or “Who will

6 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only watch the watchmen?” 1 Citizen reports can help validate public agency data such as roadwork and crashes, but a major question remains—who will validate the validators? The Phase 2 CARS-Delay MU work is intended to address this issue directly, giving most prominence to agency and citizen reports that appear to be disrupting traffic.

In the first two phases, Google Directions will be measured for roadway sections that extend 1-2 miles either side of the event’s location (configurable). In future phases, when delays increase, so will the measurement section’s length. Later, perhaps with Sacramento or other agencies’ funding, Waze “slow vehicle” reports shall be added, showing the extent and timing of a slow Wazer’s recent track.2 In the initial Phase 1 and 2 MU work, each roadwork and crash event will be treated as a separate entity, with its own delay—such that some delay sections will overlap. Later work (to be begun as funding permits) may seek to group adjacent events together, consolidating and presenting composite delays across troubled roadway sections.

San Diego’s special version “CARS-Delay SD” will carry out a separate function, assessing Google Directions travel times and delays between fixed points along primarily freeway corridors. This task was traditionally carried out using Caltrans loop detectors, but will now be carried out using the general approaches of CARS-Delay. The San Diego work is being carried out separately from MU, and will not be deployed in other CARS-Delay MU states at this time. Similarly, CARS-Delay MU functions being developed in Idaho, Minnesota and Iowa will not currently be deployed in San Diego County. Of course, given funding, each agency still has the option of joining other agencies’ initiatives at a future time of their choosing. Currently, Idaho and Minnesota have expressed interest in a possible future CARS-Delay SD deployment in their busier areas.

In possible future “event-based” phases, Idaho is potentially interested in looking at planned roadwork, to see if CARS-Delay can help establish when construction activities begin and start to impact traffic. Minnesota is interested in having CARS-Delay help assess the accuracy of adverse Winter Driving reports (painted roads showing winter road conditions). Iowa is one of several states that have expressed interest in statewide performance monitoring using CARS-Delay, as well as in perhaps seeking out3 unusual delays wherever they occur. Also, as a potentially fruitful4 future enhancement, monitoring may be undertaken of regular delay locations using “dummy events” manually created by agencies for locations and time periods where delays often happen.

Thus, the target of the initial “event-based” deployment is agency-created icon events. Using Idaho’s and Minnesota’s Phase 1 funding, initial Road Report monitoring will focus on traffic delays on stretches of road where CARS or 911 operators have created short-to-medium length roadwork or crash events. In Phase 2, for launch in FY 2016, Iowa’s initial CARS-Delay funding will target manual Waze data imports. In both phases, the new module will dynamically change the description and the

1 http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F In CARS-Delay, the question is who will check the citizen reports derived from social media modules such as Waze, CARS-Vox, and CARS-App. 2 Inclusion of Waze slow-vehicle reports in the initial Phase 1 and Phase 2 work programs is currently subject to the Sacramento and other Maintenance Updates (MU) funding uncertainties noted earlier. 3 A concept known in initial design meetings as “Whack a mole.” 4 Among CARS agencies, San Diego, Sacramento and Minneapolis probably experience the most obvious regular, recurrent, major delays at known locations. However, all states experience this circumstance to some extent, e.g., on bridges across major rivers like the Ohio and Mississippi-Missouri, and on urban freeways at peak periods.

7 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only priority of included 511 reports to reflect known traffic impacts of the event. The purpose of CARS- Delay’s individual event monitoring is to bring a new perspective to the reports in CARS and 511— i.e., to update the event details, letting travelers and the DOT know more about the current traffic impacts.

8 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only 2. Functional Requirements

This section specifies the functional requirements for CARS-Delay. The new CARS-Delay software is required to meet 100% of the critical requirements and at least 80% of the other requirements, excluding those described as possible “in the future” or “currently not fully funded” enhancements. Critical requirements are marked with an asterisk.

Phase 1 work in CARS-Delay MU is mainly funded by Idaho and Minnesota. Iowa is also contributing to the Phase 1-2 work (which may now all be funded by 6/30/15 in Phase 1, tbd). Potentially other MU agencies such as Louisiana, Indiana and Sacramento may also contribute to Phases 1 or 2. The Phase 1 work deals with delays at agency-reported roadwork and crashes, with relevance in every state. “Phase 1-2” will apply these developments to individual Waze traffic jam reports, and (in Phase 2, when funded) automated Waze slow-vehicle reports.

CARS-Delay SD work is currently slated as Phase 2. The design of CARS-Delay SD is still work-in- progress in this CARS-Delay MU Systems Design Document.

Priority 3 work in CARS-Delay MU (not yet funded) is expected to cover winter driving and recurrent congestion at predictable locations. Priority 4 may cover statewide monitoring. These Priority 3 and 4 target areas may change as funding decisions continue.

2.1 Overview

ID Functional Requirement Priority Build

In Phase 1, CARS-Delay MU will assess the impact of events containing 1 1.1.1 1. 15-20 selected 511 “icon” event phrases, using Google’s Directions API.*

Reports included in Phase 1 shall comprise selected point and extent 1 1.1.1 2. agency “icon” events of up to 6 miles in length (configurable).*

Monitored events shall include agency 511 roadwork, recent blockage and 1 1.1.1 3. crash (e.g., CAD) reports.*

CARS-Delay SD (where funded) will assess travel times and delays on up 2 N/A 4. to 20 predefined one-way corridors, using the Google Directions API.*

Phase 1-2 will increase the number of MU phrases, adding individual-user, 1-2 N/A 5. manual, social-media reports from CARS-Waze (where available).*

With Sacramento or other agencies’ funding (tbd), MU Phase 2 may also 2 N/A 6. cover automated Waze slow vehicle reports.

In Phase 2, when funded, CARS-Delay MU may monitor the first two 2 N/A 7. miles in each direction of longer roadwork, to check for entering delay.

9 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Given Phase 2 funding, CARS-Delay MU may also allow operators to 2 N/A 8. create otherwise silent events when/where delays may currently be likely.

Given Phase 2 funding, CARS-Delay MU may monitor recurrent delays at 2 N/A 9. locations and times when and where they commonly occur.

Given funding, Phase 2 may also cover grouping clusters of Waze/DOT 2 N/A 10. reports to reduce Google queries and avoid end-user confusion.

As Priority 3 (not fully funded), CARS-Delay may also help to execute 3 N/A 11. statewide performance monitoring of traffic using 20-30 mile segments.

In Phase 3 (not yet funded), CARS-App/Vox reports may be added, using 3 N/A 12. approaches similar to those to be proposed for Waze slow vehicle reports.

In Phase 3 (not yet funded), CARS-Delay may also help assess the severity 3 N/A 13. of difficult winter driving conditions.

As Priority 4 (not yet funded), CARS-Delay may also help to find and 4 N/A 14. assess delays not yet associated with any known event report.

2.2 Approach

2.2.1 Included route designators and sections

CARS-Delay MU assessment shall begin its operation on major interstates 1 1.1.1 15. with cellular data coverage in deploying agency areas.*

CARS-Delay MU assessment shall subsequently be extended to cover 1-2 N/A 16. agency-selected, high-priority sections of designated CARS-Location highways.*

CARS-Delay MU shall maintain a list of highway route designators to be 1-2 N/A 17. included in the initial high-priority monitoring.

CARS-Delay MU shall maintain configuration tables showing the 1-2 N/A 18. beginning and end milepoint linear references of each high-priority section.

CARS-Delay SD shall maintain a configuration table of corridors defined 2 N/A 19. by O-D pairs5 and time periods of the weekday (morning and evening peaks).

5 O-D pairs are pairs of origin/destination, expressed as geolocations in decimal degrees understood by Google Directions. Each O-D pair defines the start and end of a commuter route that is active between defined times of day. 10 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only In Phase 3, other significant sections of road that regularly display Google 3 N/A 20. speeds may also be added to CARS-Delay MU.

2.2.2 Included event phrases (CARS-Delay MU)

CARS-Delay MU shall maintain a list of “triggering” event phrases, 1 1.1.1 21. common across all deployments, to mark events to be included in the delay assessments.*

To help manage the future configuration burden, there shall be no 1 1.1.1 22. individual state tables of included/excluded phases.

The initial-pilot triggering event phrase list shall include only a few (initially 1 1.1.1 23. 20-30) key phrase types commonly used in the participating states.

Monitored events shall be those that include one or more of the phrases 1 24. (not just key phrases) included in this CARS-Delay MU phrase table.

Initial phrases shall include the most commonly used agency roadwork 1 1.1.1 25. extent events (ITD funding), and crash/accident point reports (MN funding).

No agency winter reports or Vox reports shall be included in the Phase 1 1 1.1.1 26. work.

27. Night-time roadwork shall not be included in CARS-Delay Phase 1. 1 1.1.1

With Iowa funding, manual Waze-reported “traffic jam” and “car 1-2 N/A 28. accident” point events shall be added in Phase 1-2.

CARS-Delay MU shall be able to distinguish Waze-sourced events from 1-2 N/A 29. agency-sourced events, because the phrases shall be distinct.

Waze “car stopped on shoulder”, “hazard on shoulder”, “pothole” and 1-2 N/A 30. “police trap” reports shall not be included in any currently funded deployments.

Any Waze reports that originate from the CARS host state DOT shall be 1-2 N/A 31. excluded. (These are currently excluded from the Waze feed.)

Given funding, Waze “slow vehicle” events may also be included in 2 N/A 32. CARS-Delay MU (where CARS-Waze is deployed).

33. CARS-Delay SD shall not include any analysis of delays at events. 2 N/A

11 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Waze reports such as “Car stopped on road” and Wazers’ weather reports6 2-3 N/A 34. may be added in later phases, as funding permits.

With further funding, CARS operators could be able to create one-off 2-3 N/A 35. delay reports that will trigger CARS-Delay MU assessment algorithms.

With further funding, CARS operators could be able to create long-term 2-3 N/A 36. delay reports that will trigger CARS-Delay at specified times of the day/week.

In the future, new Waze road closure/blockage reports imported to N/A 37. CARS-Event may also be checked for delays.

2.2.3 Included event priorities (CARS-Delay MU)

Events with included phrase types having agency priority 1-5 shall be 1 1.1.1 38. initially considered for inclusion in CARS-Delay MU assessments.

The lower agency event-priority threshold for inclusion (initially priority 5) 1 1.1.1 39. shall be configurable on a statewide basis.

Based on the current delay measurement, CARS-Delay MU shall adjust 1 1.1.1 40. operator or CARS-Imports event priorities in the range 3-5 automatically.

A current assessment of no measured delay shall cause the CARS-Delay MU 1 1.1.1 41. event’s operational priority to be made Priority 5.

Measured delays of 2 to 4 minutes shall cause the CARS-Delay MU event’s 1 1.1.1 42. operational priority to be made Priority 4.

Measured delays of 5 or more minutes shall cause the CARS-Delay MU 1 1.1.1 43. event’s operational priority to be made Priority 3.

Priority 1, 2 and priority 6-10 events inclusive shall not have their operator 1 1.1.1 44. or phrase-based priorities adjusted by CARS-Delay MU.

2.2.4 Included times of day (CARS-Delay MU and SD)

In CARS-Delay MU, delay sampling shall only be carried out between 5 1 1.1.1 45. am and 9 pm local time (configurable for each state).*

In CARS-Delay SD, assessment shall be carried during two 7-hour periods 1-2 N/A 46. of the day (configurable), directionally based on the morning/evening peak periods.

6 Examples include reports like “Weather hazard”, “Hazard on road—white out” and “Recently formed ice”. 12 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Each CARS-Delay SD corridor shall be assigned to Period 1 (inbound) or 1-2 N/A 47. Period 2 (outbound), limiting its assessment period to 7 hours per day.

CARS-Delay SD Period 1 shall run from 5 am to 12 noon, and Period 2 1-2 N/A 48. from noon to 7 pm local time (system-wide configurable).

2.3 Delay Assessment

Delay shall be assessed by subtracting the returned “normal” Google travel 1 1.1.1 49. time from the reported time in current traffic.

Significant delays shall mean delays of >2 minutes (system-wide 1 1.1.1 50. configurable).

2.3.1 CARS-Delay MU

CARS-Delay MU delays shall be assessed for qualifying events located 1 1.1.1 51. wholly in delay-measurement highway sections, with start times in the past.

Where possible, delays shall be estimated by getting travel times between 1 1.1.1 52. points two miles either side of the event’s start and end locations.

If the road starts, ends, jumps or breaks within the two miles, the sampled 1 1.1.1 53. section shall be shortened so as to avoid the jump or missing roadway section.

In Phase 1, delays at all qualifying 1–way and 2-way events shall be 1 1.1.1 54. checked in both directions.

In Phase 2, if entering delays are assessed at long roadwork sections, delay 2 N/A 55. measurements may run from 2 miles ahead to 2 miles inside the roadwork.

In a later phase, delay may also be checked in further two-mile sections 3-4 N/A 56. ahead of events’ start points, to see if the monitored section should be extended.

In this context, the event’s “start” point shall be defined directionally, 3-4 N/A 57. being the first part of the event encountered in each driving direction.

2.3.2 Event list (CARS-Delay MU)

CARS-Delay MU shall maintain a dynamic list of all events that potentially 1 1.1.1 58. qualify for delay sampling.

Events in the list shall be ranked according to their probability histories of 1 1.1.1 59. having reported significant delay, as measured in previous samples.

13 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only CARS-Delay MU agencies can opt to use the CARS Group’s shared Google 1 1.1.1 60. Maps for Work license, or shall be able to fund and use an individual state license.

If the shared license is used for CARS-Delay MU, the top 40 events in the 1 1.1.1 61. dynamic list shall be able to be monitored for delay (configurable).

On weekdays between 7 am and 9 am, and again between 4:30 pm and 1 1.1.1 62. 6:30 pm, the above top 40 shall be increased to the top 60 events from the dynamic list.

Using the shared license, qualifying events in the top 40/60 will start by 1 1.1.1 63. having both of their directional delays sampled at 30-minute intervals (configurable).

If an individual agency license is used for CARS-Delay MU, the top 120 1 1.1.1 64. events in the dynamic list shall be able to be monitored for delay.

On weekdays between 6:30 am and 9 am, and again between 4 pm and 1 1.1.1 65. 6:30 pm, the above top 120 shall be increased to the top 200 events from the dynamic list.

Using an agency license, qualifying events in the top 120/200 will start by 1 1.1.1 66. having both of their directional delays sampled at 10-minute intervals (configurable).

Significant delay found in any sample shall cause that direction’s next 1 1.1.1 67. sampling interval to be halved (e.g., to 5/15 minutes, for agency/shared license use).

New qualifying events shall be added to the top of the list for their first 2 1 1.1.1 68. hours (configurable) to begin creating a delay probability history.

If they still exist, these events shall be added back to the top of the list on 1 1.1.1 69. the first available weekday, from 7 to 8 am, to further validate the delay history.

If they still exist, the same events shall also be added back to the top of the 1 1.1.1 70. list on the first available weekday, 5-6 pm, to further validate the delay history.

Potentially qualifying events shall carry two, new, incrementing quantities: 1 1.1.1  one recording the total number of directional delay measurements, 71. and  one recording the number of measurements showing significant delay.

14 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only The ratio of these two quantities shall be used to rank qualifying events in 1 1.1.1 72. the dynamic list.

73. Incrementing the quantities shall not change the event update number. 1 1.1.1

The quantities shall be visible (but not editable) in CARS 4/5 and shall not 1 1.1.1 74. be visible in any public-facing 511 medium.

Each agency’s instance of CARS-Delay shall maintain a daily record of the 1 1.1.1 75. last 30 days’ total Google Directions API delay queries for review by CR Ops staff.

2.3.3 New and edited reports

Unless events come into effect at night, qualifying new reports shall added 1 1.1.1 76. to the top of the dynamic list as soon as they appear in CARS-Event.

New reports taking effect at night shall be initially assessed for delay 1 1.1.1 77. starting 6 am on their first weekday, or at 8 am on their first weekend day (configurable).

78. Newly manually edited CARS events shall be treated as new reports. 1 1.1.1

Automated event description changes caused by CARS-Delay MU shall 1 1.1.1 79. not be treated as new or edited reports.

2.3.4 Events not currently being monitored for delay (CARS-Delay MU)

Potentially qualifying events not currently being monitored for delay shall 1 1.1.1 80. be checked for delay once each weekday morning and evening peak.

These checks shall take place between 8-9 am, and between 5-6 pm local 1 1.1.1 81. time.

If significant delays are found, the event shall be treated as if it were a 1 1.1.1 82. new/ newly edited event report.

2.3.5 CARS-Delay SD

CARS-Delay SD delay checks shall be carried out for pre-configured 1 N/A 83. corridors, during each corridor’s live assessment period.*

The design of CARS-Delay SD shall be based on San Diego using an 1 N/A 84. individual agency Google Maps for Work license.

In CARS-Delay SD, delays will be sampled at fixed 5-minute intervals 1 N/A 85. throughout each corridor’s live assessment period.

15 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only 2.4 Announcing Delays (CARS-Delay MU)

In CARS-Delay MU, quantified delay shall be announced before the rest of 1 1.1.1 86. the event descriptions entered by operators or created from event import systems.

87. Whenever presented to a user, these delays shall be attributed to Google. 1 1.1.1

Delays seen in one direction only shall be announced as in this example: 1 1.1.1 88. “Google shows a 6 minute delay eastbound. Look out for a crash.”

If there are delays in both directions, this becomes: “Google shows a 6 1 1.1.1 89. minute delay eastbound, and a 3 minute delay westbound. Look out for a crash.”

For Waze event delays, we shall say (for example): “Google shows a 6 1-2 N/A 90. minute delay eastbound. A Waze user has reported a crash.”

A “Google reports occasional delays” phrase shall be added to the end of 1 1.1.1 91. events not currently being monitored, where delays were seen 1%-10% of the time.

A “Google reports delays likely” phrase shall be added to the end of 1 1.1.1 92. events not currently being monitored, where delays have been observed >10% of the time.

No extra phrase shall be added to events not currently being monitored, 1 1.1.1 93. where delays have been observed <1% of the time.

The above “occasional/likely” phrases shall never be used at the same 1 1.1.1 94. time as a quantified delay announcement prior to the key phrase.

Automated phrase and delay quantity changes shall not increment the 1 1.1.1 95. event’s update counter.

These special CARS-Delay phrases/quantities shall not be made available 1 1.1.1 96. for use by CARS operators.

3. CARS-Delay System Design

In accordance with FHWA’s Systems Engineering Process, this detailed design section is illustrative, rather than definitive. The concepts described below may not all be supported in the final system. The final system may satisfy the functional requirements (Section 2 of this document) in other ways.

16 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Module testing and acceptance are based on meeting the functional requirements, rather than deploying the particular concepts and initial ideas of this section.

This draft addresses CARS-Delay MU Phase 1 and 1-2. The detailed design of later phases is TBD.

3.1 CARS-Delay MU Approach The purpose of CARS-Delay MU is to monitor and report delays associated with traffic events. Ideally, all events that could significantly impact drivers’ current trips would be monitored, with sufficiently frequent updates for the drivers to receive accurate information and take an alternative route if they can and so wish. However, it is also important not to keep checking low-impact events that have only a small chance of causing delay, which—if checked frequently—could run up large operating costs and discourage states from funding the monitoring bill to Google.

In its initial phases, CARS-Delay will therefore focus on a small, well defined group of 20-30 event phrases jointly chosen by participating agencies. The Phase 1 and 1-2 deployment will target “icon” events located on major roads whose overall extent is no greater than six miles (system-wide configurable). The initially targeted events shall include agency-511 and police-CAD reports, plus in Phase 1-2 manual social media reports from CARS-Waze (where deployed).

With Sacramento or other agencies’ funding (not yet certain), Phase 2 may cover automated Waze slow vehicle reports. In the future, CARS-App and/or CARS-Vox reports may be added to CARS- Delay, using similar approaches to those to be developed for manual “traffic jam” reports from Wazers and/or CARS operators.

4:15 pm, Feb 1 2015: Widespread slow traffic due to a major winter snow belt

In principle, delays could be measured over distances longer than six miles. But, unless slowdowns are very uniform—as shown above during a wide-area weather event—long measurement sections would give the user no idea of where to expect the actual slow vehicles. Most drivers will want to know the delay impact for their own, specific driving route, which may not include the whole extent of long roadwork sections. Phase 2 of CARS-Delay may check for entering delay at each end of long roadwork sections. Future versions of CARS-Delay may attempt to address even longer-extent events, by measuring very extensive delays in a series of successive sections. In principle, statewide monitoring may eventually be constructed from large numbers of (say) 20 to 30 mile segments.

17 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only CARS-Delay MU will begin by looking at major interstates; and then add other major highways with substantial traffic volumes on which agencies judge that delays are most likely to occur. Highways with limited cellular coverage shall be excluded from CARS-Delay monitoring sections.

3.1.1 Delay prediction Slowdowns measured over very long distances such as whole state roads do not give “current delay” answers in the Google Directions API. Instead, Google attempts delay predictions, not just giving the currently measured values. This can be shown by comparing delays indicated for short and long trips that eventually pass through the same current holdup. It appears that Google expects current delays located more than 90-100 minutes ahead of the route’s origin will probably have cleared by the time the motorist has traveled that far. Also, it appears that Google may assume current delays located perhaps 45 to 90 minutes ahead will have reduced during the driver’s journey.

Whole of Iowa’s I-80 westbound on a normal day (2/5/15)—4h 14m without traffic, plus 8 minutes of delay

4:25 pm, Feb 1: 23-minute “storm” delay, inside the first 90 mins of the trip. Delays are ignored west of Iowa City

Google’s current delay forecasting algorithm seems not to take account of the delay’s cause, or how long a delay has already lasted, as we see from the screenshot above taken during the major winter storm event of February 1, 2015. Despite the long-duration nature of this situation (>6 hours?), Google assumes that the severe weather delays will go away in the next 90 minutes.

Whole of Nebraska’s I-80 WB on a normal day (2/5/15)—6h 5m without traffic, plus 14 minutes of delay

18 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only A similar picture is shown by Nebraska screen shots of the same storm. The point after which delays are ignored seems to be near Seward (20 miles west of Lincoln). Seward is located about 65 minutes (75 miles) west of NDOR’s Missouri River I-80 start point under normal traffic conditions.

4:41 pm, February 1 2015: WB, 43 minutes of delay shown. Delays west of Seward (past Lincoln) are being ignored

Actual delays are long, especially from Lincoln to Kearney. Above, “red/brown” delays near Seward were made yellow

4:52 pm, February 1 2015: 1h 28m delay. Some “red” delays are shown; but delays west of Seward are still ignored

4:54 pm, February 1 2015: 1h 26m delay. Brown turns blue, west of Seward. Really, the road is totally blocked.

19 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only These screen shots suggest that a current (i.e., delayed) travel time limit of 90-100 minutes is in use, rather than a distance constraint. Above, yellow, red and brown delays west of Seward are ignored once the motorist has travelled about 100 minutes (on that day, only 25 miles) west from Lincoln. This suggests that (if statewide monitoring is implemented in later phases), individual delay measurement sections should be limited to current delay sections not exceeding (say) 45 minutes— or that very long delays/delays measured over long distances will not be accurately represented in CARS-Delay. On the other hand, it could also be argued that Google’s guess that current delays will tend to go away is not an unreasonable approach—at least, for use in 511 information systems. The winter storm delay shown above is technically infinite, as the road is completely blocked by a jackknifed semi-trailer. Obviously, a time will eventually come when the road will actually reopen. It would not make sense to predict delays of (say) 12 hours or longer.

These data also suggest that Google is not yet reflecting event type in its delay duration predictions. In fact Google may have no knowledge of the major crash that has caused the very long delays. Waze has some information, but shows much confusion. There is an urgent need for aggregation of the various information sources (report grouping), as is proposed for future phases of CARS-Delay, after more states have joined.

20 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only

3.1.2 Sticking to the monitored road—use of intermediate waypoints Another issue that must be addressed in CARS-Delay is preventing Google from taking detours off the road being monitored. Below we see Google rerouting the westbound user off I-80 onto the parallel US 6. Google then has the driver rejoin I-80 shortly before the 100-minute delay “horizon” is reached near Seward, a location where US 6 moves much further south of I-80. A similar recommendation to use US 6 is made for eastbound I-80 traffic, with a calculated 82-minute saving.

Westbound detour recommended via US 6

Eastbound detour recommended via US 6

From the driver’s viewpoint, there are two separate problems with Google’s US 6 routing recommendations. One is that the westbound detour puts drivers back on I-80 before passing the jackknifed semi-trailer, which is totally blocking the westbound lanes west of Seward. This happens because of Google’s apparent “ignore delays over 90-100 minutes away” rule. The other problem—

21 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only even worse—is that US 6 had long been completely closed due to drifting snow. Google sees no delays on US 6 because there are no probe vehicles on US 6.7

Google’s detours often represent good advice, and in TG-Routes/TG-511 developed for San Diego, the alternative route and its delay are actually presented to the user. In this project, however, CARS- Delay’s task is to monitor conditions on a defined route, making the detours a distraction from the real focus of this project. Below is a crash blocking I-74 EB in Iowa/Illinois:

From the three examples above, we learn that CARS-Delay must “force” Google Directions to stay on the selected road. The approach to be adopted in CARS-Delay (MU and SD) shall use intermediate waypoint geolocations to influence the route without adding a stopover, by prefixing the intermediate waypoints with “via:” Google states that waypoints prefixed with via: do not add an additional leg to the route, and do not prevent driving delays being returned. A maximum of 23 waypoints per route can be included by Google Maps API for Work customers, such that up to 21 intermediate waypoints could if necessary be transmitted. In Phase 1, we shall place a “soft” via:

7 It is interesting to imagine what an autonomous vehicle would do in this example, were it not connected to a future “digital 511”. 22 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only waypoint every mile from the origin to the destination point (spacing system-wide configurable) measured in the current travel direction. The final gap in this waypoint sequence will generally be less than one mile.

By default, the Directions API calculates a route through the provided waypoints in their given order. Optionally, CARS-Delay could pass optimize:true as the first argument within the waypoints parameter to allow the Directions service to optimize the provided route by rearranging the waypoints in a more efficient order. This optimization (an application of the Travelling Salesman Problem) is not required in CARS-Delay and—for speed of response and the reduction of load on Google’s servers—shall not be utilized. The CARS-Delay origin, destination and intermediate waypoints will come from OSM CARS Location tables whose sequential, tabular structure and CARS linear references (not DOT miles) will ensure that intermediate waypoints are arranged in the correct sequence and with the required (approximate) spacing.

3.2 Roadways to monitor

CARS-Delay MU will start by focusing a relatively high level of monitoring on the most strategically significant state highways. In the initial release, this will be limited to the major interstates. After that, strategic roads will include highways that carry most traffic, or (perhaps) are used by long- distance travelers. These priority routes will also continue to be given the closest scrutiny in the longer term. We shall call these major highways “CARS-Delay 1” or “CD1” roads, being highways or major parts of highways thought to have a relatively high probability of delays at incidents and roadwork.

“CARS-Delay 2” highways are all other state roads that typically show Google traffic (painted speeds) on substantial sections—or, more often, on the whole road—during weekday business hours. In the future, CD2 roads may also be worth monitoring, in a fully developed CARS-Delay. However, the numbers of queries this could generate may require each state to have its own Google Maps for Work enterprise license—at under $20,000 per year, certainly a potentially affordable future development. CD2 roads will not be included in CARS-Delay Phase 1.

Below, Minnesota has been chosen to provide an example of the route coverage that could be achieved in CARS-Delay MU. The table below suggests that about 52 Mn/DOT highways out of a total of 201 state highways currently listed in the CARS Segment Tool (ignoring the number range MN 800-999) have good Google painted speeds coverage, and could therefore potentially be classed as “CARS-Delay 1” or “CARS-Delay 2”. Of these 52, some 40 have cellular speeds coverage for their whole lengths, and about 12 more have coverage of key parts.

The rest, called “CARS-Delay 3” roads, have only patchy or often no Google painted speed indications. In the initial deployment, we shall assume that meaningful delays would not be returned on those roads even if they were included in CARS-Delay. There are about 150 such minor state routes in Minnesota, as well as significant sections of a further 12 state highways with minimal or no Google speeds coverage. These routes are typically low-volume routes where delays are probably unlikely. These “CD3” routes are planned for exclusion from CARS-Delay.

23 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only States will need to help Castle Rock select the highways to be included in their initial CARS-Delay pilots. For reasons of conciseness, these other states’ roadway lists will not all be added to this document.

3.2.1 Minnesota’s suggested CD1 highways In Minnesota, we propose that CARS-Delay begin with I-35, I-35E, I-35W, I-90, I-94, I-394, I-494 and I-694. After that, a full set of suggested “CARS-Delay 1” routes is marked in the table below as “High” priority. Some CD1 routes are proposed for coverage over their whole lengths (20 routes), and others in parts (16 routes). The “part” route sections cross the Twin Cities, Rochester or St Cloud. Mn/DOT staff should check this list and decide on any required additions or deletions.

The entire list tabulated below comprises all Minnesota “CD1” and “CD2” routes / route sections currently identified in Minnesota. Note that the list of CD1-CD2 routes may increase as cellular phone coverage spreads, as traffic volumes increase, or as smartphone penetration continues to grow. We suggest that CARS-Delay coverage should be reviewed on roughly a three-year cycle.

Similar lists will need to be drawn up by each participating state in order to decide the highways to be initially covered by CARS-Delay. These would also be the highways that continue to receive the closest scrutiny in the longer term.

MN From To From To Cell Priority “CD1” Route cover highways I-35 IA I-35E/W I-35E/W Duluth Whole Immediate I-35E I-35 I-35 Whole Immediate I-35W I-35 I-35 Whole Immediate I-90 SD WI Whole Immediate I-94 ND WI Whole Immediate I-394 I-494 US 952A Whole Immediate I-494 Missi. Br. I-94 I-94 Missi. Br. Whole Immediate I-535 I-35 WI Whole I-694 I-94 I-94 Whole Immediate US 10 ND WI Whole High (metro/Cloud) US 12 US 71 I-394/494 Part High (metro) US 14 MN 15 MN 42 US 61 I-90 Parts High (Rochester) US 52 IA I-94 Whole High (metro/Roch) US 53 I-35/535 US 169 Part US 61 WI I-35 Part High (metro) US 63 IA MN 247 Part High (Rochester) US 169 MN 60 US 10 US 10 US 2 Parts High (metro area) US 212 MN 23 MN 62 Part High (metro area) US 218 I-90 US 14 Part MN 5 MN 19/22 US 212 I-494 MN 36 Whole High (metro area) MN 13 MN 19 MN 149 Part High (metro area) MN 15 MN 55 US 10 Part High (St Cloud) MN 21 MN 19 US 169 Part

24 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only MN 23 US 71 MN 65 Part High (St Cloud) MN 36 I-35W MN 95 Whole High MN 41 US 169 MN 7 Whole High MN 47 MN 65 US 10 Part High (metro area) MN 50 MN 3 US 61 Whole MN 51 MN 5 I-694 Whole High MN 55 MN 22 US 61 Part High (metro area) MN 62 I-494 MN 55 Part High (metro area) MN 65 I-35W MN 95 Part High (metro area) MN 77 CR 38 MN 62 Whole High MN 95 MN 23 US 61 Whole MN 96 US 61 MN 95 Whole MN 97 I-35 MN 95 Whole MN 100 I-494 I-694 Whole High MN 101 MN 812C MN 5 I-94 US Whole 10/169 MN 110 MN 55 I-494 Whole High MN 120 I-94 MN 244 Whole High MN 121 I-35W Lindale Av Whole High MN 149 MN 3 MN 55 MN 55 MN 5 Whole High MN 156 I-494 US 52 Whole MN 194 US 2 US 53 US 53 I-35 Whole MN 241 CR 19 I-94 Whole MN 243 MN 95 WI Whole MN 244 MN 120 MN 96 Whole MN 252 I-94 MN 610 Whole High MN 280 I-94 US 36 Whole High MN 282 US 169 MN 13 Whole MN 284 US 212 MN 5 Whole MN 301 US 10 CR 8 Whole MN 316 US 61 US 61 Whole MN 336 I-94 US 10 Whole MN 371 US 10 MN 200 Part MN 610 US 169 US 10 Whole High

Mn/DOT roads in the range 800-899 and 900-999 are mostly short urban sections that have been left out of the table above. At a recent LRS meeting it was indicated that these routes may soon no longer be classified as numbered state highways. In the future, a decision will be required on how these roads should be treated in CARS-Delay. Some are in populated urban areas that could in principle be classified as “CARS-Delay 1” or “CARS-Delay 2”.

Note that for CARS-Delay to work effectively in both travel directions, all the high priority “CARS- Delay 1” routes will need to have both positive and negative carriageway centerlines imported from Open Street Maps under the ongoing Maintenance Upgrades (MU) program. CARS-Delay will require accurate centerlines for each directional carriageway, which OSM imports will provide.

25 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only

3.3 Phrases to be included

In CARS-Delay, road work, lane closure and accident/incident events that are likely to cause delay will be determined from the event phrases. To reduce maintenance overheads, CARS-Delay shall load its phrases to be checked from a single, common, master phrase library used across all states. To be checked for delays, the event’s description must contain one or more of the following phrases.

3.3.1 Accident/incident phrases Minnesota’s initial focus in this work includes the automation of 511 delay reporting at incidents and crashes originating from CARS-CAD. Many of the accident/incident phrases below are rarely used (gray text), and leaving out all but the black text phrases is proposed initially. Eventually, however, once data are available on Google Directions usage levels, and for states that use their own Google Maps for Work license, CARS-Delay MU could check all the accident/incident phrases tabulated below—other than those in red text.

Note that even red text incidents such as “Abandoned vehicle” will be checked for delay if accompanied by a qualifying CARS-Delay phrase such as “lane closed.”

Abandoned vehicle Crash involving a truck Numerous crashes Accident Crash involving hazardous materials Oil spill Accident cleared Derailed train Overheight vehicle impact Accident investigation work Disabled bus Overturned bus Accident involving a bicycle Disabled semi trailer Overturned semi trailer Accident involving a bus Disabled train Overturned truck Accident involving a motorcycle Disabled truck Overturned vehicle Accident involving a pedestrian Disabled vehicle Primary accident Accident involving a semi trailer Earlier accident Rescue and recovery work in progress Accident involving a train Earlier crash Secondary accident Accident involving a truck Fuel spill Secondary crash Accident involving hazardous materials Hazardous materials spill Serious accident Acid spill Incident Serious crash Boat fire Incident cleared Spillage occurring from moving vehicle Bus stuck under bridge Injury accident Spilled load Chemical spill Injury crash Stalled vehicle Crash Jackknifed semi trailer Stuck vehicle Crash cleared Jackknifed trailer Toxic spill Crash investigation work Jackknifed trailer home Traffic incident Crash involving a bicycle Medical emergency Truck stuck under bridge Crash involving a bus Minor accident Vehicle in water Crash involving a motorcycle Minor crash Vehicle on fire Crash involving a pedestrian Multi vehicle crash Vehicle spun out Crash involving a semi trailer Multi-vehicle accident Vehicles slowing to look at accident Crash involving a train Numerous accidents Vehicles slowing to look at crash

For Phase 2, the Waze App uses two accident phrases—minor accident and major accident; sometimes accompanied by free text. CARS will map these to new TMDD phrases such as “a Waze user has reported a minor accident” and “a Waze user has reported a major accident”; and that the free text will also be included in the imported CARS event. Both phrases will trigger CARS-Delay.

26 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only 3.3.2 Roadwork phrases Idaho’s initial work in CARS-Delay is focused upon roadwork, including lane closure events. CARS-Delay shall load its phrases to be checked from a single, common, master phrase library used across all states. Initially, while a shared Google Maps license is in use, only the black text phrases shall be checked. Later, all current roadwork phrases will be used in CARS-Delay, except for those shown below in red.

Avalanche control activities Narrow lanes Road reconstruction Blasting New road construction layout Road work clearance in progress Bridge construction New road layout Road work cleared Bridge demolition work Night time construction work Roadside cleanup crew Bridge inspection work Normal road layout restored Single line traffic: alternating directions Bridge maintenance operations Normal traffic lanes restored Street cleaning Brush control Opposing traffic Temporary lane markings Construction traffic merging Paving operations Temporary traffic lights Construction work Planned roadwork Utility work Emergency maintenance Road construction Water main work Emergency repairs Road construction cleared Work in the median Gas main work Road maintenance cleared Work on the shoulder Long term road construction Road maintenance operations Work on underground cables Major road construction Road marking operations Work on underground services

3.3.3 Lane blockage/closure phrases Lane closures and unexpected blockages often cause delay, and shall be included in the initial launch of CARS-Delay. The list of phrases to be included is presented below.

Note that CARS-Delay is not being designed to handle long-term road closures or total ramp closures at this time. While such closures may sometimes cause delays, the mainline delay locations are unpredictable, most likely occurring on or before the detour route or on alternative ramps—if delays occur at all. Often the effect of ramp closures is driver inconvenience (at having to take a longer route), rather than obvious traffic congestion. Therefore the delay consequences of complete road closures and ramp closures are too complex for fully automated analysis and will not be included in the current CARS-Delay development.

In future enhancements of CARS-Delay, it is expected that operators will be able to create dummy events at points where delays have been observed, so that CARS Delay will know where to look for traffic problems including closure-related issues. Finally, in Waze states, Waze users can report traffic jams wherever they occur, including delays on detours and alternative ramps.

Closed to traffic Rest area closed Two right lanes of exit ramp blocked Closed Pedestrian trails closed Left lane of exit ramp blocked Closed ahead Through lanes closed Two left lanes of exit ramp blocked Closed intermittently Two center lanes are closed Lane closed Closed for repairs Left exit ramp closed Bridge closed Closed for the season Shoulder closed Ramp blocked Blocked Customs point open Closed to all traffic except emergency vehicles Blocked ahead Customs point closed Intersecting road closed Reduced to one lane Right lane blocked Local road closures in area Reduced to two lanes Two right lanes blocked Nearby service road closed Reduced to three lanes Three right lanes blocked All lanes blocked Collapse Four right lanes blocked Center lane blocked Out Five right lanes blocked Potential road closure Open to traffic Left lane blocked Sidewalk closed 27 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Open Two left lanes blocked Left lane of exit ramp closed Reopened to traffic Three left lanes blocked Right lane of exit ramp closed Clearing Four left lanes blocked Left turn bay closed Cleared Five left lanes blocked Right turn bay closed Right lane closed Left center lane blocked Detour in operation Left lane closed Right center lane blocked Road closure Center lane closed Two center lanes blocked Lane closed Right shoulder closed Three center lanes blocked Lane blocked Left shoulder closed Four center lanes blocked Intermittent lane closure Exit ramp closed Five center lanes blocked Alternating lane closures Entrance ramp closed Right lane of exit ramp blocked

3.3.4 Traffic conditions phrases In the Idaho deployment, automated traffic speed monitoring systems can trigger slow traffic events. Potentially, these agency slow traffic events may contradict CARS-Delay events. However, in the initial launch of CARS-Delay, it is proposed to allow duplications to occur, in order to obtain information about the comparative performance of the two systems. Initially, when both systems trigger, two warnings (e.g., Google shows 4 minutes of delay. Slow traffic.”) may be acceptable. Should the occasional double warning prove unhelpful in the longer term, one or other system can be switched off for these stretches of road. Eventually, a slow traffic warning without a measured Google delay might be better ignored by 511, whether the slow traffic warning comes from Bluetoad or from automated Waze slow vehicle events.

In Iowa, due to intermittent detector faults, these slow traffic indications are carried only on LB- Web, where Google Traffic Speed maps are not available. Until recently, Waze picked up these events and presented them to its own users. Google Traffic speed maps suggested that the reported delays were usually not real. Now, Iowa has turned off the Wavetronics speed events entirely.

One option for a future version of CARS-Delay would be to use slow traffic alerts to trigger a CARS-Delay measurement in the area, without showing the automated slow traffic event itself. In this way, automated slow traffic events could be treated like Wazer “Traffic Jam” reports, requiring verification before being announced to the public.

3.4 Grouping events

When further states join CARS-Delay MU, CARS-Delay shall consolidate events that overlap or lie within a mile of one another, unless the resulting delay event would exceed 6 miles in length (system wide configurable). This work will require some significant design effort which will be documented in this section, and through additional system requirements.

3.5 Find delay start and end coordinates

This section defines how CARS-Delay will find the positive- and negative-direction delay measurement end points for extent events such as roadwork. The goal is to place the delay “pins” about two miles outside the event’s CARS-Location extent, separately on each directional carriageway. For two-way road sections, both directions can use the same delay “pin”.

28 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Divided highways require separate pins for each direction because without them, the (typically negative direction) trip starts off on the positive carriageway, heading in the wrong direction. Google then finds a place where a U-turn can be made and comes back along the negative carriageway before overshooting the required end point and making a second U-turn. On freeways this can add many miles (and many unwanted delays) to the measurement, and is unacceptable.

Traditional CARS centerline points can be well off the actual Google Maps carriageways. This can cause delay calculations to take unpredictable and inappropriate routes. At an overpass or underpass, the CARS centerline points can even be closer to Google Maps centerline points of the non- connecting minor road than they are to any point on the monitored highway. These situations lead to chaotic routes which may involve multiple inappropriate legs in addition to (or instead of) the single leg we are trying to measure. To get around this problem, we need to import OSM points for each carriageway, and use these rather than traditional CARS centerline points. Usually the OSM carriageway centerlines are close enough to the Google carriageway centerlines for a correct route to be found; and if they are not, they can be corrected and re-imported.

For CARS-Delay, therefore, it is required that all CD1 delay monitoring routes and route sections shall have had their Display Route Points imported from OSM, for both positive and negative travel directions. It is also required that CARS linear references shall have been correctly calculated by measuring distances between points along these polylines (and not imported from state sources, which sometimes allow jumps or breaks with incorrect distances). State imports shall be limited to the CARS DOT miles field, and shall not be used in CARS-Delay MU.

The lat-longs of delay measurement “pins” shall be found from CARS-Location Display Route Points by adding/subtracting their linear references, which will themselves have been found using a method of “join the dots”, measuring distance from point to point along the carriageway way centerlines—or a centerline point at which the highway jumps/breaks, whichever is reached sooner.

Left are the CARS 4 end points for an Idaho “road construction” event. The event (which overlaps with a second roadwork) begins at linear reference 52.796. If there are no intervening jumps, the western delay pin should be placed near linear reference 50.796. The actual point could be an OSM centerline point either nearest to, or (say) the first point prior to the required linear reference. As the required LR is somewhat arbitrary, it is not important which actual OSM point is chosen. Unlike CARS centerline points (which can be a mile apart in Idaho), OSM points rarely exceed 100 meter intervals.

29 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only

Roadwork on I-84: Westernmost event location at LR 52.796 (yellow pin)

The westernmost roadwork event, analyzed above, overlaps with a second CARS 4 “road construction” event, further east. Until more states fund CARS-Delay MU, event merging will not be attempted. Thus, the downstream point for CARS-Delay measurement is a positive direction OSM carriageway centerline point just past LR 57.83 (i.e., 55.83 plus 2 miles).8

The westbound delay shall be found by using the same approach applied to the negative direction Display Route Points.

8 Note that in the absence of OSM imports, the LR values shown in the screenshots above are purely illustrative. They are not the final LRs that will have been calculated by measuring the spacings between OSM nodes on the carriageway centerlines. 30 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only 3.6 Directions API https://developers.google.com/maps/documentation/directions/#Introduction

The Google Directions API calculates directions between locations using an HTTP request. Directions may specify origins, destinations and waypoints either as text strings (e.g. "Chicago, IL") or as latitude/longitude coordinates. The CARS-Delay functions specified here will use pairs of lat- long coordinates.

The Directions service is designed for calculating directions for static (known in advance) addresses for placement of application content on a map. In our case, we have pre-existing CARS events, for which delays will be calculated and made available to users.

The Directions API is not designed to respond in real time to user input, as required for personalized CARS-Delay in TG-Web. For these dynamic, individual directions calculations, Google suggests that the use of the JavaScript API V3 Directions Service, per TG-Routes.

3.6.1 Efficient design Google notes that calculating directions is a time- and resource-intensive task. Whenever possible, Google requests that we calculate known addresses ahead of time using the Directions API, and store the results in a temporary cache of our own design. In this SDD, CARS-Delay MU will calculate delays in advance of users’ 511 information requests and store the delay results in CARS- Event.

Initially, the default approach is for CARS-Delay to use Castle Rock’s Google Maps API for Work license.9 This allows 100,000 directions requests per 24 hour period, with up to 23 waypoints allowed in each request. However, intermediate waypoints other than “via:” cannot be used in driving directions that return the duration_in_traffic field. So, each delay check will require its own request. With the “Maps for Work” license, we are limited to 10 requests per second, and 100,000 requests per 24 hour period. One of the goals of CARS-Delay could be to use up most or all of the allowable delay requests per day within the limits of the current “Maps for Work” license. Some of the requests will be used by personalized delay users of TG-511 and TG-Routes. However, these users are expected to be relatively few in number, at least initially. Therefore, the challenge is to share out most or all the remaining requests between participating agencies and to use them as efficiently as possible in determining the locations and severities of delay across the various agencies’ networks. There are 86,400 seconds in a day, so running CARS Delay at the maximum rate allowed by Google 24/7 would consume 864,000 requests per day—between eight and nine times the allowable amount (without buying a second license, or negotiating extra payments for the license that we have). Another way to view this is that we could run CARS-Delay at the maximum allowed speed of 10 requests per second for about 2 hours 45 minutes per day, if there were no use at all at other times.

9 However, states can provide their own license details from the start and be freed from most limits on phrases and numbers of events being monitored. 31 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only Initially we expect that some states will share the single existing license, but that a better option is for heavy CARS-Delay user agencies to each use their own “Maps for Work” license.

3.6.2 Shared delay license The maximum rate of requests could potentially create conflicts between personalized requests in TG-511 and TG-Routes (which will probably be clustered around morning and evening rush hours) and general requests in CARS-Delay (which might also be looking for more delays around busy periods). We should assume that TG-511 requests need to be answered immediately, taking top priority, and that TG-Routes requests are almost as urgent. CARS-Delay requests should ideally be fitted in around the personalized requests.

Delay My 511 CARS 4 2011- 2012- 2013- 3 YEAR Agency requests delay Delay 2012 2013 2014 AVERAGE%* /day requests requests Idaho 30.39% 29.36% 17.98% 26.2% 26,200 2,500 25,000 Indiana 4.74% 4.12% 3.40% 4.1% 4,100 2,500 Iowa 20.74% 24.49% 39.05% 28.4% 28,400 2,500 25,000 Kentucky 3.07% 2.39% 2.45% 2.7% 2,700 2,500 Louisiana* 4.21% 4.07% 1.40% 3.3% 3,300 2,500 Maine 0.59% 0.71% 0.57% 0.6% 600 2,500 2,500 Minnesota* 24.56% 30.48% 22.47% 26.1% 26,100 2,500 25,000 New 0.63% 1.02% 0.61% 0.8% 800 2,500 2,500 Hampshire Rhode Island 0.03% 0.06% 0.09% 0.1% 100 2,500 2,500 SACOG* 7.51% 3.30% 11.98% 7.7% 7,700 2,500 10,000 SANDAG* n/a n/a n/a n/a n/a Total 100.00% 100,000

States can reduce the risk of slow response to personalized delay services by using their own Google Maps for Work licenses. We assume that many states already own their own license and are probably using very little (if any) of their current daily Directions API query ration. By providing Castle Rock with their license details, states can substantially improve the levels of service they can obtain from CARS-Delay MU in terms of response times, query intervals, and numbers of events that can simultaneously be monitored.

32 Final CARS-Delay_SystemDesign_18m_du.docx Confidential. Limited Circulation Document. Listed Agencies Only