1 / 83

Agenda

Statewide Transportation Management Center Software Library System Software Requirements Review (SRR) and Status Meeting January 8, 2004. Agenda. Agenda. Requirements Process. Organizing original requirements All original STMCSLS requirements are converted into FEAT (feature) requirements

yvette-salas
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. Statewide Transportation Management Center Software Library SystemSoftware Requirements Review (SRR)and Status Meeting January 8, 2004

  2. Agenda STMCSLS Status Meeting and SRR

  3. Agenda STMCSLS Status Meeting and SRR

  4. Requirements Process • Organizing original requirements • All original STMCSLS requirements are converted into FEAT (feature) requirements • Reorganized the structure of the requirements into subsystems • Retained traceability back to the STMCSLS requirement numbers • Updated status of requirements appropriately (Approved, FDOT, and Future) • Created System Level Requirements • Created new category of requirements (SUB) for subsystems • Adds additional functional requirements for the various subsystems • SUB requirements are structured in a hierarchical format • Each new SUB requirement has traceability to a FEAT requirement STMCSLS Status Meeting and SRR

  5. SRS Development • FDOT required the use of Rational RequisitePro in the ITN • Rational has a companion tool, SoDA, that is used to create document templates that are “fed” from other Rational tools (e.g. RequisitePro) • For cost savings, correctness, and maintenance issues, the SRS should be generated using SoDA • SwRI is using SoDA to develop the SRS. STMCSLS Status Meeting and SRR

  6. Requirements View STMCSLS Status Meeting and SRR

  7. Requirements View - continued STMCSLS Status Meeting and SRR

  8. Select Synopsis of some High-Level Requirements STMCSLS Status Meeting and SRR

  9. High-Level Review:User Levels • Five user levels defined: • Administrator: can alter system configuration • Manager: override equipment locks, approval authority • Operator: performs daily operations tasks • Local guest: CCTV control, view status • Remote guest: device control (via C2C), view status • By definition, a user may only belong to a single level STMCSLS Status Meeting and SRR

  10. High-Level Review:DMS • Control a DMS: • Send a message • Terminate a message • Place a DMS online or offline • Set the brightness to Day, Night or Automatic adjusting • Reset the controller (software reset) • Synchronize the clock with the main process time • DMS status information • Poll for current status information • Echo the message displayed • Fan, pixel or lamp status detail • Save messages for sending to DMSs • Automatic polling of devices for status in a configurable time interval STMCSLS Status Meeting and SRR

  11. High-Level Review:CCTV • Camera control: • PTZ • Iris • Focus • Switch control: • Switch input to output • Video tours: • Define tours • Invoke tours • User "locks" a camera before control functions are issued • Note: Video wall configuration is NOT to be supported by the STMCSLS STMCSLS Status Meeting and SRR

  12. High-Level Review:Traffic Data • Traffic detection intervals may be specified in the following range (10s - 60m) • Detectors may be mapped to links and lanes • Highways may be defined to contain links • Alarm thresholds may be specified for speed, volume and occupancy • If the user subscribes, link updates will be received at the specified interval. • If the user subscribes, alarm events will be received. • Sensor data may include raw values or a smoothed average value. STMCSLS Status Meeting and SRR

  13. High-Level Review:GUI • Day to day operator functions will be combined into one primary operator interface, using a browser-based application. • The operator interface will be centered around a fully navigable (pan, scale, zoom, etc.) map which will be available in the background at all times. • Icons representing equipment, incidents, and other appropriate objects will be placed on the map according to GIS coordinates, along with major and minor roadways. • Roadway segments which are instrumented for speed data collection will be colored according to the current speed of that roadway segment. • All functions regarding real time incident information, equipment status and control, etc. will be accessible through the operator interface. • Other functions, such as equipment configuration, user permissions, and system configuration will be accessible through a secondary browser-based interface more suited to configuration. STMCSLS Status Meeting and SRR

  14. High-Level Review:Incident Management • Incidents or congestion will be automatically generated based on a user defined threshold for speed, volume or occupancy (see Traffic) • Incidents may be manually entered by a user. • A response plan may be generated based on incident location. • A response plan may consist of equipment to be activated or resource personnel to be directed to the incident. • Data collected for an incident should include: • Incident type • Location • Weather conditions • Duration • Traffic conditions (congestion, etc) STMCSLS Status Meeting and SRR

  15. High-Level Review:Logging • Log device changes: • DMS message change • Camera control acquisition • HAR message change • Log user actions: • Add/modify/delete equipment/messages/data • Changes to user permissions • Modifications to system default values • Log system errors: • Network connectivity lost • Loss of process communication • Database access errors STMCSLS Status Meeting and SRR

  16. High-Level Review:Reports • Device status by filter • Devices of type X that are online • Devices of type X that are offline • Devices of type X that are in communication failure • Devices of type X that have an active display (e.g., message) • Device history (e.g., messages displayed on a DMS during a time span) • Incidents by status • Open • Verified • Cleared • Closed • User actions per time frame filtered by users? • Congestion history STMCSLS Status Meeting and SRR

  17. Total Requirements STMCSLS Status Meeting and SRR

  18. Requirements Status • Completed Requirements • DMS • CCTV • HAR • Data Distribution • IM (Incident Management) • EH (Executive Handler) • SL (Status Logger) • TSS (Traffic Sensor Subsystem) • C2C (Center-to-Center) • GUI (Graphical User Interface) • Will be updated during Release 2a design activities: • IMS (Inventory and Maintenance) • RWIS (Weather) • DA (Data Archiving) • EC (Emergency Coordination) STMCSLS Status Meeting and SRR

  19. Agenda STMCSLS Status Meeting and SRR

  20. Requirements to Discuss • The following “groups” of requirements needs to be discussed (SwRI needs closure on the issues associated with these requirements): • Non-testable requirements • Reworded requirements • Requirements assigned to FDOT (from SwRI) because SwRI control STMCSLS Status Meeting and SRR

  21. Requirements to Discuss:Non-testable STMCSLS Status Meeting and SRR

  22. Requirements to Discuss:Non-testable - continued STMCSLS Status Meeting and SRR

  23. Requirements to Discuss:Reworded STMCSLS Status Meeting and SRR

  24. Requirements to Discuss:Assigned to FDOT STMCSLS Status Meeting and SRR

  25. Requirements to Discuss:Assigned to FDOT - continued STMCSLS Status Meeting and SRR

  26. Requirements to Discuss:Assigned to FDOT - continued STMCSLS Status Meeting and SRR

  27. Agenda STMCSLS Status Meeting and SRR

  28. Agenda STMCSLS Status Meeting and SRR

  29. Issues Identified During Small Group Requirements Meetings • User levels: • Validate users against Windows domain credentials. SwRI response: • During initial logon to the STMCSLS environment users will be validated against domain credentials. • After initial logon, application security model will be used • Allow operators to perform “DMS Conflict Resolution”. SwRI response: • Need FDOT resolution STMCSLS Status Meeting and SRR

  30. Issues Identified During Small Group Requirements Meetings – con’t • DMS: • Operators should be restricted to only displaying messages from the DMS message library. SwRI response: • A restriction for a predefined message means that the DMS Subsystem would have to search through all messages in the database when a send message is received to ensure the message was in the database. • Need FDOT resolution • CCTV: • Require CCTV control from either mouse or arrow keys. Use “scroll wheel” for zooming. SwRI response: • Investigating if browser can support requests • Browser based CCTV PTZ performance may not be acceptable. SwRI response: • Extensive testing in the SwRI labs, demo to be provided during SRR. STMCSLS Status Meeting and SRR

  31. Issues Identified During Small Group Requirements Meetings – con’t • CCTV: • On CCTV control, option to use either analog speed control or fixed speed control. SwRI response: • SwRI investigating providing both capabilities • Need FDOT resolution • Incident: • Need to be able to change incident location. SwRI response: • Incidents are tied to a spatial location when they are created, allowing the position to be altered could be problematic – need FDOT resolution. STMCSLS Status Meeting and SRR

  32. Issues Identified During Small Group Requirements Meetings – con’t • GUI: • Prefer a “fixed frame” for control panel functions. SwRI response: • GUI will be developed with the “controls” locked into the GUI • Adhere to 508 ADA GUI requirements when possible. SwRI response: • Will implement as feasible • Reporting: • Review FIDS reports. SwRI response: • Development of reports is quite limited in the STMCSLS. • SwRI needs FDOT to provide sample reports STMCSLS Status Meeting and SRR

  33. Issues Identified During Small Group Requirements Meetings – con’t • General: • Device support: what devices will be supported? SwRI response: • Working with FDOT on adding additional device drivers STMCSLS Status Meeting and SRR

  34. Agenda STMCSLS Status Meeting and SRR

  35. Open Discussion on SwRI STMCSLS Requirements STMCSLS Status Meeting and SRR

  36. Agenda STMCSLS Status Meeting and SRR

  37. Agenda STMCSLS Status Meeting and SRR

  38. CCTV GUI Demonstration • Purpose: • Show “speed” of GUI to camera commands • Evaluate latency issues with MPEG-2 video encoding/decoding • Features: • Analog controls • Pan / tilt concurrently • Limitations: • Currently only supports Pelco protocol STMCSLS Status Meeting and SRR

  39. CCTV GUI Demonstration Software Setup STMCSLS Status Meeting and SRR

  40. Agenda STMCSLS Status Meeting and SRR

  41. Open Discussion on SwRI STMCSLS Requirements STMCSLS Status Meeting and SRR

  42. Agenda STMCSLS Status Meeting and SRR

  43. Project Web Site http://stmcsls.datasys.swri.edu STMCSLS Status Meeting and SRR

  44. Proposed STMCSLS Architecture Robust Extensible Flexible Scalable Configurable Proven STMCSLS Status Meeting and SRR

  45. Release-Oriented Development Approach Release 1Release 2aRelease 2b not in scope STMCSLS Status Meeting and SRR

  46. “Generic Subsystem” Design • Based on the TransGuide implementation concept • A generic C# subsystem has been developed: • Used by all “ported” TransGuide subsystems • Used in the future for new subsystems • Each subsystem instantiates the generic subsystem • Maximizes “common” implementation approach STMCSLS Status Meeting and SRR

  47. Release 1: Core software framework: Database Process viewer Status logger User interface Map DMS subsystem, drivers for: NTCIP Florida MIB Mark IV version 2.5 CCTV subsystem, drivers for: NTCIP camera support American Dynamics 2050 switch Traffic Detection, driver for: Bitrans 238I-95 Incident management subsystem Release 2a: Core software framework upgrade Center-to-Center FDOT Central office configuration Ramp metering CCTV subsystem, drivers: SunGuide protocol RWIS Archive data HAR Web server Emergency evacuation Release 2b: Inventory and maintenance Scope of STMCSLS Effort STMCSLS Status Meeting and SRR

  48. Project Management: PM / Meetings / Reviews Process documents Interface Control Documents (ICDs) Core software framework: Database Process viewer Status logger User interface Map DMS subsystem, drivers for: NTCIP Florida MIB Mark IV version 2.5 CCTV subsystem, drivers for: NTCIP camera support American Dynamics 2050 switch Traffic Detection, driver for: Bitrans 238I-95 Incident management subsystem Status of Release 1 Activities STMCSLS Status Meeting and SRR

  49. Deliverable Status • Documents • Delivered: • 25 (23 early, 2 late) • Pending: • Waiting for FDOT comments: 3 documents • Concept of Operations (waiting on final SRR input) • Software Security Plan (in review) • Two complete but not delivered (waiting for Oracle licenses from FDOT) • Status reports: 3 delivered (none pending) All available on project web site. STMCSLS Status Meeting and SRR

  50. Cost Status • Release 1: • Budget amount: $3,208,052 • As of 1/2/04, ~$452,000 has been expended • Release 2a: • Budget amount: $2,074,276 • As of 1/2/04, $0 has been expended • Release 2b: • Budget amount: $245,311 • As of 1/2/04, $0 has been expended STMCSLS Status Meeting and SRR

More Related