Agenda

1. SunGuideSM Software Development ProjectRelease 3.0 (Follow-up) Design ReviewGeneral SunGuideSM Components - May 31, 2007

2. Agenda Design Review (SunGuide Components Follow-up)

3. Introductions Design Review (SunGuide Components Follow-up)

4. Agenda Design Review (SunGuide Components Follow-up)

5. Meeting Objectives • Discuss: • Issues raised in the original Design Review • Scope discussion: • What can be absorbed in the current effort • What needs to be deferred to future releases • Not an objective: • Revise requirements Design Review (SunGuide Components Follow-up)

6. Release 3.0 Development Activities Design Review (SunGuide Components Follow-up)

7. Action Items – recapSwRI AIs will be throughout slides Design Review (SunGuide Components Follow-up)

8. Action Items – recap: con’tSwRI AIs will be throughout slides Design Review (SunGuide Components Follow-up)

9. Action Items – recap: con’tSwRI AIs will be throughout slides Design Review (SunGuide Components Follow-up)

10. Summary Of Issues • “Preserve the look and feel of R2.2” • Based on SUM 2.2.2 • Alert bar across the top • Alert sub-window with event list • Incorporating functionality and changes based on May 8-9 Review • “Multi-function interface” of PM window preserved • Event list with alert sub-window • Road Rangers (with AVL) • CCTV Blocking • Audit function • Reporting Design Review (SunGuide Components Follow-up)

11. Summary Of Issues – con’t • Map window on right monitor, EM window on left • Preserved ability to place windows, SunGuide can “remember” placement • Opening multiple EM windows presents technical challenges, being addressed • Road Rangers with EM • Implement D4 ICD (bi-directional IP communication) • Implement D7 ICD (URL file access) • Integration of AVL with Road Rangers • Reconsidered separate subsystems • Coalesced into one • Reduced some complexity • Introduced some complexity Design Review (SunGuide Components Follow-up)

12. Operator GUIs:FDOT Direction for Future GUIs • For GUIs in development for 3.0: • Device GUIs (e.g. VSL) will be in SEPARATE windows in a “grid style” • GUIs specifically related to “Event Management” will be in a SINGLE window with “Tabs” • Will use the R2.2 “blue/green” color scheme • IS THIS CORRECT??? D4 Comment: Will the tabs be implemented like the green menu bar in the EMPM GUI or will it simply be a collection of pages opened using IE7 tabbed browsing? Should we take the screenshot as an example or an implementation possibility? If it uses IE7 tabs, will operators need to open each tab one at a time or will all relevant tabs be opened at once automatically? What happens if an operator closes these tabs, how do they get them back, and how would they be prevented from accidentally opening the tab in another IE window? Design Review (SunGuide Components Follow-up)

13. Agenda Design Review (SunGuide Components Follow-up)

14. Issues from Initial Design Review • Logging to record file changes upon saving • User account name and timestamps • XML file contents • Previous XML file contents will be preserved • Filtering open file dialog to show XML files only • Warn users before closing file without saving Design Review (SunGuide Components Follow-up)

15. Config Editor: Scope Questions • Included in R3 Scope or Requirements and will be implemented: • Filter for Open dialog • Warning message • Not included in R3 Scope or Requirements, but will be implemented within existing budget and schedule: • Logging to Status Logger and preserving previous contents • Not included in R3 Scope or Requirements and will require additional budget and/or schedule: • None identified Design Review (SunGuide Components Follow-up)

16. Config Editor: Scope Questions • Included in R3 Scope or Requirements and will be implemented: • None identified • Not included in R3 Scope or Requirements, but will be implemented within existing budget and schedule: • None identified • Not included in R3 Scope or Requirements and will require additional budget and/or schedule: • None identified Design Review (SunGuide Components Follow-up)

17. Configuration Editor Questions? Design Review (SunGuide Components Follow-up)

18. Agenda Design Review (SunGuide Components Follow-up)

19. Issues from Initial Design Review • Will Event Viewer have an inactivity timeout? • Microsoft IIS session timeouts will serve as inactivity timeout • Internet browser derived requirement: • FEAT22.1.3 (SV002B): The SunGuide Event Viewer Web site shall be accessible through at least the following browsers: AOL, AOL CompuServe, AOL Netscape, Open Ride, Internet Explorer, MSN Explorer, Firefox, Mozilla, Sea Monkey and Opera. • Reworded requirement: The SunGuide Event Viewer Web site shall be accessible through at least the following browsers: Internet Explorer 6 and 7, Firefox, Opera, Netscape, and AOL. Design Review (SunGuide Components Follow-up)

20. Issues from Initial Design Review • Need permissions to restrict data displayed • Two levels of data: public, non-public view • Separate permission for viewing non-public data • FEAT22.1.1 (SV001): SunGuide shall provide a read-only Web site application for TMC personnel that runs on Windows servers and is viewed with modern internet browsers. • Reworded requirement: The SunGuide Event Viewer Web site shall not display identified sensitive data to restricted users (e.g. license plate information, crash data, etc). • What is the list of “sensitive” data that cannot be viewed by the public using the event viewer? (NEED BY June 15, 2007) Design Review (SunGuide Components Follow-up)

21. EV: Scope Questions • Included in R3 Scope or Requirements and will be implemented: • None identified • Not included in R3 Scope or Requirements, but will be implemented within existing budget and schedule: • Two viewing levels for public and non-public data • Not included in R3 Scope or Requirements and will require additional budget and/or schedule: • None identified Design Review (SunGuide Components Follow-up)

22. Event Viewer Questions? Design Review (SunGuide Components Follow-up)

23. Agenda Design Review (SunGuide Components Follow-up)

24. Issues from Initial Design Review • Displaying incident detection data • On both map and EM GUI? • SwRI has CitiLog simulator • Version provided to SwRI does not support the snapshot feature • Request FDOT help to resolve the issue (by June 15, 2007) • Display incident alert bar on map • Conflicts with the current map implementation • Option of using on-top window D4 comment: There are two types of images displayed on the VisioPaD alert screen: live JPEG snapshots and a bitmap image received from VisioPaD depicting the snapshot of the incident with an arrow pointing at the stopped vehicle? The existing VisioPaD subsystem receives the name of the bitmap image file through the "TCP Server" interface, and EMPM accesses the file from the "supervisor" server on a windows file share. The live JPEGs are fetched from the supervisor from a different share, using the citilog camera id to identify the correct file. D4 Comment: No mention of the operator interface for any of the incident detection data. Will it be consistent with 2.2? Design Review (SunGuide Components Follow-up)

25. CitiLog Camera Configuration • New location description field added Design Review (SunGuide Components Follow-up)

26. IDS: Scope Questions • Included in R3 Scope or Requirements and will be implemented: • Displaying incident detection data in alert bar and alert box on EM GUI • Displaying incident detection data as flashing icon on map • Not included in R3 Scope or Requirements, but will be implemented within existing budget and schedule: • None identified • Not included in R3 Scope or Requirements and will require additional budget and/or schedule: • Floating alert bar over map Design Review (SunGuide Components Follow-up)

27. Incident Detection Questions? Design Review (SunGuide Components Follow-up)

28. Agenda Design Review (SunGuide Components Follow-up)

29. Agenda Design Review (SunGuide Components Follow-up)

30. Major Design Decision • At first review: AVL and RR were separate because: • Road Ranger data CONTAINS AVL data • AVL data does not necessarily contain RR data • “Two way” communication need to RR was not understood • After extensive internal discussions, SwRI has modified the design: • RR and AVL will be combined into a single subsystem • Drivers for D4 and D7 formatted data will be developed • Subsystem structure will support the addition of future “AVL only” drivers Design Review (SunGuide Components Follow-up)

31. AVL / RR Functionality:High Level Summary – Vehicle Data • Vehicle tracking: • Icon positioning on map with breadcrumbs • Update based on data received from field • Status: • Icon color changes based on status (Does FDOT want to combine these for color purposes?) • Patrolling • Dispatched • Assisting • Motorist • FHP • Other RR • Meals • Base • Inspection • Mechanical • Out-of-Service • Summary, rollover tool-tip (details shown in later slide) per vehicle • Detailed status per vehicle Design Review (SunGuide Components Follow-up)

32. AVL / RR Functionality:High Level Summary • Summary data via the GUI • Vehicle list • Rollover tool-tip on Map • Location playback via the Map • Historical tracking with breadcrumbs • Single vehicle • Status data • RR status data • RR shift data • Incident data Design Review (SunGuide Components Follow-up)

33. AVL / RR Functionality:High Level Summary – Geo-fencing • Capabilities: • To define a geo-fence, select poly-line with configurable “offset width” on map • Optionally associate a beat with a geo-fence • Geo-fencing alerts • Icon will flash on Map • Will be displayed on alert box in EM Design Review (SunGuide Components Follow-up)

34. AVL / RR Functionality:High Level – Admin Editor • Use Admin Editor to define: • Vehicle groups • Tracked vehicles • Availability status • Vehicle operators • Note: Icons are NOT configurable per FDOT direction Design Review (SunGuide Components Follow-up)

35. AVL / Road Ranger Design Design Review (SunGuide Components Follow-up)

36. Issues from Initial Design Review • Playback to be displayed in existing or pop-up map? • Pop-up map not possible due to technical limitations • Provide existing map display with other icons hidden • Map will center and zoom appropriately • Original view will be restored when exiting playback mode • AV004L (Feat24.3.2) states “As a minimum, the XML data file shall contain the following information: …area of responsibility for the vehicle (zone ID or area ID)…” • Is this the same as “beat”? • What is the source for this data? D4 Comment: We believe this should be by beat. Design Review (SunGuide Components Follow-up)

37. Issues from Initial Design Review • Standardized icons for AVL • The following requirements contradict a decision made in the May 8th-9th DR. • FEAT24.1.2 (AV002V): The icon symbol for each vehicle shall be able to be selected by an operator with administration rights on SunGuide and with appropriate permission for the subsystem. • FEAT24.6.4 (AV004V): If position reports are received for different service vehicles … the operator with appropriate privileges shall be able to assign an icon to represent the type of vehicle for the type of position reports received. • Action Item #136: • FDOT to provide icon ideas to be used for managed vehicle groups Design Review (SunGuide Components Follow-up)

38. Managed Vehicle Group and Availability Status Configuration Design Review (SunGuide Components Follow-up)

39. Vehicle Configuration Is “Road Ranger” the correct term? (Default to checked). Design Review (SunGuide Components Follow-up)

40. Road Ranger Configuration Design Review (SunGuide Components Follow-up)

41. Operator Map Screens Change Vehicle State control is disabled for non-RR vehicles Design Review (SunGuide Components Follow-up)

42. AVL Playback Design Review (SunGuide Components Follow-up)

43. Geo-Fence Editor Design Review (SunGuide Components Follow-up)

44. AVL / RR: Scope Questions • Included in R3 Scope or Requirements and will be implemented: • Playback on existing map with icons hidden • Not included in R3 Scope or Requirements, but will be implemented within existing budget and schedule: • Managed vehicle groups • Two way communication to RR devices using the D4-XML protocol • Ability to globally enable/disable geo-fences • Not included in R3 Scope or Requirements and will require additional budget and/or schedule: • Dispatch of Road Rangers from RR Vehicle List GUI D4 Comment: Is dispatching from the RR Vehicle List required or desired? The current system does not allow this, you must first open the event data edit window and dispatch vehicles to the event from that screen. The RR/SIRV list is not used to dispatch vehicles at all. Design Review (SunGuide Components Follow-up)

45. AVL / RR Questions? Design Review (SunGuide Components Follow-up)

46. Agenda Design Review (SunGuide Components Follow-up)

47. Agenda Design Review (SunGuide Components Follow-up)

48. Issues from Initial Design ReviewEvent Manager (Event List) • Event Manager (Event List) • Alert Bar – display multiple alerts • Alert List – display multiple alert types in a single list (color coded) including the following Alert Types: • Road Ranger Messages • Blocked CCTV Messages • TSS Alerts • VisioPaD Alerts • GeoFence Alerts • C2C Alerts • Etc. • Menu structure • Filter fields identified (green column header) • Floating Alert List, stays on the screen during scrolling Design Review (SunGuide Components Follow-up)

49. Issues from Initial Design ReviewEvent Manager (Event List) Design Review (SunGuide Components Follow-up)

50. Issues from Initial Design ReviewAlert Bar & Alert List • Color coding of Alert Types • Filtering of alerts by Alert Type • Access to alert directly through the Alert Bar • Sorting by alert name or time • Legend Design Review (SunGuide Components Follow-up)