Expand connected temporary traffic signals in SwzDevice

[sknick-iastate]

Issue name: “Expand connected temporary traffic signals in SwzDevice”

Summary

Currently the SwzDevice feed allows for temporary traffic signals under the field device type of location marker. The location marker device type is currently designed to only describe the location marker type/location but doesn't allow any additional attributes associated with the device. In Iowa, there is a desire for an additional attribute on the mode of the connected temporary traffic signals that we would like to incorporate into the SwzDevice feed. Providing the mode allows for a better understanding of the impacts the signal has on traffic as well as ensuring the device is operating as desired.

Proposed changes

Iowa was working on creating a protocol for connected temporary traffic signal and originally put together the following enumerations for the mode:

• No communication available to the temporary signal set
• Powered on, but not displaying
• Using a timed cycle
• Using a manual trigger
• Using some other external trigger
• Disabled due to an error

I feel there are multiple options for adding a mode for the temporary traffic signals but looking for feedback from others on the best implementation that aligns with the SwzDevice feed. Below is a list of some potential options

• Option 1: Simply add a mode in the MarkedLocations Object that is optional and only used when the MarkedLocationType is temporary-traffic-signal. The problem with this approach is that the mode is not relevant to most of the marked locations.
• Option 2: Create a new device type object for TrafficSignal similar to the Arrowboard Object and FlashingBeacon Object. The TrafficSignal object would contain the core_details and mode. I would propose making this a required field as well. This approach would allow additional attributes to be added specific to traffic signals if needed in the future.

[sergebeaudry]

As a manufacturer of TrafficSignal I agree with the proposal and I would suggest Option #2 above due to the various elements related to such piece of equipment.

I'm proposing some change to the Modeabove:

• Power On, but not displaying. The Standard NEMA TS5 that applies for such equipment define Startup Flash as that operational state. That could be the name
• TS5 defines the Mode of Operation. which are: Pre-Timed, Semi-actuated (mix of timing and actuation), fully actuated and Manual. That could replace the timed and trigger mode above.
• TS5 also add the standby mode which could be red, red flash or yellow flash.
• The last element is defined as the Fault Mode in TS5 and this one could be either a solid Red, flashing red or flashing yellow. I would think that could be valuable information as the car behavior is going to be affected depending on the mode and type.

On the same wave. AFAD Automated Flagger Assisted Device are a sort of subset of this. They are reporting location of flagging operation. They cannot be actuated but could report the others elements (off, standby or startup, error). So this object may be used for such devices as well.. or creating one for such equiment

[j-d-b]

@sknick-iastate I agree with Option 2, creating a new type of field device: a TrafficSignal (or TemporaryTrafficSignal, to be discussed). We would also remove the temporary-traffic-signal value from the MarkedLocationType enumerated type.

TrafficSignal Object

The TrafficSignal object describes a temporary traffic signal deployed on a roadway.

Name	Type	Description	Conformance	Notes
core_details	FieldDeviceCoreDetails	The core details of the traffic signal device.	Required	This property occurs on all field devices
mode	TrafficSignalMode (see below)	The current operating mode of the traffic signal.	Required

Optional allows representing a traffic signal when the mode is not known, which is consistent with what the current implementation (traffic signal as a MarkedLocation) allows.

TrafficSignalMode Enumerated Type

To be discussed See below

[rdsheckler]

Do we want to put AFADs and portable signals in the same group?

[jlstanley-git]

Hello. I'm the author of the related Iowa standard protocols for portable traffic signals and arrow boards, I've been asked to provide input on this.

I believe that Skylar's option 2 is the best choice. It keeps the traffic signal devices in their own definition/domain without blurring the MarkedLocations Object by adding optional elements that only relate to one type of device.

@sergebeaudry has some good points about keeping an eye on maintaining compatibility with TS5 standards.

I will note that the "powered on, but not displaying" is a status, not a description of a startup event. So it should not be modified to blend with the TS5 "startup flash" status.

[sergebeaudry]

Regarding @rdsheckler question on AFAD.
We already have the value flaggerin MarkedLocationType with the description A human who is directing traffic_ An AFAD is an extension of a flagger. A human is still directing the traffic. An AFAD can't be automated as per MUTCD. The current way could work for a human with a traditional Flip stick, a GPs enabled stick or an AFAD.

Do we have others elements pertinent of having a separate objects?. Aside reporting error I do not see.. An even error, if this occurs the Flagger will have to put a B-plan in place.. Traffic will not stop.

[sknick-iastate]

After discussing further with a smaller group, the consensus was that Option 2 for a new device object would be preferred. The only attribute beyond the core_details recommended at this point was the mode. Below is a list of the recommended modes (descriptions may need further details).

• Blank - Not displaying
• Timed/Pre-timed - Using a timed cycle
• Manual Trigger - Using a manual trigger
• Semi-actuated - using an external trigger only for the minor movements
• Fully-actuated - using an external trigger for all movements
• Flashing-red - The signal is in a flashing red state that could be part of startup or fault
• Flashing-yellow - The signal is in a flashing yellow state that could be part of startup or fault
• Unknown - The mode is not known

Right now the plan would be to make this a required field but would appreciate further discussion.

There were also additional discussions about Fault and whether that information should be in the mode but it was deemed this info should be located in the status_messages in the core_details

[j-d-b]

The list for TrafficSignalMode looks good to me; I've drafted enumerated type documentation based on it below (I used pre-timed and manual as this was the wording in the NEMA TS 5 standard document).

As for required or optional, it has been a consideration for past specification design choices that instead of adding "unknown" as an option that the property is optional. That is, in this case, if the mode is not known, then the property is not provided. If "Unknown" is an option or that is more explicit, I agree with the property being required. I would just advocate for being consistent across the spec with using optional properties vs an enumerated type value to represent unknown. Edit: FieldDeviceStatus includes unknown, so I think we are fine to have TrafficSignalMode include it as well.

TrafficSignalMode Enumerated Type

The TrafficSignalMode enumerated type describes the current operating mode of a TrafficSignal (see definition above).

Values

Value	Description
blank	The signal is not displaying anything.
flashing-red	The signal is in a flashing red state that could be part of startup or fault.
flashing-yellow	The signal is in a flashing yellow state that could be part of startup or fault.
fully-actuated	The signal is using an external trigger for all movements.
manual	The signal is using a manual trigger.
pre-timed	The signal is using a timed cycle.
semi-actuated	The signal is using an external trigger only for the minor movements.
unknown	The current operating mode is not known.

Used By

Property	Object
mode	TrafficSignal (see above)

[j-d-b]

Another decision to make: the name of the traffic signal object:

• TrafficSignal; or
• TemporaryTrafficSignal

I don't have the ideal knowledge set to make this choice so am curious what others think.

For what it's worth, the current enumerated type value in WZDx v4.0 for representing a traffic signal using the LocationMarker MarkedLocationType is named temporary-traffic-signal.

[j-d-b]

The simpler name TrafficSignal was chosen during SWZ Subgroup meeting discussion on 2022-04-25. The description will clarify it is for a temporary traffic signal deployed on a roadway.

[j-d-b]

Implemented in #313.