Software Requirements Specification Document

Transcription

1 Statewide Transportation Management Center Software Library System: Software Requirements Specification Document STMCSLS-SRS Draft Prepared for: Florida Department of Transportation ITS Office 605 Suwannee Street, M.S. 90 Tallahassee, Florida (850) December 22, 2003

2 Document Control Panel File Name: STMCSLS-SRS Draft.doc File Location: STMCSLS CM Repository CDRL: Name Initial Date Created By: Lynne Randolph, SwRI LAR 12/01/03 Reviewed By: Robert Heller, SwRI RWH 12/01/03 Steve Dellenback, SwRI SWD 12/15/03 Stephen Novosad SwRI SEN 12/22/03 Steve Dellenback, SwRI SWD 01/27/04 Stephen Novosad SwRI SEN 01/27/04 Modified By: Lynne Randolph, SwRI LAR 01/24/04 Completed By: STMCSLS-SRS Draft i

3 Table of Contents 1. Scope Document Identification Project Overview Related Documents Contacts Requirements Accessing and Viewing the Requirements Updating the Requirements Requirements Tables Center to Center (C2C) Closed Circuit Television (CCTV) Data Archiving (DA) Data Distribution (DD) Dynamic Message Sign (DMS) Executive Handler (EH) Graphical User Interface (GUI) Highway Advisory Radio (HAR) Incident Management (IM) Inventory Maintenance System (IMS) Road Weather Information System (RWIS) Logging (SL) Transportation Sensor System (TSS) User Privileges (USER)) Qualification Provisions Requirements Traceability STMCSLS-SRS Draft ii

4 List of Tables Table 2.1 Requirement types for the STMCSLS...4 Table 2.2 STMCSLS Requirement Attributes...4 Table 2.3 All Feature Requirements...6 Table 2.3 All Feature Requirements...7 Table 2.4 Center to Center FEAT Requirements Table 2.5 Center to Center SUB Requirements Table 2.6 CCTV FEAT Requirements Table 2.7 CCTV SUB Requirements Table 2.8 Data Archiving (DA) FEAT Requirements Table 2.9 Data Archiving (DA) SUB Requirements Table 2.10 Data Distribution (DD) FEAT Requirements Table 2.11 Data Distribution (DD) SUB Requirements Table 2.12 DMS FEAT Requirements Table 2.13 DMS SUB Requirements Table 2.14 Executive Handler (EH) FEAT Requirements Table 2.15 Executive Handler (EH) SUB Requirements Table 2.16 Graphical User Interface (GUI) FEAT Requirements Table 2.17 Graphical User Interface SUB Requirements Table 2.18 Highway Advisory Radio (HAR) FEAT Requirements Table 2.19 Highway Advisory Radio (HAR) SUB Requirements Table 2.20 Incident Management (IM) FEAT Requirements Table 2.21 Incident Management (IM) SUB Requirements Table 2.22 Inventory Maintenance System (IMS) FEAT Requirements Table 2.23 Inventory Maintenance System (IMS) SUB Requirements Table 2.24 Road Weather Information System (RWIS) FEAT Requirements Table 2.25 Road Weather Information System (RWIS) SUB Requirements Table 2.26 Logging FEAT Requirements Table 2.27 Logging SUB Requirements Table 2.28 Transportation Sensor System (TSS) FEAT Requirements Table 2.29 Transportation Sensor System (TSS) SUB Requirements STMCSLS-SRS Draft iii

5 Table 2.30 User Privileges (USER) FEAT Requirements Table 2.31 User Privileges (USER) SUB Requirements STMCSLS-SRS Draft iv

6 List of Acronyms ATMS... Advanced Traffic Management System C2C... Center-to-Center CCTV... Closed Circuit Television DA... Data Archiving DD... Data Distribution DMS... Dynamic Message Sign DOT... Department of Transportation FDOT... Florida Department of Transportation FEAT... Feature Requirement HAR... Highway Advisory Radio IM... Incident Management IMS... Inventory Maintenance System ITS... Intelligent Transportation Systems ITN... Invitation to Negotiate RWIS... Road Weather Information System SRS... Software Requirements Specification SUB... Subsystem Requirement STMCSLS... Statewide Transportation Management Center Software Library System SwRI... Southwest Research Institute TMC... Traffic Management Center TSS... Transportation Sensor System XML... extensible Markup Language STMCSLS-SRS Draft v

7 REVISION HISTORY Revision Date Changes Draft December 22, 2003 Initial Release Draft January 27, 2004 Updated based on SRR input and discussion with ITS Central Office STMCSLS-SRS Draft vi

8 1. Scope 1.1 Document Identification The Software Requirements Specification (SRS) details the requirements for the Statewide Transportation Management Center Software Library System. The requirements are separated into two types; features (FEAT) that were specified in the Invitation to Negotiate (ITN) and new subsystem (SUB) requirements determined during initial system design. The requirements for the system are maintained in a database using Rational RequisitePro. This document serves as a starting point for the requirements and discusses how to access, view, and maintain the requirements database. This document is not intended to be a user manual for RequisitePro. For information on using RequisitePro, refer to the hard copy documentation accompanying the product, the RequisitePro online help, or the Rational web site at Project Overview The Florida Department of Transportation (FDOT) is conducting a program that is developing a Statewide Transportation Management Center Software Library System (STMCSLS). The STMCSLS is a set of Intelligent Transportation System (ITS) software that allows the control of roadway devices as well as information exchange across a variety of transportation agencies. The goal of the STMCSLS is to have a common software base that can be deployed throughout the state of Florida. The STMCSLS development effort is based on ITS software available from both the states of Texas and Maryland; significant customization of the software is being performed as well as the development of new software modules. The following figure provides a graphical view of the software to be developed: STMCSLS-SRS Draft 1

9 Figure High-Level Architectural Concept The STMCSLS development effort spans approximately two years. After the development, the software will be deployed to a number of Districts and Expressway Authorities throughout Florida and support activities will be performed. 1.3 Related Documents The following documents were used to develop this document: SwRI Qualification Response: Response to the Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN- DOT-02/ RR, SwRI Proposal No , dated: November 18, SwRI Technical Proposal: Technical Proposal for Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN-DOT-02/ RR, SwRI Proposal No , dated: January 31, STMCSLS-SRS Draft 2

10 SwRI Cost Proposal: Cost Proposal for Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Negotiation Number: ITN- DOT-02/ RR, SwRI Proposal No , dated: January 31, SwRI BAFO letter: Southwest Research Institute Proposal No , Invitation to Negotiate (ITN): Statewide Transportation Management Center Software Library System, Reference: Negotiation Number: ITN-DOT-02/ RR, dated: May 5, FDOT procurement document: Invitation To Negotiate (ITN), Negotiation Number: ITN- DOT-02/ RR, Statewide Transportation Management Center Software Library System, dated: October 21, FDOT Scope of Services: Statewide Transportation Management Center Software Library System: Scope of Services, September 22, FDOT Requirements Document: Statewide Transportation Management Center Software Library System: Requirements Specification, June 3, Southwest Research Institute, TMC Software Study, November 15, Southwest Research Institute, Introduction to an Operational Concept For the Florida Statewide Library, FDOT OCD 1.0, March 31, World Wide Web Consortium (W3) website: STMCSLS Project website: Contacts The following are contact persons for the STMCSLS project: Chester Chandler, ITS Central Office, Liang Hsia, FDOT Project Manager, John Bonds, Senior ITS Specialist, David Chang, ITS Specialist, Steve Dellenback, SwRI Project Manager, Robert Heller, SwRI Software Project Manager, Charlie Wallace, PBF Deputy Project Manager, John Schumitz, PBF Software Project Manager, The following are contacts that will be used by the STMCSLS project team to assure consistency with other FDOT projects and FDOT procedures: Dan Baxter, PB Farradyne, FDOT C2C Project, David Lambert, University of North Florida, RWIS, Bob Colins, PBS&J, Emergency Evacuation, John Fain, FDOT, Comptroller, Jerry Bloodgood, McCain, Ramp Metering Leslie Jacobson, PB Farradyne, Ramp Metering, STMCSLS-SRS Draft 3

11 2. Requirements The following sections describe how to access, view, and update the requirements for the STMCSLS system. 2.1 Accessing and Viewing the Requirements To access the database using RequisitePro, select the Project->Open menu option. Select STMCSLS from the projects list. If STMCSLS does not appear on the list of projects, select Add to add the STMCSLS.RQS project. The database views can be accessed by selecting the Views workplace button. The RequisitePro database has a default Attribute Matrix View defined for each type of requirement. The requirements can be viewed directly from the database views or from this file. This file is intended to allow those who do not have RequisitePro access to the requirements. The RequisitePro database contains more detailed information than can be displayed in this file. There are two types of requirements that are used for the STMCSLS system. Table 2.1 describes each requirement type and lists the RequisitePro view name from which the requirements for that type can be viewed. Requirement Type Functional Functional Table 2.1 Requirement types for the STMCSLS Requirement Type Description Requirements that are features of the system. Requirements for the individual subsystems. RequisitePro View Name FEAT SUB Each requirement in the database has associated attributes. Table 2.2 describes each attribute, acceptable values for the attribute, and the requirement types in which the attribute is used. Attribute Name STMCSLS ID Table 2.2 STMCSLS Requirement Attributes Description The original requirement number as listed in the ITN. The current status of the requirement. values include: The requirement has been proposed but has not been approved. Approved The requirement has been approved. FDOT The requirement is Requirement Types Where Used FEAT FEAT, SUB STMCSLS-SRS Draft 4

12 Attribute Name Test case Traced-From Description assigned to FDOT personnel. Future The requirement has been relegated to a future allocation of funds. Validated The requirement has been validated as being part of the working system. Not approved The requirement has been rejected by FDOT. District request The requirement has been requested by one or more districts. The acceptance test plan test case which validates this requirement. The requirements that can be traced to this requirement from a FEAT requirement. How the Requirement would be tested. Qualification methods include: The functionality would be demonstrated (possibly during an acceptance test.) Inspection The software would be inspected by an Independent Verification and Validation (IV&V) team to confirm the requirement has been met. Test A test program will confirm the requirement has been met. Requirement Types Where Used FEAT, SUB SUB FEAT, SUB 2.2 Updating the Requirements The requirements database can be updated by adding, modifying, and deleting requirements directly from the RequisitePro database views. When the database has been modified, this document should be regenerated. 2.3 Requirements Tables Requirements listed in Table 2.3 have been designated as FDOT responsibility and will not be tested during acceptance testing. STMCSLS-SRS Draft 5

13 Table 2.3 FDOT Feature Requirements STMSCSLS ID A firewall shall provide EAL-4+ certification employing a FEAT1.1.2 shall be available and enabled on the firewall. Firewall "default deny" security policy. security policy Both ASCII and binary logging NW001 FDOT FEAT1.1.3 FEAT FEAT FEAT1.6.5 FEAT8.2.2 FEAT8.4.1 DMZ model to segment LAN traffic RPO shall be less than 0.1% RTO shall be less than 1 hour Public domain/sector software Camera system types MPEG2 displayed on monitors A multi-layer DMZ model shall be used to segment traffic coming into the transaction server(s) from public LAN connections (if any) by being able to access the database layer. have a recovery point objective of having less than one-tenth percent (0.1%) difference between the master database and the recovery copy of the database at all times. The recovery time objective shall be one hour or less. consist of public domain/public sector software (object and source code) wherever possible. The system shall be capable of controlling traditional pan/tilt units as well as the dome camera systems that are commonly deployed in ITS applications and that have a driver developed. The CCTV function shall allow any digital video data or analog video signal that is converted to MPEG2 format from any field device to be displayed on any video monitor or desktop workstation within the TMC system. NW002 DB003 DB001R S002 TV002D TV001S FDOT FDOT FDOT FDOT FDOT FDOT STMCSLS-SRS Draft 6

14 STMSCSLS ID The CCTV function shall allow the same digitized or digital video image to be viewed FEAT8.4.2 simultaneously from multiple View image workstations without conflict if multiple the necessary switching, locations display, conversion and connectivity functionality is supported in the TMC video system. TV002S FDOT FEAT8.4.4 Route video frames to FDOT Central Office. be capable of routing the maximum number of video frames per second over the FDOT network to the FDOT Central Office that can be supported by the hardware video switch or the network. TV005S FDOT Table 2.4 lists the original feature requirements as outlined in the ITN. These requirements have been reorganized to allow subsystem requirements to be better grouped. The original STMCSLS requirement identifier is noted as an attribute in the table. Table 2.4 All Feature Requirements STMCSLS ID FEAT1 General General requirements not relating to particular subsystems or components. FEAT1.1 Network security not prohibit the use of a firewall and the identification of what FEAT1.1.1 ports and hostnames are Allow firewall used to communicate usage between processes shall be provided so allowances can be made to pass through a firewall. S026 Approved FEAT1.1.4 FEAT1.1.5 Operating system workstation security User and user group assignments use windows domain authentication for user login. The workstation security function shall provide the capability to assign specific users and groups to categories that have specific access to levels of the software functionality. S012 Approved WS001 Approved STMCSLS-SRS Draft 7

15 STMCSLS ID The workstation security function shall use encrypted FEAT1.1.6 what levels of software functionality. Encrypted passwords to identify which passwords users or groups can access WS002 Approved Inspection FEAT1.1.7 FEAT1.1.8 FEAT1.1.9 FEAT FEAT FEAT1.2 FEAT1.2.1 FEAT1.2.2 FEAT1.2.3 FEAT1.2.4 User/group functionality Workstations not user-specific System administrator access Software module access Call box cycling Database and Databus Modular abstraction layer Input and output separated Non-compliant SQL databases Data formats Each user added to a group shall inherit the functionality of the group. In the event of a workstation failure, users shall be able to log into other workstations and have the same functionality as they would if they were at their own workstation. not prevent system administrators from access to the security of the operating system and operating system functionality (access to disk drives, system configuration, etc.) As the TMC software GUI is browser-based, no.exe files shall be placed upon user workstations. The TMC software workstation operator shall have the capability to cycle the call box icon on and off. The databus shall be a modular abstraction layer to allow subsystems to retrieve data. The databus shall have an Interface Control Document (ICD) for client data exchange and an ICD for subsystem data exchange. not require third party subsystems to access an SQL database. extensible Markup Language (XML) shall be used to transmit data to and from the central data repository (databus). WS003 Approved WS004 Approved WS005 Approved WS006 Approved Inspection GS006 Future DB001 Approved Inspection DB001A Approved Inspection DB002 Approved Inspection DB002A Approved Inspection STMCSLS-SRS Draft 8

16 STMCSLS ID FEAT1.2.5 Database reports Reports shall be generated by accessing data in the DB003A Approved database directly. FEAT1.2.6 Historical data An option shall be provided for FDOT to store historical data for traffic management devices for a specified amount of time programmable at the system administrator level. DB004 Approved Each subsystem shall ensure FEAT1.2.7 the central data repository Databus (databus) contains the most architecture recent data, including equipment status. S003 Approved FEAT1.2.8 FEAT1.2.9 FEAT FEAT FEAT FEAT User and device tables Database table update permission Device communication database update Device specification Device status Database clustering Tables shall exist in the Oracle database for entry of GUI workstation users and parameters to set up, control and communicate with devices such as DMSs, CCTVs, cameras, loop controllers, and other devices. allow users with proper security permissions to update database tables from the GUI workstations. Data collected from device communications software shall update the database tables as soon as data is received. support the specification of field device parameters for the creation and control of field devices such as camera control, DMS message content, video wall control, ramp meters, and other devices. Table parameters shall provide for current status of such devices and allow for the creation of status lists based on device. be capable of running in a clustered database configuration. UT001 Approved Inspection UT002 Approved UT003 Approved UT004 Approved UT005 Approved S007 Approved STMCSLS-SRS Draft 9

17 STMCSLS ID The system support function shall store the history FEAT Oracle database table for the future references. System support information pertaining to the jobs status of a job inside the SS001 Approved Inspection The backup component shall shutdown the database and FEAT Database backup take the complete backup of all the database related files SS002B Approved unless a RAID system is used that allows mirroring. FEAT Automated backup The system support function shall provide an automated backup component that can be programmed to perform one or more backups throughout the day at a specific clock time. SS001B Approved FEAT FEAT1.3 FEAT1.3.1 Database parameters Test Plans Provide test plans and procedures use configurable parameters for connecting to the database. be provided with test plans and test procedures for integration cases and the system acceptance test to ensure that each test is comprehensive and verifies all the features of the function to be tested. S007 Approved Inspection QA001 Approved Inspection STMCSLS-SRS Draft 10

18 STMCSLS ID The following information shall be included in the test plan: An implementation plan and detailed schedule (PERT and GANTT Microsoft Word format); Record-keeping procedures and forms; Procedures for monitoring, correcting, and retesting variances; Procedures for controlling and documenting all changes made to the TMC software after the start of testing; Block diagram(s) of the hardware test configuration, including Contract Vendor and Department supplied equipment, external FEAT1.3.2 communication channels, and Test Plans any test or simulation contents hardware; A list of individual tests to be performed, the purpose of each test segment, and the appropriate functional design specification reference describing the feature being tested; Identification of special hardware or software tools or test equipment to be used during the test; Techniques and scenarios used to simulate ultimate system sizings, especially during the peak loading tests; Copies of any certified test data (i.e. environmental data) to be used in lieu of testing; and; Alpha and beta test plans (as appropriate); QA001P Approved Inspection FEAT1.3.3 Test procedure objective Each test procedure shall list the objective of the testing and the specific TMC software system requirement(s) that are being verified along with pass/fail criteria for each. QA002P Approved Inspection STMCSLS-SRS Draft 11

19 STMCSLS ID Test procedures shall include the following items: Function(s) to be tested; Purpose of each test segment; Set-up and conditions for testing including ambient conditions; FEAT1.3.4 Step-by-step procedures to Test procedures be followed; content Pass/Fail criteria for each requirement tested including measurement tolerances; All inputs and expected results outputs for each test segment; and Descriptions of all simulation tools and techniques used during the test. QA003P Approved Inspection All TMC software test results, FEAT1.3.5 Test result formats notes, and observations shall be maintained in both hard QA002 Approved Inspection copy and softcopy. FEAT1.3.6 Test records The test records shall be keyed to the steps enumerated in the test procedures and reported in the test report for each integration case. QA001R Approved Inspection STMCSLS-SRS Draft 12

20 STMCSLS ID The following items shall be included in the test records: Test names and Paragraph numbers; Dates; Test locations; Test specimen serial numbers or other identification; Additional equipment used; Test engineers name; Start and stop times; Log of events; FEAT1.3.7 printouts, photographs, and plots, as applicable, that will be attached to the data sheets; Description of test anomalies (as applicable), Recommendations for resolution of any test anomalies; Provision for comments by FDOT's representative; and A copy of the master test procedure. Test record Observed test results, content including specified computer QA002R Approved Inspection FEAT1.3.8 FEAT1.4 FEAT1.4.1 FEAT1.4.2 FEAT1.4.3 Requirement verification Event Logging Event notification Event notifications stored in database Executive Handler error logging All hardware and software units, elements, components or subsystems shall be tested to verify they meet the specified requirements prior to statewide deployment. Reporting functions shall include the ability to send event notifications via and/or pager, and/or telephone as well as visual and audio notifications at the user console. All event notifications shall be stored in the central database and be tagged with the system time to the nearest second and date of occurrence. The executive handler shall log error conditions as they are detected. S025 Approved Inspection EX001R Approved EX002R Approved EX007 Approved STMCSLS-SRS Draft 13

21 STMCSLS ID FEAT1.4.4 Logging levels The amount of data logged for an error condition shall be able to be adjusted in real time by the user through the EX001L Approved GUI without having to restart the application. FEAT1.4.5 Separate log files Separate log files shall be used for each application EX002L Approved monitored. FEAT1.4.6 Time and origin Each log file message shall be time stamped and shall provide some indication as to the origin of the message EX003L Approved (e.g. what process reported or detected the error). FEAT1.4.7 Contact list Event notifications including alarms shall be sent to a configurable list of people through a primary and secondary contact medium EX003R Approved including electronic-mail, telephone, and pager. The contact list shall be tailored to the event or alarm. FEAT1.5 TMC support the collection, assessment and management of real-time FEAT1.5.1 management information to the motoring public and commercial vehicle operators. Traffic traffic data and video for management delivery of traffic S005 Approved FEAT1.5.2 FEAT1.5.3 FEAT1.5.4 FEAT1.5.5 Management of freeway traffic Exchange requests between centers Software reliability Monitor processes support the management of traffic along the State freeway system. support the exchange of traffic management requests among centers running the TMC software. not require any regularly scheduled down time. provide a mechanism for monitoring the health and status of TMC software. A024 Approved A025 Approved A026 Approved S028 Approved STMCSLS-SRS Draft 14

22 STMCSLS ID be FEAT1.5.6 eight hours. Unattended capable of running operation unattended for a minimum of A027 Approved Test FEAT1.5.7 Data exchange support the exchange of data using the center-to-center A030 Approved ICD. FEAT1.5.8 Work zone support traffic management in a work zone via A031 Approved communication to wireless or wired devices. FEAT1.5.9 TMC categories support running in multiple TMC configurations. FEAT RTMC support running in a regional TMC. A029 Approved FEAT FEAT FEAT FEAT1.6 FEAT1.6.1 FEAT1.6.2 FEAT1.6.3 STMC VTMC PTMC Software & Documentation Management TMC software monitoring Architecture standards Configuration management of devices support a secondary TMC sending command and control requests via center-tocenter. support operating the center from a remote location. support deployment of the system on a laptop. log communication errors and ITS field device failures. adhere to open architecture standards. A configuration management template shall be provided to capture information needed to control ITS devices. A029 Approved A029 Approved A029 Approved A013 Approved S027 Approved Inspection A014 Approved Inspection STMCSLS-SRS Draft 15

23 STMCSLS ID Baseline of Before any software development begins, off-theshelf software that will serve to be the foundation of the TMC software system shall be documented to establish a FEAT1.6.4 software for baseline for configuration configuration management of what S029 Approved Inspection management software is developed specifically for the STMCSLS project including what software is modified and to what degree it has been modified for the project. FEAT1.6.6 FEAT1.6.7 FEAT1.6.8 FEAT1.6.9 FEAT Documentation requirements Software library modules Recommended responses Future capabilities Flexible and expandable be provided with a complete documentation package that shall include, but not be limited to, detailed functional and interface description, user/operator manuals, software standards manuals, software test plans and procedures, and all other documentation required to complete the STMCSLS project. The Statewide Software Library system shall provide for a centrally managed set of software modules that completely support all functionality of the RTMCs. provide intelligent software that presents a list of recommended responses in time ordered sequence to different event conditions to the workstation operator. provide an ICD for the databus to allow additional subsystems to be added. provide ICDs for subsystem device drivers to be added. S024 Approved Inspection S001 Approved Inspection EX008 Approved A028 Approved Inspection S004 Approved Inspection STMCSLS-SRS Draft 16

24 STMCSLS ID FEAT Automation of system support support the automation of system support tasks through the use of user modifiable scripts for the following functions: * System scheduler; S011 Approved Inspection tasks * System backup; * Data archiving; * Maintenance of system integrity; and * Data links to other FDOT computer systems. FEAT Software function provide each TMC with the software tools that can be used to reduce congestion and delays while responding to traffic incidents in a rapid, accurate, and effective S006 Approved Inspection FEAT FEAT Limited access facilities Traveler information manner. provide for the management and operations of limitedaccess facilities during incident management, and peak demand periods and one-way operations during evacuations including control of detour signage. provide software for the collection and dissemination of traveler information using dynamic message signs (DMS), trail blazer signs, highway advisory radio (HAR), and advanced traveler information system (ATIS) services (511 telephone services, Internet, commercial radio, television, text messaging, etc.) for freeway operations and where available along other arterial routes independently or through an information service provider (ISP contractor) contract vendor for ATIS. The ATIS capability shall support disseminating information by the Amber Alert program. A003 Approved Inspection A004 Approved Inspection STMCSLS-SRS Draft 17

25 STMCSLS ID interface with FDOT legacy FEAT device drivers through FDOT legacy standardized device device drivers interfaces documented in the TMC software Interface Control Documents. S018 Approved Inspection provide a mechanism to FEAT Software versions display the versions of the various TMC software applications. A014 Approved FEAT1.7 FEAT1.7.1 FEAT1.7.2 FEAT1.7.3 FEAT1.7.4 FEAT1.7.5 System Misc. Video wall software Motorist aid call box system Data reporting Traffic and delay prediction Action checklist not preclude the operation of video wall control software from a workstation that also has the TMC software on it. provide software for management and operations in support of the motorist aid call box system if a remote interface (via either TCP/IP or RS-232) exists on the motorist aid call box system and the interface provides status of the call box. provide for the reporting of data; data to be included in the reports shall be provided by FDOT by March 15, provide software for traffic and delay prediction to support incident management and performance monitoring (including travel times and travel speeds). The operator workstation shall display a list of actions to be taken in response to specific events that require TMC operator response and can be checked off as they are completed. S013 Approved Inspection A016 Future A017 Approved A018 Approved WS001A Approved STMCSLS-SRS Draft 18

26 STMCSLS ID The list of actions to be taken in response to a specific event detected by the TMC software shall be interactive and shall tailor itself to the specific situation. For example, if a major traffic incident is detected on a FEAT1.7.6 limited access facility, the Interactive operator at a workstation at response the RTMC that has procedures responsibility for that sector would be presented with a list in time ordered sequence of who to notify, the proper contact number(s) or other appropriate response. As each step is completed, the software shall highlight the next step. WS002A Approved FEAT1.7.7 FEAT1.7.8 FEAT1.7.9 FEAT Use operating system schedulers Interface to Amber Alert ITS Devices Interface to portable DMS and CCTV. Report creation All other backups, background, batch and performance evaluation jobs shall be documented and be able to be used as operating system schedulers such as "cron" jobs. provide an interface to ITS devices that are used in the Amber Alert program including portable dynamic message signs and the communications links to operate them. provide an interface to portable changeable message signs (CMSs) and CCTVs that support work zone management through a minimum of two drivers supporting: Florida MIB (subset of the NTCIP standard); Mark IV support the creation of reports by authorized users. SS002 Approved Inspection TB002 Approved Inspection S030 Approved Inspection S009 Approved STMCSLS-SRS Draft 19

27 STMCSLS ID FEAT Print report utility All reports shall be selected from a print menu on the operator's workstation and shall contain location parameters that indicate roadway segment links. The report will be printed with controls for page setup and for how many copies are printed. WS007 Approved Inspection STMCSLS-SRS Draft 20

28 STMCSLS ID Device drivers shall communicate to the field devices through FDOT networks and perform the following: Set or check the date and time; Poll the device on a periodic basis as specified in the database and retrieve device status; Check the cyclic redundancy check of the device operating parameters and message library against the cyclic redundancy check parameters of the database; Download operating parameters; Upload the current operating parameters and display on user's workstation; Display all database parameters and attributes on FEAT All uploaded information from the device shall be displayed at the user's workstation; The operator, with proper security, shall be able to display/change database messages and parameters; A log of all changes shall be maintained by time and operator identification; Provide test mode set of commands; Provide a method for restricted access to selected devices based upon incident management criteria; Provide a log of all communcation events to and from the device including the report of device errors; and Provide the capability to stop and restart the device driver via operator control. General device the user's workstation as driver appropriate to the device; EX009 Approved STMCSLS-SRS Draft 21

29 STMCSLS ID provide software for coordination with all law enforcement, fire/rescue, and emergency management personnel, coordination with local traffic operation centers, FEAT1.8 and coordination with county Coordination of emergency management agencies centers and the State Emergency Operations Center (SEOC) when appropriate. The data will be either available through the Center-to-center interface or through the use of a remote interface terminal. A011 Approved Inspection FEAT2 FEAT2.1 FEAT2.2 FEAT2.3 FEAT2.4 FEAT3 Web server Web server function Video server Access to camera system control functions Map elements: congestion, incidents, cameras, DMSs Executive Handler (EH) The TMC software shall provide a web server for private and public dissemination of TMC information. The web server shall capture and publish video from analog and digital video devices within the system for private and public dissemination via LAN, WAN, and the World Wide Web. The video server shall refresh and update the image at a rate set via parameters by the workstation operator. The web server shall provide secure access to system control functions of selected cameras as determined by the system administrator for users with high-speed Internet access. The web server shall provide a map showing the congestion levels and all current incidents on the highway. The map shall show where cameras and DMSs are located. S020 Approved PA001 Approved PA002 Approved PA004 Approved STMCSLS-SRS Draft 22

30 STMCSLS ID have an executive function that FEAT3.1 external devices and internal processes. Executive handler handles all monitoring and function reporting of the status of S008 Approved FEAT3.2 FEAT3.3 FEAT3.4 FEAT3.5 FEAT3.6 FEAT3.7 FEAT3.8 Minimum functionality Start, stop, and restart processes Scheduled process control stored in database Group dependencies Process start order Restart safeguards Initialize individual components As a minimum the executive handler shall provide: Process initiation/termination; Process status and monitoring; Error logging. The executive handler shall be capable of automatic (scheduled) and manual initiation, termination and reinitiation of system processes. The executive handler shall have the capability to read scheduled process control from the central database. The executive handler shall also have the capability to group dependencies between applications and resources into hierarchical subsystem groups, so that if a failed application's required resource has been determined to be offline, unavailable or exhausted, the application can be failed over to an alternate processor or appropriate notification can be initiated. In the case of a failure, the executive handler shall start processes in the same order that they originally started. In the case of a process failure due to unavailable resources, the executive handler shall have safeguards to prevent the unrestrained cyclical restart of failed applications. The executive handler shall have the ability to initialize individual components as well as subsystem groups. EX001 Approved EX002 Approved EX003 Approved EX004 Approved EX001F Approved EX002F Approved EX005 Approved STMCSLS-SRS Draft 23

31 STMCSLS ID The executive handler shall be capable of monitoring, FEAT3.9 reporting, and displaying the Monitor, report status of all subsystems, and display status subsystem components, and network communications links and components. EX006 Approved The executive handler shall provide a hierarchical view of FEAT3.10 Hierarchal view the system allowing the user to drill down from a EX001D Approved subsystem level to an individual component level. FEAT3.11 Monitor key data Monitoring shall include pertinent system information such as the current system state, as well as historical information such as system performance, uptime, and error logs. EX001M Approved FEAT3.12 FEAT4 FEAT4.1 FEAT4.1.1 FEAT4.1.2 FEAT4.1.3 FEAT4.1.4 Database storage of information Inventory Management System (IMS) System Interface to maintenance and inventory tracking software Index by equipment type Vendor name referenced by equipment type ID. Reports provided by type ID All information collected shall be capable of being stored in the database. be provided with an interface to a software system that tracks the inventory of all ITS equipment and the status of equipment repair(s) and maintenance (i.e. life-cycle asset management software system). The inventory/maintenance software database shall index by equipment type for the purpose of reporting and updating the inventory. The vendor name shall be referenced by the equipment type identification. Reports shall be provided by type identification for all equipment according to equipment status. EX002M Approved Inspection S022 Approved IM002 Approved IM001D Approved IM001R Approved STMCSLS-SRS Draft 24

32 STMCSLS ID The workstation operator shall be capable of viewing FEAT4.1.5 according to a specific type identification. View and print and printing the complete vendor table vendor table or the vendors IM002D Approved The inventory/maintenance software shall maintain warehouse locations, repair FEAT4.1.6 Location data shop locations, and installation locations, with a GUI screen to add/edit/delete IM003D Approved FEAT4.1.7 FEAT4.1.8 FEAT4.1.9 FEAT FEAT FEAT4.2 Equipment status catagories Record status of equipment Equipment status tracking Save repair information Repair history GUI such locations. The equipment status shall be: In inventory; Installed; or In repair/test. The inventory/maintenance software shall provide the operator the capability to record the status of equipment that has failed and is in the process of being repaired. The inventory/maintenance software shall support tracking the status of the equipment being tracked as follows: Failed at site; At repair depot; In repair at depot; In testing at depot; and In inventory. The inventory/maintenance software shall contain repair information on the equipment to include the dates of failure and repair, the repair technician, the time to repair, parts utilized by part number and comments. The inventory/maintenance software shall maintain a history of the equipment repairs and may be reported via GUI to the operator or may be printed. IM005D Approved IM004 Approved IM006D Approved IM005 Approved IM006 Approved STMCSLS-SRS Draft 25

33 STMCSLS ID The inventory/maintenance software shall provide a GUI display screen for the operator to add/edit/delete inventory equipment information. The equipment information shall at a minimum include: FEAT4.2.1 FEAT4.2.2 FEAT4.2.3 FEAT4.2.4 Add/edit/delete equipment GUI Add/edit/delete vendor information GUI Print reports GUI Equipment history GUI Type identification and description; Model identification and description; Manufacturer information; Serial number; Firmware version; Location description; Date installed; (inventory/installed/repair); Location geographic reference; and Quantity by Type identification on hand. The inventory/maintenance software shall provide a GUI for the operator to add/edit/delete vendor information. The vendor information shall at a minimum include the following: Vendor name; Vendor contact; Address/ information including city, state, and zip code; Telephone and facsimile numbers; and Web address for purchase. All printed reports of the inventory software shall be selected via a GUI menu. History of the equipment transfer and its inventory status shall be maintained and reported via GUI to the workstation operator or printed. IM001 Approved IM003 Approved IM002R Approved IM004D Approved STMCSLS-SRS Draft 26

34 STMCSLS ID FEAT4.2.5 Displays The displays shall result from a comparison between all possible sources of data derived from real-time data, operator input or historical data as determined by the algorithm. ID001W Approved FEAT4.2.6 The repair status of a specific Repair status piece of equipment shall be display displayed to the operator. IM007 Approved FEAT5 Incident Management (IM) FEAT5.1 FEAT5.1.1 FEAT5.1.2 FEAT5.1.3 FEAT5.1.4 FEAT5.2 FEAT5.2.1 General Minimum functionality Incident type Video verification Minimize keystrokes Detect Incident detection The incident management subsystem shall acquire data from the vehicle detection subsystem and include the following functionality at a minimum: Incident verification; Motorist information; Response; Site management; Traffic management; and Incident clearance. The incident management function shall support operator entry of the incident type such as HAZMAT spills. provide software for video verification of messages posted on DMS to the extent possible due to physical configuration in the field of the camera and sign. The TMC software s incident management function shall minimize the number of key strokes for the entry of traffic incidents while providing drop-down menus, check boxes, and data interfaces with subsystems such as the road weather information systems (RWIS), vehicle detection, motorist aid, vehicle detection, motorist aid (AVI), DMSs, and CCTVs. provide software for incident detection along the limitedaccess facilities. TM002 Approved TM003W Approved A009 Approved TM001 Approved A001 Approved STMCSLS-SRS Draft 27

35 STMCSLS ID Automatic support the detection of incidents or congestion, via a FEAT5.2.2 detection of software algorithm, that incident or determines occupancy, ID001 Approved congestion volume, or speed and makes a determination based on user-defined thresholds. FEAT5.2.3 FEAT5.2.4 FEAT5.2.5 View congestion report View incident or congestion raw data Manual incident entry provide the ability to view a congestion report for all roadway segments in the system. The congestion report shall include a graphical display and the following information for each roadway segment in the system: Roadway segment identifications; Source of the incident or congestion information; Reported speeds [in miles per hour (MPH)] Historic speeds (in MPH); FDOT's LOS; Congestion cases (i.e. closed, heavy, moderate, none, or free flow); and Other recommended parameters. The workstation operator shall have the ability to view an incident or congestion raw data report for all links in the system. The workstation operator shall have the ability, via a menu and the selection of a link on a map, to enter manual incident or congestion information. The incident or congestion information the user may enter shall include: Congestion case (i.e. closed, heavy, moderate, none, or free flow); Incident types; Roadway weather conditions; and Incident duration (i.e., the amount of time incident the will last). ID002 Approved ID003 Approved ID004 Approved STMCSLS-SRS Draft 28

36 STMCSLS ID FEAT5.2.6 Graphical displays The report shall include graphical displays and the following information for each roadway segment in the system Roadway segment identifications; Roadway segment ID002W Approved geometries; Source names (determined by the algorithms); Reported speed, volume, and occupancy; and Congestion case. FEAT5.3 Manage The personnel list shall be on a geographic basis and, at a minimum, shall include. Response personnel/and contacts; FEAT5.3.1 Geographic agency Geographic responsibilities; personnel lists Talk list (i.e., responders contact list); Radio frequencies; Phone/ and facsmiles numbers; and Pager numbers. TM001R Approved The incident management software will provide the FEAT5.3.2 Messaging ability to redirect incident information to standard message services (such as TM002R Approved FEAT5.3.3 FEAT5.3.4 FEAT5.3.5 Cataloging of incident management teams/resources Recommend DMS/HAR locations and messages Recommend a set of HAR messages FAX, , pagers). The incident Management function shall support the cataloging of incident management teams and resources with a listing of equipment, material, and the available personnel who possess special skills. The incident management response function shall recommend a set of DMS locations and messages for the workstation operator to select. In addition, HAR messages shall be activated. The incident management response function shall recommend a set of HAR messages to be activated. TM003R Approved TM005R Approved TM006R Approved STMCSLS-SRS Draft 29

37 STMCSLS ID The incident management response function shall FEAT5.3.6 display, on the GIS map, Recommend recommended alternate alternate routes routes in response to incidents that are blocking roadways. TM007R Approved FEAT5.3.7 FEAT5.3.8 FEAT5.3.9 FEAT FEAT Select alternate maps Communicate with detour message signs Hierarchy of traffic management activities Personnel lists and contact numbers Distribute information In response to incidents requiring alternate route(s), the workstation operator shall be able to select alternate maps via drop down menus. When appropriate, the incident management response function shall communicate with detour message signs that are supported by the TMC software and TMC communications network capability indicating recommended alternate routes. The incident management response function shall support a hierarchy of traffic management activities and display these activities for review by RTMC managers. The incident management function shall provide the workstation operator with personnel lists and contact numbers as well as a catalog of agency resources via dropdown menus. The incident management function shall distribute video feeds, traffic flow, and incident information, and traffic event data until the incident is cleared and the traffic flow is back to normal. TM008R Approved TM009R Approved TM010R Approved TM005 Approved TM004 Approved STMCSLS-SRS Draft 30

38 STMCSLS ID The incident management function shall format information for distribution to the following dissemination media: HAR; Commercial radio broadcast; FEAT Telephone systems; Commercial and public televisions; Facsmile machines and pagers; and Additional dissemination mechanisms provided by the dissemination function. Format for Internet Web servers; dissemination DMSs; TM001I Approved FEAT FEAT FEAT FEAT Quick click interface to GIS Incident status GUI Traffic control procedures Incident removal resources The incident management function shall provide a quick click interface to the GIS maps for the display and location of resources, i.e. fire hydrants. The incident management function shall provide the workstation operators with GUI screens that record accurate information regarding the incident's current status, the overall progress towards clearance and the equipment required to complete the process. The incident management function shall support the RTMC with traffic control procedures that include, at a minimum, point traffic control at the scene, managing the roadway space, and deploying personnel to better manage the traffic by improving traffic flow past incident sites and on alternate routes. The incident management function shall provide support to the incident clearance process by the cataloging of resources for the removal of the all types of incidents. TM004R Approved TM006 Approved TM007 Approved TM008 Approved STMCSLS-SRS Draft 31

39 STMCSLS ID Included in the catalog shall FEAT be the resource, location, Catalog of FDOT cost of service, and resources availability of related equipment and resources. TM011R Approved FEAT FEAT FEAT FEAT FEAT FEAT Construction work zones Map display Incident data archiving Management, dispatch, and coordination of RR Service Patrols. Coordination of freeway incident management team Diversion routes provide for the identification of construction work zones and activities to support operations and management of these work zones and, where smart work zone management is provided, integration of the smart work zone management into freeway management systems (FMS) and incident management systems (IMS). The system shall have a map display of the current incident or congestion for each segment. The map shall change the color of the roadway segment based on the current condition. An algorithm will determine the congestion case. provide software for Incident data archiving. provide software for the management, dispatch, and coordination of Road Rangers Service Patrols. provide software for coordination with a freeway incident management team involving major stakeholders. provide software for the maintenance of a list of diversion routes for management of traffic during incidents and evacuations. The software shall tie in with construction updates to avoid detours into construction areas. A006 Approved ID005 Approved A010 Approved A012 Future A015 Approved A022 Approved STMCSLS-SRS Draft 32