Smart Work Zone Meeting #2 10 24 2022 - usdot-jpo-ode/wzdx GitHub Wiki

Purpose

Purpose of the meeting is to meet with subgroup members to present the pull requests to members for the streamlined cycle 3 for the subgroup on WZDx Smart Work Zones (WZDx Device Feed).

Agenda

  • Update
  • Pull Requests
  • Next Steps

Notes

Update (Neil Boudreau)

  • The former smart work zone device feed is now called Device feed, has been released, WZDx v4.1.
  • This subgroup is performing an accelerated cycle before the new standards group takes over the WZDx specification.
  • This meeting will be used to discuss the pull requests based on the issues discussed at the last meeting.
  • There will be no more membership meetings for this cycle
  • Federal highway administration (FHWA) has awarded the formal standards group for WZDX. Kickoff meeting for this new group has been held. There will be an outreach effort to gauge interest in getting involve with the upcoming activities of this new group.

Pull Requests (PRs)

Pull Request #354– Clarify Flashing Beacon is for representing a flashing warning beacon mounted on a temporary control device (Neil Boudreau) Resolves issue #341

  • It is proposed that the description of the FlashingBeacon object is updated to clarify that it should only be used as a flashing warning beacon mounted on a temporary traffic control device.
  • A flashing warning beacon used to supplement a temporary traffic control device. A flashing beacon is mounted on a sign or channelizing device and used to indicate a warning condition and capture driver attention.
  • Clarify flashing beacon and what it represents. There is some confusion on what it represents.
  • The intention of a warning beacon versus a flashing light, which is what we are addressing. The vehicle light will be addressed later on.
  • The description has been updated and this is what we are proposing for this pull request using language directly from the MUTCD.
  • Flashing beacon is mounted on a sign or channelizing device and is used to indicate a warning condition and capture the driver attention.
  • If anyone disagrees with this language update, please comment on this PR in Github.

Pull Request #355 – Support representing static Temporary Traffic Control Zone Signs (see MUTCD definition) in the Device Feed (Todd Foster)

  • This resolves issue #337
  • Allow data producers to represent a static, non-electric sign that conveys both general and specific messages by means of words, symbols, and/or arrows (MUTCD Section 6F.02). Specifically, this PR makes the following changes:
    • Add a new field device object named TemporaryTrafficControlZoneSign
    • Add a value of temporary-traffic-control-zone-sign to the FieldDeviceType enumerated type.
    • Update the fielddevicefeature object to be able to contain a TemporaryTrafficControlZoneSign object.
  • This PR is meant to represent critical aluminum signs that are in a work zone. These signs would be connected or identified in some fashion. They are not digital. Non electronic is the word we are using to represent the aluminum signs in a work zone. The non-electronic would correspond to
  • allowed signs that are in MUTCD section 6F.02.
  • Several manufacturers equip the aluminum signs with a box to add on a GPS device or some sort of RFID tag or a smartphone application. This PR is to address all these types of signs.
  • The distance or height on a sign can change. We will need an additional descriptor to handle some of the text. For example, even though it is a G20-1 sign, we need to know how many miles are represented on that sign.
  • Ross Sheckler – This might be a place to ask data consumers or just the larger group who may not have been following this issue/PR in Github how they feel about using the MUTCD codes.
  • Neil Boudreau – By federal law, all states must adopt the MUTCD codes and the codes do not change. Each state may end up developing special signs that are specific to their state.
  • Massachusetts has some unique work zone signs that are specific to Massachusetts.
  • Massachusetts wouldn’t expect a mapping service provider to understand what is done in Massachusetts, but those are very unique sign circumstances. All states are using the MUTCD terminology and codes.
  • Jacob Brady – Specific to the code and the consumer perspective, there is no objection to the MUTCD codes, but what is notably different is that there is nowhere in the specification where we reference an external specification. The MUTCD section is a very good one to reference because it is ubiquitous, but it should not be reflected in its own enumerated type in WZDx. The description for the sign designation in this new object is just a string, and technically you could put anything, but recommend that it be one of the codes from MUTCD section 6F.02. There’s no restriction on an enumerated type, which can be fine because as a consumer you can just ignore values the consumer doesn’t want to include. On the consumer end it maybe difficult to deal with the different values programmatically because the list of sign designation in MUTCD is quite long. You would need to program in all of them into your own reference enumerated type in the software if you did want to deal with them each specifically, but you’d also need to follow MUTCD to see if they ever change and then update your list, rather than just referring to the WZDx specification. This is not a reason to not do this, it just seems a bit inelegant and not as polished as all the other things in the feed currently.
  • Todd Foster – Unless MUTCD says they will never change, it’s theoretically a concern and does contribute to the implementation being not as elegant.
  • Neil Boudreau – The basic premise behind the codes in the MUTCD is that they do not change. The only change in the MUTCD in the last 20 years is the adoption of symbol signs to represent text, but in those situations, they add an A or a B, etc. There is the same code, it just has a different end character to define the difference. The MUTCD codes rarely change.
  • Jacob Brady – Adding or removing codes is sort of the same problem. If you have software that can consume a device feed and read the codes and react to the codes, you have to continually follow along with the MUTCD to be able to handle all the options, which can be fine for our effort.
  • Todd Foster – There is going to be a lot of work zones that are not going to have electronic connected devices, so we want to accommodate the non-electronic signs because there is critical information in those work zones that would be helpful as part of this feed and will help it propagate itself and better inform the drivers of connected and automated vehicles. That is the motivation behind this change.
  • Todd Foster – There isn’t a downside to this change. The subgroup has discussed this. From the manufacturers side, there are items that companies provide that are not defined in the current feed and the philosophy is that if there is information that you do not care about you don’t digest it on the consumer side. There are critical devices in work zones that we want to provide in the feed and if they are not of value to a consumer, they can ignore them.
  • Michelle Boucher – Can we put a consumer on the spot, David Craig?
  • David Craig – From GM’s point of view, they are not concerned with bridge height/clearance signs. What GM is concerned about is not consuming the digital signing information but consuming the larger WZDx feed. The message that says here is the work zone and here is what is going on in the work zone at this location, the speed drops to 45 mph and the bridge height clearance drops to 13’ 6”, that is the type of information that GM wants to consume.
  • Todd Foster – If you want to know the speed limit in the work zone, you don’t care if it is on a digital sign or an aluminum sign, you only care that the speed limit is reduced in that work zone.
  • David Craig – Yes, I just care what it says.
  • Skylar Knickerbocker – Keep in mind a consumer like GM is not going to care about the device feed. A state DOT is going to care about the device feed. So a company like GM is going to care about the WZDx feed that contains information such as bridge height and work zone speed. This information is for the DOT consumer, not the mapping company consumer.
  • Todd Foster – This is a very good point. The reason we came up with the device feed is for the agencies and the fact that they want the extra level of detail beyond what car companies that only want the generic information, regardless of how it gets in, as long as it is accurate. It is two different audiences. Other DOT participants should comment.
  • Ben Acimovic – This has a lot of good application and use cases. CODOT for instance is looking at how to put RFID chips or some sort of communication on static signs, permanent or otherwise, for inventory purpose. This can assist with determining if a work zone is set up correctly. Need to figure out the use case. It is a lot of information and can it be used, yes. CODOT wants to know what is out in the field.
  • Ross Sheckler – Sharing a lesson learned in Texas. The Central Texas COG started a program to access device data. They want data from the streets of Fort Worth and Dallas without the ability to write their own specs, they want to collet what Dallas has and ingest in their traffic center. So the data consumer is the larger government. To share the data, they will publish it through the WZDx feed. Sharing the data so the larger and smaller government agencies both get the data.
  • Jacob Brady – Second part of comment, he understands the value of having the signs represented and agrees and agree with referencing the MUTCD. This would be the first device that doesn’t have to be connected, which means it still uses the field device core details, which is designed around a device being connected, such that it has a status, as a required property, which has the value of Ok, Warning, Error or Unknown. For this use case you would need to use Unknown. If producers are using this to just represent a static sign that isn’t connected, the location is registered at one point when it is deployed and then we push the information out in the feed. Nothing will change because there is no connected hardware on the device. This doesn’t fit with the current model. Examples of other properties on the field device core details are serial number and firmware version and status message. The device feed should have a connected device so we know the location through GPS, which is valuable to the DOT consumer because they can confirm a device location this way. For a static sign you are depending on manual intervention. Hopefully the manual entry is correct, and it is reflecting real information. This puts more responsibility on the person who is updating the device feed with this information. The static signs compared to the connected devices.
  • Ross Sheckler – There is a possibility of virtually marking the static devices. These static signs can also have a device that marks their location automatically or through a cell phone application. Virtual marks have real value and may solve this concern.
  • Todd Foster – We shouldn’t confuse the two issues. The virtual marker can be entered as a new and separate issue from this one. The static sign would be known and established with GPS when it is installed and witnessed by somebody or some process to confirm the location. If a sign gets turned 90 degrees or laid flat, this would need to be reported manually by the witness or process. However, the sign is still physically at the location, but it is not in an active display mode. You have to believe that a witness is credible. We don’t want to dictate to the industry how to do it, we just want to give out a better base of information.
  • Jacob Brady – Distinguish between a device that is consistently communicating compared to something that was set at one point. Then a consumer can choose to ignore a manual device vs a connected device.
  • Ross Sheckler – This gets back to the validity of data, how do we validate, for a non-connected device it can get stolen and you wouldn’t know it is no longer in the field. Need to build the least hackable system possible.
  • Jacob Brady – Devices should report the facts that they know and taking away manual entry is important. With a device that is marked when it is installed, but you don’t actually know it is still there days later.
  • Todd Foster – We talked about whether GPS has manually verified or automatic, so we can have the exact problem with manually overriding GPS on a connected device. Because sometime there is an issue with automatic GPS.
  • Jacob Brady – It is only the same discussion for location because the other properties would still send status from the device directly.
  • David Craig wrote in the chat – Would this mean that static non-connected (non-smart) signs would really fall under the spec extension subgroup? Especially the clearance sign is pretty much exactly what that group is doing. I am thinking this needs a new field, smart devices vs dumb devices.
  • Ben Acimovic – I agree with what Dave Craig wrote.
  • Ross Sheckler – Will need to define. If you glue a tracker to the back of a work zone static sign, does that make it a smart or a static sign?
  • Ben Acimovic – That is a static sign because it is not taking input in and sending out. It needs to have actionable intelligence. A PVMS is sending out actionable intelligence.
  • Todd Foster – Do not agree with this statement because sensors have no input, just output.
  • Ross Sheckler – A work truck with hazard lights, which we will get to later, is marking a device that is active or not active. A speed limit sign can be active or not active.
  • Todd Foster – remember we renamed the group from Smart to just device. Ben Acimovic – There is no standard for static signs to have GPS on them, there is no consensus for where we are on that issue.
  • Todd Foster – Our job isn’t to define the method of delivery. It is to convey accurate information that is critical to the speed.
  • Ben Acimovic – There needs to be standard for people to follow. It is complicated. The intention is good, we just are not ready yet from a DOT standpoint.
  • Dan Sprengeler – As a user of putting up signs and doing working zones, he agrees that we are not there yet. We want our connected devices to be foolproof. We need to be able to trust them. This is something we can add later on, I don’t think it is worth the effort right now. Connected vehicles maybe able to read the sign and we can get the information this way, rather than having to read the sign.
  • Ben Acimovic wrote in the chat - People out there we entrust to put things on signs or move them etc are not 100% ready for this.
  • Peter Stresino wrote in the chat - Is it possible that this would help in not having to have a worker drive through a work zone to inspect the signs and barricades to make sure the work zone is set up correctly? Also, would this also help in the court of law to indicate what signs were being displayed in the work zones when trying to prove fault?
  • Neil Boudreau – In the chat we received a comment from Peter Stresino. What Peter is indicates is clearly something that could be done as part of this. If we were to track the signs and other type of devices in the work zone it does open up the potential for many issues, but our intent here was just to provide information to try to better get what is happening in the work zone out to end users.
  • Michelle Boucher – We need to leave this issue/PR for the co-chairs to regroup and discuss.
  • Todd Foster – I would encourage this PR. People should go to this pull request in GitHub and add your feedback.

Pull Request #353 – Allow a LocationMarker to be used to mark an active work truck (Ross Sheckler) Resolves issue #298.

  • Enhance the LocationMarker field device to all it to be used to ark an active work truck.
  • Specifically, the following change will be made:
    • Add new value work-truck-with-lights-flashing to the MarkedLocation Type enumerated
  • type.
  • There are all sorts of different work trucks and we want to know where they are in the work zone.
  • The consensus is to allow the location marker or marked location to be used to represent a work
  • truck that is active in a work zone. In the future, we may make a work truck a separate device
  • type. For this release it will be a marked location type with the value. It is a work truck with its light
  • flashing.
  • There were no comments from the members on this PR.

Pull Request #352 – Allow providing current velocity for a field device (Ross Sheckler)

  • Resolves issue #296
  • This PR enhances the WZDx Device Feed specification to allow a data producer to provide the
  • velocity for any type of field device. Specifically, the following change was made:
    • Add new optional property velocity_kph to the FieldDeviceCoreDetails
  • GPS equipment is tracking devices such as arrow boards and message boards, etc. This
  • information can be used for locating (not predicting) mobile work zones, by adding the velocity
  • field. This is an optional field to the core details. It is not required so it is not a breaking change.
  • Todd Foster – Should not use the term predicting for this, the proper term to use is location.

Next Steps (Ben Acimovic)

  1. Members should review the pull requests on GitHub and provide comments.
  2. Look out for information about volunteering to be part of the connected work zone standardization effort that will be starting up soon with ITE.
  3. The voting for WZDx v4.2 will be in Nov 2022 and the feed will be released in Dec 2022.

Participants

  • Colorado DOT – Benjamin Acimovic*
  • iCone Products – Ross Sheckler*
  • Massachusetts DOT – Neil Boudreau*
  • Ver-Mac – Todd Foster*
  • Arizona DOT – Marty Lauber
  • ATSSA – Nagham Matout
  • Castle Rock – Kristin Virshbo
  • Connecticut DOT – Jennifer Petrario
  • GM – David Craig
  • Hill and Smith – Todd Hartnett
  • Hill and Smith – Ivo Kushkiev
  • IBI Group – Jacob Brady
  • IBI Group – Michelle Boucher
  • Illinois DOT – Peter Stresino
  • Iowa State University – Skylar Knickerbocker
  • Iowa DOT – Sinclair Stolle
  • Iowa DOT – Dan Sprengeler
  • John Thomas Inc. (JTI) – Charlie Percival
  • John Thomas Inc. (JTI) – Bob DeCarlo
  • PA Turnpike – Albert Brulo
  • Pi Variables – Adam Selevan
  • Solar Technology – Cody Nederostek
  • SwRI – Nick Boltralik
  • The Sanborn Map Company, Inc. – John Copple
  • Volpe – Molly Behan
  • Volpe – Nate Deshmukh Towery

*Smart Work Zone Subgroup co-chair