Smart Work Zone Subgroup

June 14, 2021

Purpose

• This Subgroup will focus on adding optional objects and properties related to smart work zone data to the WZDx Specification. Specifically, the subgroup will be extending the existing static work zone information to include real-time metrics and various field devices related to smart work zones.

Agenda

• Introduce Co-Chairs and Review Subgroup Purpose, Scope and Objectives for this Subgroup.
• Discussion of Smart Work Zones
• Overview of the New Branch on GitHub Dedicated to Smart Work Zones
• Action Items and Next Steps

Scope

• Extend the WZDx Specification to include data elements related to Smart Work Zones ("smart data").
• Implement “smart data” through a new type of road event, i.e., a "smart work zone" road event.
• Define field device configuration information and dynamic metrics as well as where to include the information in the WZDx specification.
• Answer questions regarding the smart work zone event type and field devices.

Objectives

• Create a new branch on the existing open-source WZDx GitHub repository site where the smart work zones subgroup changes will be implemented as well as an issue/PR “label” for content related to smart work zones.
• Define the required fields and data sources for road event-level smart work zone data. Organize smart data in a new road event type, i.e., "smart-work-zone," which is a superset of the "work-zone" road event type already in the WZDx Specification.
• Define smart work zone field device types and configuration details as well as device data (such as health status and operational metrics) for each device type.
• Develop documentation describing the new fields as well as how the smart work zone event type should be used and how it specifically fits into the context of the WZDx Specification.
• Develop examples and JSON schema validation for the new smart work zone and field device information.

Activities and Milestones - see charter

• Item 1: Hold Kick-Off meeting for the WZDx Smart Work Zones Subgroup – June 14, 2021
• Item 2: Use MassDOT Vendor API specification as the base for discussion and formation of a draft for the WZDx smart work zone and field device objects – July 19, 2021
• Item 3: Revise draft smart work zone and field device objects and create GitHub issues for each new object – August 16, 2021
• Item 4: Create pull requests (PRs) from issues and group discussion which implement the desired new features supporting smart work zones and field devices – September 20, 2021
• Item 5: Finalize pull requests, perform QA/QC, and merge to the base smart work zones branch containing all the proposed changes related to smart work zones – October 18, 2021
• Item 6: Present all proposed changes related to smart work zones to WZDWG – October 28, 2021

Discussion of Smart Work Zones

Define the field device and traffic metrics that should be collected in a uniform/consistent standardized form.

Review of MassDOT’s Vendor API Document

• Work Zone Project and road event definitions (modeled after existing WZDx)
• Field Device Configuration (DMS, CCTV, and VDS properties, CCTV presets)
• Road Event Dynamic Metrics (volume, travel time, delay, avg speed, capacity, free flow speed, length of queue, avg occupancy)
• Field Device Dynamic Metrics (DMS, VDS, CCTV)

Demo of MassDOT’s Smart Work Zone Manager (SWZM) (Jacob Brady)

• System Demo of User Interface (UI)
• All static data in SWZM is based on WZDx
• Overview of existing dynamic Smart Work Zones captured

Discussion of Smart Work Zones (led by Neil Boudreau and Todd Foster)

• What other field device and traffic metrics should be collected in a uniform/consistent standardized form?
• What is missing?
• What is important to you?

Jeremy Agulnek: Managed lane traffic alerts (that control lane closures). Permanent managed lane devices, if they happen to be in work zone. Temporary gating should be considered. Weather related information, over lay on a map layer (wet, wind, snow, fog, etc). Bring elements together through a geofence for the work zone.

Vinod Chandran: Platform implanted into an application. All kinds of companies sensors, look at individual devices. MassDOT vendor API should be generically defined, open API, not vendor specific. Environmental sensors should be included.

Kelly Wells: Safety Service Patrol presence?

Skyler Knickerbocker: Iowa has sent out a draft protocol for connected temporary signals that would be similar to the smart arrow board protocol. All device inputs to overall system, used to start/end coordinates. Identify devices that support inputs into overall system.

Unknown: Monitor line of cones not just first and last cone. Not always about devices. Road width and low vertical clearance are also important.

Unknown: Need to keep in mind the value to the general consumer. What is the meaning from the devices? What are the use cases we are trying to address? Data to deliver from this angle to consumers/customers.

Donna Clark: worker presence devices and vehicle entering systems would be important to ATSSA.

Jianming Ma: There are a few additional data you might want to consider in smart work zones: vertical clearance, entry of construction equipment, and incident info. I understand that these may not apply to every work zone.

Clayton Burke: Mobile Maintenance Operations

Ben A: CDOT - three more – Over height, over width sensors, temp ramp metering, Mobile MVDR, Late merge devices,

Peter Stresino: Image Snapshots at merge locations to verify queue and /or for emergency response.

Russ Holt: In line with Vinod's input, and this may be a few years away: But in theory any "system user" data that will be made readily and routinely available in work zones (e.g., from CVs). But aside from that you got a lot covered, and glad folks are noting signals, AFADs, lane controls/gates, and even SSP vehicles... understand we are just starting/initial steps

David Rush: Automated Speed Enforcement

Ross Sheckler: So, add...temporary rumble strips, pavement marking trucks, marking removal trucks, crash trucks, barrier wall, etc. This information can show up through connected equipment.

Jianming Ma: It's important to capture any unusual situations that could happen in work zones, such as low vertical clearance, entry of construction equipment, and incidents.

Adam Carreon: By its nature, most elements of work zones are unusual.

Russ Holt: Probably makes sense to focus on the "basic" traffic control data first and foremost (the stuff for which public agencies are the owner, and which private industry really wants); this is in line with the push behind the whole WZDx effort as i understand. Great steps MA and IA to date

WZDx on GitHub, Live Demo (Jacob Brady)

• The smart work zone data will be developed on a branch named smart-work-zones based on the existing WZDx specification for static data. SWZ related issue pull requests will be labeled with “Smart Work Zones”.

Action Items and Next Steps

1. Email [email protected] if you want to be a member of this subgroup and you are not on the current roster.
2. Provide feedback on smart work zone data (you) want to collect.
3. Share MassDOT vendor API to subgroup members.
4. Review and send comment on the MassDOT vendor API.

Attendees

• State of Colorado – Benjamin Acimovic*
• Haas Alert – Jeremy Agulnek
• Navjoy – Ethan Alexander
• CeVe – David Aylesworth
• Ver-Mac – Todd Foster*
• WSDOT – Justin Belk
• South Dakota DOT – Christina Bennett
• Colorado DOT – Manjari Bhat
• Panasonic Corporation of North America – Ryan Blake
• IBI Group – Jacob Brady
• IBI Group – Michelle Boucher
• Massachusetts Department of Transportation – Neil Boudreau*
• IowaDOT – Clayton Burke
• Arizona DOT – Adam Carreon
• Navjoy, Inc. – Vinod Chandran
• University of Wisconsin – Yang Cheng
• ATSSA – Donna Clark
• DKS Associates – Alan Clelland
• The Sanborn Map Company, Inc. – John Copple
• Neaera Consulting – Tony English
• Utah Department of Transportation – Chuck Felice
• Delaware DOT – James Graham
• WSDOT – Steve Haapala
• Woolpert – Michael Hanowsky
• Navjoy, Inc. – Justin Healey
• Navjoy, Inc. – Marc Russell
• Ohio DOT – Nicholas Hegemier
• QLynx Technologies – Devorah Henderson
• Open Mobility Foundation - Jascha Franklin-Hodge
• Rhode Island DOT – Russell Holt
• HERE technologies – Weimin Huang
• TomTom – Robert Hoyler
• Paul Jodoin - FHWA
• Iowa State University – Skylar Knickerbocker
• Washington State DOT – Toy Leingang
• TxDOT – Jianming Ma
• Ohio DOT – Michael Meeks
• Hawaii DOT – Maaza Mekuria
• Ohio DOT – Chad Mann
• Minnesota Department of Transportation – Michelle Moser
• Minnesota Department of Transportation – Mildford (Ted) Ulven*
• Minnesota Department of Transportation – Catherine Huebsch
• Michigan Department of Transportation – Meredith Nelson
• Illinois DOT – Alec Paoni
• PA Turnpike – Christopher Parker
• Tennessee DOT – Jason Qucksall
• Virginia DOT – David Rush
• Kyra Solutions – Satyam Patel
• iCone Products LLC – Ross Sheckler
• Wisconsin DOT – Erin Schwark
• Iowa DOT – Dan Sprengeler
• Iowa DOT – Sinclair Stolle
• Illinois DOT - Peter Stresino
• Hillsborough County – William Twaite
• Austin Transportation Department – Luke Urie
• Castle Rock ITS – Kristin Virshbo
• North Carolina Department of Transportation – Kelly Wells
• Tx DOT – Beverly West
• Inrix – Jim Williams
• Maryland DOT – Hua Xiang
• TxDOT – Reyna Zeke
• Volpe – Molly Behan
• Volpe – Hadrian Merced Hernandez
• Volpe – Nate Deshmuckh-Towery
• Volpe – Mark Mockett
• Booz Allen Hamilton – Mahsa Ettefagh