Sunguide Software Wrong Way Driving Conops Document Comments December 05, 2014

Date: December 05, 2014 Reviewing activity notes:

ID# Reference R Comment Response Status e v i e w e r Section 4d D Camera lock should not prohibit operators from moving This is existing SunGuide Resolved on them behavior – any operator with g permission can override a Ch lock imposed on a camera by en another operator or by another subsystem. However, the lock is needed so a scheduled action will not take over the camera. This was clarified in the document. SunGuide® Software Wrong Way Driving ConOps Document Comments December 05, 2014

ID# Reference R Comment Response Status e v i e w e r D Due to the severity of WWD events, may want to Item 4g was modified to be Resolved on consider an additional pop-up (in addition to IDS more clear that the alert g notification). handling window will Ch immediately appear without en the operator having to click on the alert as is required for other alert types. When operators handle the alert, the window will remain with the video on desktop and the alert handling viewer will disappear and the event that is created will appear. The first operator to handle the event will be the event owner. M Consider including ramp meters as devices that can be Added to the end of the main Resolved ar ‘configured’ in conjunction with a WWD event. It might section as a subsection, 3.5: k be beneficial to be able to slow or completely shut off 3.5 Changes Pl on ramp traffic as part of WWD event management. Considered for future phase. as s

of 19 SunGuide® Software Wrong Way Driving ConOps Document Comments December 05, 2014

ID# Reference R Comment Response Status e v i e w e r M As noted in Section 4 of the Concept of Operations the The automatic activation of Resolved ar protocol is based on the system posting DMS messages response plans is k without operator intervention. Potential risk to the configurable. A paragraph Pl Department in cases where DMS messages are posted was added at the end of as for events that are subsequently found to be false calls section 2.3.1 to cover the s should be assessed through a ‘scenario testing’ process additional testing and where DMS messaging is simulated in different analysis that could be done environments (urban, rural, urban with express lanes, prior to configuring the extreme weather, etc.) and for varying lengths of time system to automatically before operator intervention to disable. Not sure how activate the response plans. to structure this testing process but strongly recommend it be done and used to inform the Department’s ultimate WWD response procedure. M Although this may not typically be indicated in a There is a separate Resolved ar Concept of Operations, it is critical that the Department operational procedure k have ONE COMMON and proscriptive WWD response document to ensure Pl procedure and not a procedure that could result in a everyone is doing things the as different approach being taken (messaging, etc.) by same way. s different districts. This needs to be CPR.

ID# Reference R Comment Response Status e v i e w e r M Should we create an NTCIP standard instead of vendor I took a quick look at newest Resolved an specific standard? A standard which is driver base and version of NTCIP 1209 and I ny provides SunGuide the necessary information. didn’t see anything that Ro could be used for wrong way dr alerts to the central system. ig Coming up with a simple ue standard communication z approach could be considered in the future, but it will also require modifications to the appropriate Standard Specifications. The communications would need to be push instead of pull oriented, with some sort of mechanism to make sure the device is still active. Are you also thinking of including the Tapco devices in this category? They have additional information like JPEG images that may be a little more difficult to handle. Due to the pressing nature of wrong way driving, this cannot be done at this stage, but can be considered for a future phase. This has been added to the future

ID# Reference R Comment Response Status e v i e w e r M Should the response behavior be consistent across the There is a separate Resolved an state instead being set by the district? operational procedure ny document to ensure Ro everyone is doing things the dr same way. ig ue z M Automated Messages should only be sent if there is a The software will be Resolved an 2nd source of information that confirms the wrong way configurable to allow us to ny driving. do testing before Ro automatically sending dr messages, then to automate ig the messages if testing is ue successful. We can discuss z operationally how we should approach the automation, and include that decision in the operational procedure.

Waiting for a second source for verification may take too long. The sooner we can make the public aware of a potential wrong way driver, the better.

ID# Reference R Comment Response Status e v i e w e r 1 Introduction Te This document is an excellent effort but it is restrictive Specific devices were Resolved rr in that only limited hardware is considered. The WWD removed from the document y warning system is under development and and generic WWD detection H experimentation in at least three Districts. It is devices are mentioned. en premature to limit the equipment type and software sl updates that may be necessary to implement the ey program. Figure 1.1 Ro Why all the historical data? Anyone reading this We removed text and Resolved m ConOps knows what SunGuide is. referenced the website for on more background a information. Bu rk e 2.2 Contacts Ro If you make this a part of the document, won’t it have to Yes, but only for new and Resolved m be changed everytime someone leaves? modified documents. on a Bu rk e 3.1 “are” Te The type of equipment should not be limited. Almost Specific devices were Resolved rr every day we are learning of equipment that may be removed from the document y suitable. So far, two camera units, several radars and in and generic WWD detection H pavement loops are being considered. This CO should devices are mentioned. en not limit any equipment that can be tested. sl ey

ID# Reference R Comment Response Status e v i e w e r 3.1 1. “devices” Ro This should be more generic since the data could come Specific devices were Resolved m from more than those two devices. removed from the document on and generic WWD detection a devices are mentioned. Bu rk e 3.1 1. “devices” D Are these the only devices that will work? Doesn’t the Specific devices were Resolved av State frown on specifying only one device that will removed from the document id work? Shouldn’t they write a spec that requires the and generic WWD detection H device have the ability to detect a vehicle traveling the devices are mentioned. o wrong way without stating that the Wavetronix and w TAPCO are the only devices that will work? ell 3.1 2. b. “detection” Te Several vendors are supplying trial units. Specific devices were Resolved rr removed from the document y and generic WWD detection H devices are mentioned. en sl ey

ID# Reference R Comment Response Status e v i e w e r 3.1 4. d. i. “Messages should not be posted to D There is usually confusion with which direction the Discussed and conops Resolved motorists in the other direction” av motorist is traveling and which direction is the wrong updated for one direction for id way. The messages must be posted immediately and WWD detection device H sorting out which direction is which takes too much events but to give the o time. I recommend posting DMS messages in both operator the option to w directions like we do here. I would rather alert too choose the one direction or ell many drivers than post in one direction that may be the both directions for manually wrong direction. entered events 3.1 4. d. i. “of” Te To add, some of our alerts come from cell calls. A Discussed and conops Resolved rr significant portion of the time, the motorist does not updated for one direction for y know the direction they are traveling. Posting on both WWD detection events and H sides is prudent. to give the operator the en option to choose the one sl direction or both direction ey for manually entered events

ID# Reference R Comment Response Status e v i e w e r 3.1 4. d. ii. “response” Ro Why would anyone be emailed? Is this intended to be This was requested as one of Resolved m optional? Also stating to send notification to responders the actions to be taken on via email; not a viable option. among other actions. If you a prefer another action Bu instead, you can configure rk the emails to not be sent, e and you can let us know if you have an additional action you would like taken, which would also be configurable/optional. Please let us know what additional action you would like taken. 3.1 5. d. “locked” Ro Will the operators be able to override the lock? Yes, as long as they have this Resolved m permission in SunGuide on a Bu rk e 3.1 5. g. ii. “cameras” Te Does this refer to recording? We do not record any No, this refers to live video, Resolved rr FDOT cameras. not recorded video. The y word “live” was added for H clarity en sl ey

ID# Reference R Comment Response Status e v i e w e r 3.2 2nd bullet “feeds” Te Also need to overcome SunGuide latency in posting DMS was updated to use Resolved rr multiple DMS multithreading in the past. y We will be sure to test with H multiple DMS in testing to en ensure that many DMS can sl post messages at once. We ey will include the test case where some DMS are offline, which can cause other DMS messages to wait for timeouts. 3.3.1 End of 1st sentence “phase” Te This section needs to be broad enough to encompass Specific devices were Resolved rr any equipment that may be determined to be suitable removed from the document y for use. and generic WWD detection H devices are mentioned. en sl ey

ID# Reference R Comment Response Status e v i e w e r 3.3.3 1. “Subsystem” Te D7 is using the “Fence Break” system developed for This is an interesting Resolved rr Alligator Alley with success. approach and device usage. y The conops does not limit H specific devices. We will need en to authorize the additional sl work to copy the safety ey barrier / contact closure protocol into an additional IDS WWD driver so that this device can participate in this WWD operation as an IDS device. 3.3.3 3. a. “driver” Te Due to the time delay, emails are an overrated option This was requested as one of Resolved rr for notification. Also, they take the responders eye off the actions to be taken y the road, perhaps at a critical time. among other actions. It is a H mechanism to notify FHP for en Districts that are not co- sl located. If you prefer another ey action instead, you can configure the emails to not be sent, and you can let us know if you have an additional action you would like taken, which would also be configurable/optional. Please let us know what additional action you would like taken

ID# Reference R Comment Response Status e v i e w e r Figure 2.1 D Suggest there be another option in the “What would The following feature was Resolved av you do?” options. Suggest an “Immediately Post DMS added to accommodate this id Warning Messages in the Vicinity and then Open an scenario. When a phone call H Event” option. is received by a TMC o operator, the operator can w go to the location of the ell reported WWD event, right- click on the map, and click a menu item  “Create WWD event and activate response plan”. A confirmation prompt will appear to confirm that is what the operator intended, and then the system will automatically create an event, a response plan, and activate it according to the configured automatic behavior. Section 2.3.3, item 3.b Al WWD will post automatic messages to DMS. It is not ConOps updated in section ej said the priority of the message when is send to DMS. 2.3.3, item 3.b, first sentence an – to specify that WWD dr detection DMS messages will o have a Priority of 1 M ot ta

ID# Reference R Comment Response Status e v i e w e r Section 2.3.3, item 5 Al WWD will Log the WWD detection information. What ConOps updated in section ej information will be included or recorded? 2.3.3, item 5, to specify what an information will be recorded dr (WWD device or notification o source, time of notification, M detailed location ot information, the ta identification number of the alert produced to operators, and the identification number to the event created). Section 2.1, item 5a and in 2.3.3, item 5 Al WWD Detection Report would include the date, time, ConOps was updated in ej device, location, and associated event. What device will section 2.1, item 5a and in an be included, vehicle detector information, DMS used? 2.3.3, item 5 for clarification dr to replace “device” in that o sentence with “WWD M detection device or ot notification source”. ta Section 2.3.3, item 3b Al Post warning messages to motorists on DMSs upstream ConOps was updated in ej of the WWD detection using a WWD event message section 2.3.3, item 3b, adding an template. What happens if the is a WWD event closed a note to the end of the dr to another District. It could be a good future paragraph: “Note, this can o enhancement to use C2C to post the message include remote District DMSs M automatically on both Districts? available via C2C control.” ot ta

ID# Reference R Comment Response Status e v i e w e r Al 3b. should read “nearest upstream”, rather than There may be some fine ej “nearest and upstream”, which could include tuning needed, which is why an downstream cameras (i.e. nearest cameras and this is configurable. dr upstream cameras, where nearest may be The “nearest and upstream” o downstream). However, it is possible that the first text was removed altogether M selected camera will be downstream of the detector and left up to this ot (slightly) and use a preset that points upstream. configuration. ta Ultimately, this is configurable, so it is up to the district to choose the most appropriate 1-5 cameras – correct? Section 2.3.3, item 5 Al There is a mention of logging detection information for ConOps was updated in ej reporting, but will all actions be logged in the event section 2.3.3, item 5, last an chronology if an event is created (including messages on paragraph with the dr signs and cameras used)? following: “The existing o Event related reports will be M able to be filtered to show ot only WWD event types using ta the existing filtering. This will include all actions taken by operators or by the system in regards to the WWD event.” However, the cameras used is not stored as part of an event and will not be available.

ID# Reference R Comment Response Status e v i e w e r Al Will the software “user” assigned to IDS have to be Yes, part of the installation ej granted permission to update signs and control cameras and configuration of the an or will this bypass the permissions? SunGuide software dr modification will be to add o the necessary permissions. M Also, operators with override ot permissions will always be ta able to then subsequently take control of the cameras as part of existing behavior. Al Why are agency contacts flagged for WWD e-mail, The ConOps was updated ej rather than creating WWD mailing lists? after this was discussed, and an you will be able to add dr individual contacts as well as o mailing lists to be notified of M WWD detection events. ot ta

ID# Reference R Comment Response Status e v i e w e r Al If the software detects that CPU utilization is high, how ConOps was updated with ej will it choose which videos to show and which not to the following: an show? Does it work from the closest one upstream until a. An update Video dr it hits a bandwidth limit? Is there a way for an operator on Desktop o to override (since the vehicle may quickly leave the FOV Window used for M of the closest camera – maybe triggering upstream the alert: a screen ot detectors may factor into this)? picture and ta description showing efficient use of the system. If as a vehicle travels and triggers detections from multiple devices, only additional cameras not already loaded will be added to the VOD window. b. This VOD alert handling will be included with the same release as the Map out of IE enhancement, which will allow VOD to utilize multiple cores on the workstation. This should

ID# Reference R Comment Response Status e v i e w e r Section 2.5.4 Al If we have multiple detectors along a roadway ConOps was updated by ej configured for WWD, will a new alert be generated for adding section 2.5.4 to an each detector as the vehicle travels upstream or is there include this for future dr some filtering that can be used to suppress them? consideration. This needs to o be discussed at the CMB. M ot ta Section 2.5.5 Al When messages are sent via SMS, will the software SunGuide does not currently ej ensure that the message size fits within SMS 160 alter the message for SMS an character limit? Does it truncate, abbreviate, … ? recipients. The SMS service dr provider will break the o message up into multiple M messages. ot ConOps was updated by ta adding section 2.5.5 to include this for future consideration for SunGuide (not specific to WWD detection response emails), to add a flag to an email address in the system if it should be formatted for SMS maximum character limit compatibility.

ID# Reference R Comment Response Status e v i e w e r Al If we have a detector that is misbehaving and producing ConOps was updated in ej erroneous WWD events, can it be blocked without section 2.3.2 to mention that an taking the detector out of service? (I am not sure how SunGuide treats TSS and dr likely it would be that the WWD mechanism would fail WWD devices independently o in this way with the detector working properly with independent M otherwise other than a misconfiguration.) communications channels, ot and either the TSS or the ta WWD can be put out of service without impacting the operation of the other. Section 3.3.3 4c Al In 3.3.3 4c (page 8), it says Pop up the video on desktop ConOps was updated to ej view of the nearest camera zoomed out and upstream remove 2.3.3 4c since the an of the location… pop up is covered in the next dr Same issue as before – this should read nearest item. o upstream camera (or nearest camera configured for this M location), and it needs rephrased to talk about the view ot separately from the camera ta Section 3.3.3 4c Al In 3.3.3 4c (page 8), it says Pop up the video on desktop ConOps was updated in the ej view of the nearest camera zoomed out and upstream 2.3.3.4d (now 4c) to read: an of the location… “Pop up the video on dr Shouldn’t it say “at the selected preset”, rather than desktop view of the nearest o “zoomed out” and upstream CCTV cameras M at the configured preset if ot configured to for the WWD ta detection device.”

ID# Reference R Comment Response Status e v i e w e r Section 2.1, item 4g Al Once an operator takes responsibility for the alert, do ConOps was updated in ej the alerts on other operators’ workstations go away? section 2.1, item 4g to clarify an that the VOD window dr contains the alert handling o dialog and the camera M viewers. Once the alert is ot handled, the alert handling ta viewer goes away but the camera video viewers remain in the VOD window, on the screen for all operators.