Support representing static Temporary Traffic Control Zone Signs (see MUTCD definition) in the Device Feed

[j-d-b]

This PR resolves #337 by to allow data producers to represent a static, non-electronic sign that conveys both general and specific messages by means of words, symbols, and/or arrows (see definition in MUTCD Section 6F.02 General Characteristics of Signs).

Specifically the 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.

[j-d-b]

I implemented this PR following decisions made in the Smart Work Zones Subgroup Co-chairs meeting 2022-10-13. However, while making the PR I had second thoughts about this feature as currently implemented in this PR.

Firstly, I don't like the coupling to another specification (MUTCD). I would rather not have reliance on an external specification for simplicity and stability.

Edited: Resolved per MUTCD being required by law and ubiquitous.

For another negative, as a consumer, it would be burdensome to code in each of the MUTCD sign designations from that table in the MUTCD documentation and stay up to date with changes in MUTCD. It could also be hard to know how to use each one.

Lastly, I think if we are going to propose this then there needs to be text about how a static sign could be enabled with hardware such that it is connected (and thus the properties in FieldDeviceCoreDetails apply). If the sign is not connected, I don't think it fits in the WZDx Device Feed.

[rdsheckler]

The equipment builders have several products in the works to mark static signs. It is just beginning and not necessarily clear what concepts are going to win but I believe that five years from now there will be plenty of 'devices' that mark static signs.

[j-d-b]

Per discussion in the spec-update co-chairs meeting 2022-10-21, I propose the following changes:

• Add clarifying text that the TemporaryTrafficControlZoneSign should be used for signs that are equipped with connected, GPS-enabled hardware (not just a sign that has all details manually entered.
• Remove direct links and table column references to the specific MUTCD section to reduce coupling with MUTCD given a new version of MUTCD is scheduled for release soon and the chapter and table numbers may change.
• Based on @sknick-iastate's comments on how Iowa would use this device type, add an optional boolean property to the TemporaryTrafficControlZoneSign object to indiciate if it is in a deployed/in-use position (like ArrowBoard is_in_transport_position). This property can be used to determine if the sign is currently having an impact to travelers on the roadway. Iowa considers "is horizontal" (not visible to roadway users) or "is vertical" (visible to roadway users) in assessing if the sign is having an impact.

For the additional property, see below for an implementation idea for discussion:

Name	Type	Description	Conformance	Notes
is_in_deployed_position	Boolean	Indicates if the sign is positioned such that it considered deployed and could be visible to roadway users.	Optional	This property can be used to determine if the sign is currently having an impact to travelers on the roadway.

[tfoster-vm]

We echo @rdsheckler that these devices already exist with a few manufacturers and more are in development to help demark static aluminum signs that are critical for work zone guidance. Also, why should an aluminum sign as part of a hybrid sign object type be considered and not a properly identified regular aluminum WZ speed sign? All DOT's and government agencies rely on the MUTCD (a national standard) and the existing sign codes usually do not go away or change, just new ones get added...for the most part, so the new manual would not impact this proposal. This is better than letting people name things and the inconsistency that accompanies that, such "ROAD CLOSED" vs CLOSED ROAD", vs ???. We could remove coupling of the MUTCD table but we should keep the MUTCD link to the codes. The signs will be connected either full time or at the time of deployment, so it does belong and is more inclusive to allow these devices than not.

[sergebeaudry]

I'm not for limiting the market with this restriction: add clarifying text that the TemporaryTrafficControlZoneSign should be used for signs that are equipped with connected, GPS-enabled hardware (not just a sign that has all details manually entered.

Some companies today are using smart phone with RFID tag on those sign to create an inventory of signs and location. that is almost as valuable as a GPS-enable hardware.

I'm fine with the is-in_deployed_position. that way the feed will be able to report that a bunch of sign are still on the workzone but not in used... maybe the contractor forgo those. or they are there in preparation for next night closure.

[rdsheckler]

We need to have a separate conversation about the use of techniques other than a located device tied to the equipment in reporting work zone information inside the 'device feed'. We are exploring virtual markings but we need to talk about virtual vs. real-presence.

[NeilBoudreau]

@j-d-b - while I can understand the concern with linkage to another specification as you put it, but the MUTCD is far more than just a specification. Unlike the NTCIP, ANSI and other standard specifications like those, the MUTCD is adopted by reference in accordance with Title 23, United States Code, Section 109(d) and Title 23, Code of Federal Regulations, Part 655.603, and is approved as the national standard for designing, applying, and planning traffic control devices. This essentially means that it is Federal Law and that changes are only made though a formal process that requires public notification and comment before any change can be adopted. This gives us a level of certainty that the sign codes are not changing with any frequency. As @tfoster-vm said, we absolutely want to avoid the potential for the wrong designation of a sign name and function through this process. I cannot speak for the CAV industry, but I believe that consumption of the sign code, name and function data is something that is of use for automated driving systems, and I believe that is also of importance to some of the mapping service companies. These folks need to chime in to be sure. The mechanism for how the sign data is captured automatically in the field should be left to the industry to define, there are several options being considered/used and I am not sure that we can drive that decision.

[NeilBoudreau]

@j-d-b - while I can understand the concern with linkage to another specification as you put it, but the MUTCD is far more than just a specification. Unlike the NTCIP, ANSI and other standard specifications like those, the MUTCD is adopted by reference in accordance with Title 23, United States Code, Section 109(d) and Title 23, Code of Federal Regulations, Part 655.603, and is approved as the national standard for designing, applying, and planning traffic control devices. This essentially means that it is Federal Law and that changes are only made though a formal process that requires public notification and comment before any change can be adopted. This gives us a level of certainty that the sign codes are not changing with any frequency. As @tfoster-vm said, we absolutely want to avoid the potential for mis designation of a sign name

[j-d-b]

Closed following subgroup member meeting 2022-10-24. The consensus was opening the spec to allowing devices that are not actively connected (such as static signs that were placed and either manually entered or position recorded on placement) needs more discussion and cannot be completed for the v4.2 release. Issue #337 that led to this PR will remain open for further discussion.

[davidcraig4300]

Leaving comments that I posted during the meeting chat:

1. The feed is called the Smart Device Feed from the Smart Workzone Sub-Group, should these static untracked signs fall under this feed or the Specification Extension Sub-Group?

2. If static aluminum signs are to be reported in the Smart Device Feed, there should be some field that indicates that this is not a smart sign. I could see smart signs and static printed signs being treated differently and knowing which is which will become important.

[bzacimovic]

A few comments:

1. I think this pull request (at some point) should move forward. The information for larger DOT's seeing what local agencies are doing on their projects and their roadways would be good. It would also assist in traffic control audits and inventories for counting. I also agree with Neil above that it would be invaluable for autonomous and connected vehicle driving systems with I2V use cases.
2. I don't think at a state, county, or local level we are ready to require this one without a lot more thought on the implications to workers who are taught to put the sign-out and leave it. There could be equity issues, market issues, entry to the market issues, data issues, and types of communication issues to work out. I think there will be a large timeline for the transition to this as we go from 5-10 devices to potentials dozens to hundreds of signs on larger projects.
3. Static vs Smart - I know we renamed the thread devices vs smart but I suggest we have a good distinction between what is a static and what is a dynamic device. The device spec is separate from wzdx feed for a reason. I don't know if this is the right place for this one given the difference to consumers and DOTs.
4. I think we need to consider how this would effect businesses, workers, DOTs etc before we move forward with this one.

[rdsheckler]

While it needs to put into a separate thread we should note that any information that is not associated with a device that is both real-time and real-presence needs to be identified as 'virtual'. If a static sign is outfitted with a status/tracking device that continually verifies its presence then that sign can be verified. If a sign is entered into the data system through means that don't continue linger with the sign (worker entry, RFID scan, etc.) I don't think we can say that it is 'verified'.

[adam-pilit]

Adding a few thoughts & comments:

From my understanding knowing the presence and status of the signs are of value to WZDx consumers. From an automated system, and perhaps @davidcraig4300 can confirm or deny this, knowing the context of the sign can be helpful. From an agency perspective, knowing the whereabouts or status of the sign in real time (inspection, compliance, etc) and/or internal reviewing purposes can be helpful ("where was the sign on this day at this time?").

The method in which to document the presence of the signage can vary: tracker, qr code, RFID, camera, manual input, etc. and there are positives and negatives for each approach. As discussed on the call, data 'freshness' becomes an issue with virtual/manual inputs however they may have their own set of benefits. I believe it is up to the consumer to decide whether the data is of use based on their application and the device's update_date field. If the sign has been documented virtually, the device may only be updated on an hourly or daily basis. A tracker may be able to provide updates at a faster interval.

Some WZDx consumers may require real-time information in order to be useful, some consumers may only need a daily update. But if a consumer would like to have the information, it may be worth considering the additional device type.

Adam Selevan

[davidcraig4300]

@pilit , Adam, From the OEM point of view and from the vehicle / human driver point of view, the most important information is what data is actually on the sign, or what does the sign want the vehicle to do. Understanding that the speed limit drops to 45mph at location X is way more important than understanding what type of sign this information is on. Understanding that the left lane is closed is way more important than knowing if it is an arrowboard. And yes, knowing that information to a high degree of certainty is desirable. But, first is just to get the information. This basic information is comprehended in the current WZDx 4.1 spec. Honestly, the vehicle would need to treat the WZDx reported speed limit and a smart digital speed limit sign the exact same way. We cannot guess or treat one differently than the other. If a WZDx event says reduce the speed, and digital speed limit sign reports something else, the only logical response is to drop to the slowest one.

That all being said, I totally understand that the IOOs would like a way of keeping track of their inventory of signs. That makes sense to me, I just don't see the vehicle ever consuming this info.

Which is why I first thought that this is a perfect fit for the specification extension subgroup. But, I can also see the logic of putting it in the Smart Device feed, but I think we either need to change the name of the feed, to something like Device and Sign feed (or Work Zone Device Feed), or at least put in a couple attributes that differentiates these two radically different things (dynamic/static, trackable/not-trackable).

[j-d-b]

Reopening due to continued interest. Due to the v4.2 release timeline, it is unlikely for this to be implemented for v4.2 given the amount of remaining discussion needed, but please feel free to continue comments here as the implementation proposed can be modified and eventually completed.

[j-d-b]

@davidcraig4300

But, I can also see the logic of putting it in the Smart Device feed, but I think we either need to change the name of the feed, to something like Device and Sign feed (or Work Zone Device Feed), or at least put in a couple attributes that differentiates these two radically different things (dynamic/static, trackable/not-trackable).

For your reference, In v4.1 (current released version of WZDx) the "Smart Work Zone Device Feed" was renamed to "Device Feed".

I agree that if the Device Feed is going to be altered to be able to include signs that are not actively connected, there must be a way for the producer to clarify this using additional data fields (most likely in the FieldDeviceCoreDetails), such as an "is_static" or "is_connected" or as @rdsheckler suggested "is_virtual" (since they aren't "real" devices, just signs represented as devices). It is inevitable that these "devices" will have lower quality data, as they will rely on manual updates from a human to be added, updated, and removed from a system—having a way for a consumer to know they are not real connected devices would be the consumer handle the data differently (e.g. trust it less).

It may also help clarity to consider adding another value to FieldDeviceStatus enumerated type (maybe not-connected or similar; currently the values are ok, error, warning, unknown)—else unknown will have to be used for all not-connected devices.

In general, I think that a device being connected to the internet and the data producer's server and reporting out "facts" (collected data, displayed content, current GPS position, status... etc) via the Device Feed is the best way to reduce human error and contribute to accurate work zone information (which is the goal of the device feed), so I still lean toward not allowing statically placed, semi-manually entered, not-connected signs in the Device Feed. Following that mindset, the TemporaryTrafficControlZoneSign could be represented only if it has hardware mounted to it that maintains a connection to the internet and the data producer's server.

[natedeshmukhtowery]

It is also worth noting that this discussion is likely the first in a series that will continue into the newly announced Connected Work Zones effort, so all of the points made above are very useful and relevant for both today and the future

[j-d-b]

Closed following co-chairs discussion 2022-10-20. It was determined that there are certain MUTCD signs that lead to an impact to travelers or provide information that could be used to generate an accurate WZDx Work Zone Feed. These include arrows (lane closure), road closures, ramp closures, and speed limits. Lane closure, road closure, and ramp closure can be represented by the existing LocationMarker. Thus, there would be value in enabling a reduced speed limit to be represented by a LocationMarker as well. I will make a new issue for that.