1 / 40

Agenda

SunGuide TM Software Development Project Release 4.2 FHP/CAD + AVL/RR Design Review January 8, 2009. Agenda. Introductions. Agenda. Meeting Objectives. Requirements: Provide a high level review Provide SwRI’s interpretation (via a design) of the requirements Design

yuma
Télécharger la présentation

Agenda

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. SunGuideTM Software Development ProjectRelease 4.2 FHP/CAD + AVL/RR Design ReviewJanuary 8, 2009 R4.2 Design Review

  2. Agenda R4.2 Design Review

  3. Introductions R4.2 Design Review

  4. Agenda R4.2 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 R4.2 Design Review

  6. Agenda R4.2 Design Review

  7. Release 4.2 Development Activities R4.2 Design Review

  8. FHP CAD Interface Server FHP CAD FHP/CAD Overview • Goal is to make the communication of event information between FHP dispatchers and FDOT operators faster and more efficient • FHP CAD Interface Server consolidates, filters, and redistributes FHP CAD data to each subscribing SunGuide deployment • SunGuide allows the operator to process incidents as well as process updates to those incidents. R4.2 Design Review

  9. Agenda R4.2 Design Review

  10. FDOT Concept of Operations

  11. Operational Concept Regional Communication Centers SunGuide District 1 Fort Myers FHP Incident Driver IDS Jacksonville SunGuide District 2 Lake Worth Statewide FTP Site FHP Incident Driver IDS Miami Orlando FHP CAD Interface Server Tampa Tallahassee SunGuide District 7 FHP Incident Driver IDS

  12. Operational Concept • FHP Interface Service • Retrieves alerts from the FHP CAD FTP site and distributes to the FDOT districts based on subscriptions • IDS FHP Incident Driver • Handles the connection between the FHP CAD Interface and Incident Detection Subsystem (IDS) • IDS Subsystem Update • Notifies GUI of new and updated alerts • Stores alerts and responses to alerts in the database • GUI Updates • Displays FHP Alerts to the operator • Provides response dialog and event creation dialog • Display events on the Operator Map R4.2 Design Review

  13. FHP Alert GUI • FHP Incident Alert Dialog • Consistent with other types of alerts generated by IDS R4.2 Design Review

  14. FHP Alert GUI 14 R4.2 Design Review Action Choices • Create New Event • Create Secondary Event • Set Responder Arrival • Dismiss as Already Detected • Dismiss as False Alarm • Associate to Existing Event • Acknowledge, Take No Action Jan 8, 2009

  15. FHP Alert GUI 15 R4.2 Design Review Event Field Population • Populated with the closest EM location found • All information contained in the alert is logged in the comments section of the event Jan 8, 2009

  16. Alert Processing Choices • Create New Event • Creates a new Event • Create Secondary Event • Creates a new Secondary Event • Set Responder Arrival • Fills in the FHP incident number in a selected event • Sets the responder arrival field in the selected event • Operator is required to own the event • Associate to Existing Event • Fills in the FHP incident number in a selected event • Operator is required to own the event *These actions will allow updates. When updates are displayed, the Event ID of the event that was previously created or associated is displayed in addition to the information about the alert. R4.2 Design Review

  17. Alert Processing Choices 17 R4.2 Design Review Acknowledge, Take No Action • Logs alarm as acknowledged • Allows updates • Updates are treated as new alerts Dismiss (False Alarm or Already Detected) • Logs alarm as dismissed • Does NOT allow updates • This action is NOT reversible so alert updates with the same ID will NOT be seen by the operator Jan 8, 2009

  18. Communication Alarms • Loss of FHP Interface Server Connection • Occurs if the FHP Interface Server disconnects suddenly or is not connected within 1 minute of the FHP Incident Driver being started • All deployments will receive this alert R4.2 Design Review

  19. Communication Alarms 19 R4.2 Design Review Loss of FTP Server Connection • Occurs when the FHP Interface Server fails to connect to the FTP site to retrieve alert information • All deployments will receive this alert Jan 8, 2009

  20. Communication Alarms 20 R4.2 Design Review Stale FHP CAD RCC Files • Issued only if a file that contains a county that IDS has subscribed to has not been updated in a configured amount of time. • Only issued to the deployments subscribing to counties included in the stale file. Jan 8, 2009

  21. FHP Interface Server Configuration Options • FTP Site • Host, port, username, password • Local Directory to store current FTP files • Interface only supports data from a single FTP site • Access • List of usernames and passwords for all users • Timing • Retrieve Interval • How often to get new alerts from the FTP site • Stale Data • The maximum time limit a file should go without an update • Stale Data Multiplier • Number of retrievals containing stale data before next Stale Data Message is sent R4.2 Design Review

  22. FHP Incident DriverConfiguration Options 22 R4.2 Design Review Each SunGuide deployment can have a unique filtering configuration County Filtering • Can subscribe to any county in the state • Supplying no counties will return all alerts in the state • Case-insensitive, punctuation insensitive • St. Lucie = ST LUCIE, stLUCIE, ST.LuCiE • “St. Lucie” DOES NOT match “South St. Lucie” Roadway Filtering • Filters alerts after the county filter has been applied • Case-insensitive and punctuation insensitive • Searches for given text inside a given roadway • I-95 = i95, i 95, i-95, I 95, I95 (DOES NOT match SR-95) • I-95 DOES match “South I-95” or “i-95 Florida Drive” FHP Interface Server location • Host, port, username, password Jan 8, 2009

  23. Limitations of FHP Data • Inconsistent Roadway Naming • I-95 and SR-9 are the same road require two different entries in the subscription list (unless returning all roadways) • Linear References and Directions • Uses a predefined list of references and directions to parse data • Incorrect Formatting • Worst case • 16450 SE FEDERAL HIGHWAY [JDSP MAIN ROAD] [HOBE SOUND] • Missing “x[“ to split the roadway and cross street • Alert is disregarded because it can not be parsed correctly • Other cases • I-75 SB [I-75 SB] x[MM116.0] [BONITA SPRING] • Roadway = I-75, Dir = Southbound, Linear Reference = I-75 SB • Could result in odd references, but will still result in a valid alert • For parsing specifics, refer to the FHP Data Parsing document R4.2 Design Review

  24. Agenda R4.2 Design Review

  25. Questions? R4.2 Design Review

  26. Agenda R4.2 Design Review

  27. Agenda R4.2 Design Review

  28. Overview • Current AVL/RR implementation feeds Event Update and EM and AVL configuration data from SunGuide to the Road Ranger. The information pushed into SunGuide from the Road Ranger is: • Vehicle status and location (AVL information) • Event comments • AVL/RR communications interface needs to be enhanced to include a additional bi-directional flow of information. R4.2 Design Review

  29. Agenda R4.2 Design Review

  30. District 7 ConOps V2 R4.2 Design Review

  31. AVL/RR Architecture R4.2 Design Review

  32. Operational Concept • Receive event data from tablet • Add a new, in-progress event • Update event data, including: • Lane blockage • RR activities • Involved Vehicles • Ability to close an event (or leave open, ex: abandoned vehicles) • Does not change existing functionality • Enhanced behavior is driven by new data being sent by the RR device. • If the RR device does not use any of the new schemas, then system maintains the SG 3.x functionality • No changes to GUI (Operator Map, Admin Editor) R4.2 Design Review

  33. AVL/RR Modifications • AVL/RR subsystem and driver updated to handle enhancements to RRMA ICD • Three new messages added to RRMA ICD: • New Event • Update Event (lane blockage, RR activities, involved vehicles) • Change Event Status • New data is forwarded on to EM subsystem for processing R4.2 Design Review

  34. EM Modifications / Limitations • EM Modifications • EM subsystem updated to process an entire event record in one message • EM will process event updates from AVL/RR • Limitations • TMC Operator and Road Ranger should avoid editing an event at the same time • Events created by AVL/RR will initially show up as being owned by the AVL/RR subsystem • A TMC operator can then take ownership of the event; however, this will not prevent updates received from the RR from being saved • If RR provides new data, unsaved data entered on EM details window for that event will be lost R4.2 Design Review

  35. Agenda R4.2 Design Review

  36. Questions? R4.2 Design Review

  37. Agenda R4.2 Design Review

  38. Documentation / Schedule • Documentation (ones in yellow have already been provided to FDOT): • SRS (Software Requirements Specification) • SIP (Software Integration Plan) • SICP (Software Integration Case Procedures) • SDD (Software Design Document) • SUM (Software Users Manual) • VDD (Version Description Document) • Schedule • FAT currently scheduled for week of Feb 16th • Deployments are not yet scheduled R4.2 Design Review

  39. Agenda R4.2 Design Review

  40. Action Item Summary R4.2 Design Review

More Related