Worker Presence Subgroup meeting, 2022 04 11 - usdot-jpo-ode/wzdx GitHub Wiki

Date: April 11, 2022

• Share lessons learned from first data consumer interviews.
• Discuss how to implement new worker presence object in WZDx feeds.

• Sign-in and Welcome
• General Updates
• Worker Presence User Stories
• Data Consumer Interviews
• Implementing New Worker Presence Object
• Action Items and Next Steps

• Meeting presentation

Worker Presence co-chairs presented at 3 conferences/meetings

• ATSSA Annual Convention - Serge and Ben presented at a WZDx workshop and a couple committee meetings
• AUVSI Automated Trucking committee - Kristin and Luke shared what the group is working on. Members of the committee are interested in engaging.
• Minnesota CAV Innovation Alliance - Kristin presented to their monthly meeting to explore and investigate developments in connected and automated vehicles

New GitHub issues - two related to worker presence

• Extending the MarkedLocation enumerated type for worker locations - the new "wearable" enumeration would allow SwzDeviceFeed to share where workers are within a work zone
• The WorkerPresence object on the WZDxFeed has a field for the "method" used to define how a data producer knows that workers are present. This issue will contain discussion about how to refine the options for that property and close the gap with the SwzDeviceFeed

User stories are a way to communicate how different types of users are going to use the system or its features

• Not necessarily an end goal or requirement, but a unit of what can be done from the user's perspective
• Enables collaboration and story-driven solutions The general structure is "As the <user type>, I shall be able to know <this information> so that I can <take an action>
• Example: As the vehicle OEM, I shall be able to know if workers are present or not on a stretch of roadway so that I can inform the driver that there is a work zone ahead.

Takeaways from user stories:

• Stories help us look at the users or system to see what people really want to do and why
• Stories enable collaboration
• Stories drive creative solutions
• Stories help create the requirements and the system

The user stories could be useful to anyone involved in a WZDx project - illuminating to think about the system in user stories rather than functional requirements

• Reach out to the co-chairs if you want access

Primary co-chairs activity over the last couple months has been to conduct a series of outreach conversations with different stakeholders involved in WZDx

• Producers - those on the IOO side or who help IOOs produce data
• Consumers - who want to use data in WZDx feeds in their products Goal is to validate whether the current specification meets market needs and hear perspectives on how people are thinking about the WZDx feed

Interviews

• Vehicle OEMs: General Motors
• Mapping providers: Waze, Google
• ATMS/traveler information systems: Q-Free and GEWI
• Connected vehicle warnings: Panasonic
• Upcoming: one.network, INRIX, Locomation, Kodiak

Takeaways

• No conversations that featured super focused interest in worker presence data, but there was some interest in the data for a few uses:
  • Driver alerts of workers ahead
  • Rerouting
  • Proxy for whether work zones are actually ative
• Less interest in how many workers there are in a work zone or where they are specifically
  • A couple data consumers expressed interst in knowing which subsections of a work
• High interest in mobile work zones - interested in better data from those
• Accuracy is important, but perfection isn't needed
  • Some data is better than no data, but hopefully it's good
  • Location is where people went first - want that data to be accurate, and to know which direction is affected
• Timeliness - wide range of answers, all in the minutes timeframe (2-15 minutes)
  • Also wanted to know when the data was most recently updated to get a sense of quality
• Not a lot of concern about worker presence definitions
  • We asked whether consumers had a definition and whether it could be a barrier to moving forward
  • If doing driver alerts, what matters the most is whether it would resonate with a driver going through the work zone, not necessarily for a court of law

Background on worker presence and WZDx feeds

• Worker Presence in the WZDxFeed and has been around since at least version 3
• Version 4.0 created a new WZDx feed about device data
• Earlier this cycle we sat down with the device feed group to discuss how the two feeds touch worker presence

The feeds present two different views of a work zone:

• WZDxFeed declares whether workers are present or not

• SwzDeviceFeed is about devices and what their status is

• Fictional work zone with start/end, sensors with road counts, a variable speed limit sign, arrowboard w/ lane closure, another dynamic speed limit, some workers,

• The blue and green lines show what story the WZDxFeed and SwzDeviceFeed would tell about the work zone

  • There are several segments that inform the user of the impacts that the work zone has on motorists
  • First event indicates that there is a work zone, but it has no impact on traffic
  • Second event tells the user that there's a reduced speed limit
  • Third event adds the lane closure
  • Fourth event informs users about the further reduced speed limit and workers on the side of the road
  • Last event has the higher speed limit and lane 2 closure until the end of the work zone

• Device feed has the locations of different types of devices

• There's a precise difference between the two feeds - one is the devices, one is the segments

  • How does the link get made? Who is responsible for informing users about worker presence?

• Kristin mentioned a few proxies for worker presence that could be used (say, a smart arrowboard is deployed) but that's not always the case across jurisdictional boundaries

• IOOs will receive raw device data and enable them to inform data consumers whether workers are present or not

• Diagram will be available on GitHub soon

Next steps

• There were some limitations to the location markers - none of the enumerated values directly related to workers themselves.
  • Issue #244 is looking at several values that could be added
• WorkerPresenceMethod enumeration is missing several options that could be used to identify where workers are - flashing beacon (not currently there, but could be useful),
  • Issue #290 contains discussion on this

Standard Operating Procedures for Populating Worker Presence

• It will be up to each IOO/DOT to define whether a value in a device feed indicates that workers are present
• If you already have SOPs that indicate workers are present if a certain criteria is met - please reach out to us!

Next meeting about 4 to 6 weeks from now

• For data users - if interested in the interview process, email Mark ([email protected]).
  • Your participation will help us fill out the one-pager we want to prepare later this cycle.
• For data producers - participate in producer interviews or send in SOPs

Has anyone started using the worker presence elements?

• Sinclair - Iowa DOT just started an initiative to improve worker safety using technology (IoT, especially). We're doing a bunch of pilot projects. Maybe not in the initial version through the grant but we're working in that direction. I'll be more active in the group and bounce ideas with people
• Pete Krikelis - We're starting to partner with a company that provides wearables for workers. Essentially a proximity sensor to avoid getting hit by vehicles, could be integrated into our SWZ system as well
• Walter - We're in early stages of getting wearables in the safety contingency fund of the infrastructure bill, so they can get reimbursed back to the project. That helps increase interest in using them. Maybe a year from now, we have partnerships with universities that want to do studies on braking/incidents. Also looking at Public Service Announcements to use navigation apps that can warn them about upcoming work zones
  • We generally protect workers on the construction side, but on the motorist side we have more trouble.

Name	Organization
Donna Clark	American Traffic Safety Services Association
David Schmidt	Applied Concepts
Randy Jackson	Applied Concepts
Luke Urie*	Austin Transportation Department
Kristin Virshbo*	Castle Rock
Benjamin Acimovic*	Colorado DOT
Eli Sherer	GEWI
Weimin Huang	HERE
Jingwei Xu	HERE
Pete Krikelis	Hill and Smith
Jacob Brady	IBI Group
Michelle Boucher	IBI Group
Sinclair Stolle	Iowa DOT
Walter Jones	Laborers' Health and Safety Fund of North America
Neil Boudreau	Massachusetts DOT
Ted Ulven	Minnesota DOT
Christopher Poe	Mixon Hill
Tony English	Neaera
John Parker	Pennsylvania Turnpike Commission
Lynne Randolph	Southwest Research Institute
Mark Mockett	USDOT Volpe Center
Molly Behan	USDOT Volpe Center
Nate Deshmukh-Towery^	USDOT Volpe Center
Serge Beaudry*	Ver-Mac
Erin Schwark	Wisconsin DOT

* Co-Chair of Spec Update Subgroup
^ Co-Chair of Work Zone Data Working Group