1 / 163

SunGuide SM Software Development Project Release 3.0 Design Review May 8-9, 2007

SunGuide SM Software Development Project Release 3.0 Design Review May 8-9, 2007. Agenda. Introductions. Agenda. Meeting Objectives. Requirements: Provide a high level review Provide SwRI’s interpretation (via a design) of the requirements Design High level architectural overview

danielle-briggs
Download Presentation

SunGuide SM Software Development Project Release 3.0 Design Review May 8-9, 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SunGuideSM Software Development ProjectRelease 3.0 Design ReviewMay 8-9, 2007

  2. Agenda Design Review

  3. Introductions Design Review

  4. Agenda Design Review

  5. Meeting Objectives • Requirements: • Provide a high level review • Provide SwRI’s interpretation (via a design) of the requirements • Design • High level architectural overview • Operator actions and reactions • Prototype screens / reports • Not an objective: • Revise requirements Design Review

  6. Release 3.0 Development Activities Design Review

  7. SRS Discussion • SwRI’s interpretation of FDOT’s requirements • FDOT “system” requirements assigned as “FEAT” requirements • SwRI “derived” requirements listed as “SUB” requirements • Document contains requirements from < R3.0 • The text of “FEAT” requirements is contractually limited (i.e. do not edit) Design Review

  8. Agenda Design Review

  9. Configuration Editor • ‘config.xml’ file is the master configuration file for all SunGuideSM processes • If an error is made in editing the XML file it can cause serious side effects • Windows based editor will be developed that simplifies the editing process (and make it less error prone) Design Review

  10. Configuration Editor: Requirements • Provide a “easy to use” editor to facilitate editing of the SunGuideSM configuration file (config.xml) • Changes will be to the parameters identified in the VDD (no source code changes will be required) • Appropriate permissions will be required to access the editor Design Review

  11. Config Editor: GUI Mockups • The “File” menu provides options to open a configuration file and to save the edited configuration file • Selecting “Open” from the file menu opens a dialog to used to select the configuration file for editing. Design Review

  12. Config Editor: GUI Mockups – con’t • Selecting a configuration file to open • Clicking “Open” after selecting the file will load the configuration file into the editor Design Review

  13. Config Editor: GUI Mockups – con’t • Users can drill down into the file to select options to change Design Review

  14. Config Editor: GUI Mockups – con’t • Parameters may be modified by editing the value in the panel on the right side Design Review

  15. Config Editor: GUI Mockups – con’t • After modifications are made, changes must be saved using the File menu Design Review

  16. Config Editor: GUI Mockups – con’t • Creation wizards can be used to help make a large change to the file safely at an appropriate location. Design Review

  17. Configuration Editor Questions? Design Review

  18. Agenda Design Review

  19. Event Viewer (EV) • Read-only web site displaying: • Active events with a lane blockage • Active events without a lane blockage • Recently inactive events • Details page displays information about a specific event record • Runs on a Windows IIS server • Prompts for a username and password Design Review

  20. Event Viewer: Requirements • Logout button provided to end secure access • Data will refresh automatically at a configurable interval • Events will be flagged as ‘inactive’ after a configurable amount of time has passed without activity Design Review

  21. Event Viewer: Requirements – con’t • Allow access restriction based on IP address • Support use of SSL security via Microsoft IIS Design Review

  22. Event Viewer: Requirements – con’t • Sections of the event list will differ in background color • Selecting (clicking) an event will open then event details for the event • Event details will contain: • Event data • Related Road Ranger data • Agency response data • Event chronology summary Design Review

  23. Event Viewer: Requirements – con’t • Associated events will contain links between event details pages Design Review

  24. Event Viewer: Derived Requirements • Accessible via SunGuide website • Site will not be accessible to IP addresses outside the allowed range specified within IIS Design Review

  25. Event Viewer: GUI MockupsLogin Screen • ASP.NET application • IIS provides the ability to restrict users by: • Domain • IP (single or range) • Username / password • Application security will be based on SunGuideSM user credentials Design Review

  26. Event Viewer: GUI MockupsSummary and Detail Screens • Directed to retain existing D4 Smart Viewer “look and feel”: • Yes? • Events summarized by: • Active with lane blockage • Active with no lane blockage • Inactive events • Details presented in a READ ONLY fashion Design Review

  27. Event Viewer Questions? Design Review

  28. Agenda Design Review

  29. Incident Detection: Design Overview • Subsystem Development • Design new database tables • Subscribe for incident alarms from VisioPaD driver • Subscribe for incident alarms from TSS Alarm driver • Publish combined alarms to subscribers • Log alarms to database • VisioPaD Driver Development • Accept incident data from CitiLog TCP Server • Publish incident alarms to ID subsystem Design Review

  30. Incident Detection: Design Overview – con’t • TSS Alarm Driver Development • Subscribe for TSS alarm data from TSS • Publish incident alarms to ID subsystem • GUI Development • Adapt current TSS Alarm handling to incident alarms • Send Alarm Confirmed or Canceled message to IDS • Create and send new Event message to EM • Develop Admin Editor screen for defining CitiLog camera locations Design Review

  31. Incident Detection: Requirements • Incident detection (previously part of TSS) will be centralized into the Incident Detection subsystem • When potential incidents are identified, the alert will be published to Data Bus – subsystems subscribed to incident alerts will be notified (e.g. EM subsystem) • A driver for VisioPAD will be developed Design Review

  32. Agenda Design Review

  33. Agenda Design Review

  34. Incident DetectionArchitectural Overview • Database stores alerts and Citilog camera mapping data • IDS Subscribe Handler manages sending alert data to clients • IDS Retrieve Data Handler manages reception of data from drivers • IDS Config Handler delivers CitiLog camera mapping data to VisioPaD driver • VisioPaD Event Handler manages connection with and data from the CitiLog server • TSS Alarm Handler subscribes for and manages alarm data from TSS Design Review

  35. Incident DetectionAdministrative Editor (for “devices”) • Device location • Device identifier information • Associate closest SunGuideSM CCTV Design Review

  36. Incident DetectionOperator Interface • Alarm dialog will be presented to users subscribed via Data Bus • Location will be provided Design Review

  37. Incident DetectionOverview of Data Flow – client to drivers Design Review

  38. Incident DetectionData Flow – Subsystem to Driver Design Review

  39. Incident Detection Questions? Design Review

  40. Agenda Design Review

  41. AVL: Design Overview • Subsystem Development • Design new database tables • Subscribe for vehicle location data from Road Ranger Location driver • Subscribe for vehicle location data from External Data driver • Publish location update data to subscribers • Store location update data to database • Develop queries for retrieving vehicle track records • Develop geo-location queries for geo-fence violations • External Data Driver Development • Develop file retrieval from URL, FTP, and shared folder sources • Parse and translate AVL data to SG format • Publish external source location data to AVL subsystem Design Review

  42. AVL: Design Overview – cont. • Road Ranger Location Driver Development • Subscribe for Road Ranger location data from RR subsystem • Publish Road Ranger location data to AVL subsystem • GUI Development • Develop vehicle icon selector • Develop geo-fence creation and editing facility • Develop vehicle status and position updates for display • Develop vehicle list, summary, and detail dialogs • Develop “Find Vehicle on Map” facility • Develop “breadcrumb track” data retrieval and display • Develop Admin Editor screen for add and deleting tracked vehicles • Develop Admin Editor screen for maintaining AVL data source locations Design Review

  43. AVL: Requirements • New Admin Editor screens for managing external sources and tracked vehicles will be developed • Time-stamped location data for tracked vehicles will be stored in the SunGuide database • GUI will include support for icon selection and a tabular vehicle list window Design Review

  44. AVL: Requirements – cont. • An External Sources driver will be developed to retrieve XML-formatted vehicle location data from URL, FTP, and shared folder sources • Current position of tracked vehicles will be shown on the Operator Map using selectable icons • A vehicle status summary “tooltip” dialog will be displayed by mouse hovering Design Review

  45. AVL: Requirements – cont. • AVL will support at least four availability status values • A detailed vehicle status dialog will be available when clicking on a vehicle icon or selecting a vehicle from the vehicle list • Detailed vehicle status data will include stopped time or moving time as appropriate Design Review

  46. AVL: Requirements – cont. • External source data will be re-formatted and re-ordered as necessary • The location of the closest road will be substituted and flagged for inexact location data • A Road Ranger Location driver will be developed that will retrieve RR location data from the RR subsystem • Vehicle locations on the map will be updated as data is received Design Review

  47. AVL: Requirements – cont. • AVL will need roadway and cross-street geo-data in Oracle Locator tables to convert lat/lon to roadway text description • AVL and Operator Map will support real-time and playback display of previous location position (“breadcrumb trail”) • Position replays will support vehicle selection and time span selection Design Review

  48. AVL: Requirements – cont. • A new map-based geo-fence editor GUI will be developed, similar to the TSS Link Editor • Geo-fence polygon data will be stored in Oracle geo-spatial tables that support queries for finding points in shapes Design Review

  49. AVLArchitectural Overview • Database stores vehicle track and external sources data • AVL Subscribe Handler manages sending location data to clients • AVL Retrieve Data Handler manages reception of data from drivers • AVL Config Handler delivers external sources data to External Sources driver • External Sources Handler manages location data retrieval from external sources • RR Location Handler subscribes for and manages location data from Road Ranger Design Review

  50. AVL Administrative EditorAdministrative Editor – Add/Edit Vehicles Design Review

More Related