Implement new detector status, "Inactive," for broken, non-essential signal detectors

[atdservicebot]

What application are you using?

Data Tracker

Describe the problem.

Traffic Signal detectors needs a new status of "Broken-Unessential" or something similar.

Describe the outcome you'd like to see when this feature is implemented.

Change our reporting and information so that nonessential detectors are not factored/reduced value while determining repaired maintenance.

Describe any workarounds you currently have in place or alternative solutions you've considered.

Storing information in a nonstandard form i.e. detector comments or other random areas.

Requested By Joshil B.

Attachment (58.88kb)

---

Request ID: DTS21-101495

[amenity]

@dianamartin @johnclary Would you all object to adding a "Broken - Nonessential" status if Joshil commits to updating the data himself?

[amenity]

Questions in to Joshil via email:

• How many signals would be assigned a "Broken - Nonessential" status?
• What status do you apply to signals that are broken but are essential?
• How do we determine whether a signal is essential or not? Where is that list documented?

Thinking about it more: If some signals are truly nonessential, shouldn't that be recorded directly on the signal rather than in a status? In this case, if it were repaired it would lose its "nonessential" designation.

[johnclary]

Good questions and I agree with your points @amenity. This doesn't quite sound like the right solution and I'm guessing Jen would not be enthused. Propose we table it for our AMD project prioritization or ask Joshil to run it by Jen, Brian C, and Brian VDW.

If we were to implement a fix, we'd want to, as you suggest, create a new detector attribute that designates if the detector is "essential" separately from its status.

[johnclary]

Point of clarification that Joshil is referring to detector statuses, not the signal itself. This status is driven by "Detection Events". This form, pictured here:

And these are the detector statuses:

[amenity]

Response from Joshil:

How many signals would be assigned a "Broken - Nonessential" status? These would be Traffic Signal Detectors (i.e. a subsystem of Traffic Signals) that would be assigned a “Broken-Nonessential” status and I would guess may be 300 out of the 4800ish we have right now. Primarily this is for my reporting and repairs workflow so I don’t keep seeing the same detector being broken but realize it’s non-essential (and can be fixed at a later point) and is primarily for data collection rather than essential signal operations.

How do we determine whether a signal is essential or not? Where is that list documented? To reiterate, this is for traffic signal detectors, not traffic signals. This is a mix of a lot of factors. For example, all pre-timed signals are not explicitly labelled as such in Data Tracker unless they have detection assigned to them. However, most of downtown is pretimed and that is mostly a knowledge thing and/or recorded in the signal controller program (which does not interface well with outside entities other KITS). It would primarily be data retroactively changed over time rather than importing a new/replacement list.

Looking at the detector status list, this makes a lot more sense. Asked Joshil to sync with Brian VdW and Billy before our Feb 8 AMD meeting.

[amenity]

Since there isn't a way to bulk update the 300 detectors based on related fields/table, Joshil said the signals will get updated overtime.

Both Billy Bolander and Van de Walle have been informed of this request and agree with the idea as well.

[johnclary]

On hold. Allyson will circle back with Brian and Jen to get alignment on specifics.

[amenity]

From Allyson: We'd like a detector status 'inactive' added to reflect the broken, non-essential detectors.

[amenity]

@dianamartin - please check on reports.

[dianamartin]

@johnclary Should I add Detector Status Event - "DETECTION INACTIVE" to the existing events statuses

• DETECTION CHECKED
• DETECTION RESTORED
• DETECTION INSTALLED
• VERIFICATION NEEDED
• ISSUE REPORTED
• DETECTION UNINSTALLED

Then add "INACTIVE" to Detector Statuses so that workflow will look like this now (highlighted in: red)

[johnclary]

@dianamartin this visual is amazing! Yes, and can you add the form submit rules so the detector status becomes INACTIVE when the DETECTION INACTIVE event is chosen? I think you were implying this but just want to be clear.

[dianamartin]

@johnclary That was that Miro workflow I made for the detectors awhile back when it was confusing for me and I was trying to understand the relationships. Yes, I didn't specifically put I was going to update the form rules, but that is my intention. Thanks for the clarification, now I can work on this.

[dianamartin]

• signal_detectors object > "DETECTOR_STATUS"

  • added INACTIVE

• `signal_detection_status_log >"EVENT"

  • added DETECTION INACTIVE

• Updated Form Submit Rules - Add signals_detection_status_log form

• Check detector status reports

[dianamartin]

Emailed Joshil, Billy, Brian VdW, Allyson, Lance

I’ve gone ahead and added the “Detector Status” – INACTIVE and the Detector Status Event – DETECTION INACTIVE. Whenever the event “DETECTION INACTIVE” is submitted, it will update the detector to the “INACTIVE” status.

I wanted to ask about how you want me to update the Detector Reports because you wanted to not include the “Inactive” status to the reports. Let me know how you want me to do it and I’ll update the reports.

[dianamartin]

I emailed yesterday (3/9)

Is anyone able to assist with detector reporting changes? I’m eager to finalize this request for y’all.

Joshil replied

I was planning on going over all the charts and the like to see what changes we want. At the bare minimum we’re all good with the INACTIVE detectors not counting towards any calculations for detector health/performance measures. I’ll let you know what we want to see by the end of this week. Thanks!

[dianamartin]

Detector Report Changes

Signal Detector Status Count by Intersection

• Absorb “UNKNOWN” into “Broken” and “NO DE-TECTION”, “VERIFICATION NEEDED”, “INACTIVE”, and “REMOVED” into “OK”, with “OK” and “BROKEN” being percentages of all signals “TURNED ON” (including PHBs/diamonds) signals.
• For example, any signal with a single broken or unknown detector is labelled as “BROKEN” for this metric but anything else should be labelled as “OK”.

Signal Detection Status

Description Text:

For TRAFFIC signals that are TURNED ON. To calculate % working detection, divide OK signals by he sum of BROKEN, OK, and UNKNOWN signals

Remove this or if it is used in calculations, which ones as it doesn’t seem useful as a metric.

Detection Issues and Repairs

• Rework into monthly and/or yearly data of detection reported as repaired or broken, with the ability to click each bar and see the location of the repair/break.
• If needed, keep this but it seems like unnecessary information as it is cumulative of the past three years which is not useful for determining priorities.

[dianamartin]

Scheduled a meeting with Joshil on 3/23 to get clarity on detector reporting

[dianamartin]

Sync'd with Joshil this morning, 3/25

Signal Detector Status Count by Intersection

• Updated report description
• Removed some filters on the table
  • [x] Signal_Type is not PHB
  • [x] Detection_Status is not "Unknown"
• 

Signal Detector Status Count

Updated with report description

Signal Detection Status

• just checked the source

Detection Issues and Repairs

• Filtered Event Date for FY 20