statewide transportation management center software library system software requirements review...

Statewide Transportation Management Center Statewide Transportation Management Center Software Library SystemSoftware Library System

Software Requirements Review (SRR)Software Requirements Review (SRR)and Status Meeting and Status Meeting

January 8, 2004January 8, 2004

January 8, 2004STMCSLS Status Meeting and SRR 2

AgendaAgenda

8:30 – 8:35 Introductions All

8:35 – 9:30 High-Level Requirements Summary Dellenback / Randolph

9:30 – 10:00 Requirements to Discuss Dellenback / Randolph

10:00 – 10:15 Break

10:15 – 10:45 Issues from Small Group Meetings Dellenback / Randolph

10:45 – 12:00 Open Requirements Discussion / Comments All

12:00 – 1:15 Lunch

1:15 – 1:30 GUI / CCTV Demonstration Dellenback / Randolph

1:30 – 2:15 Open Requirements Discussion / Comments – Con’t All

2:15 – 3:00 STMCSLS Status Report Dellenback

3:00 – 3:15 Break

3:15 – 4:00 Impact of adding New Devices Dellenback

4:00 – 4:20 Open Discussion: MDX and Lee County All

4:20 – 4:30 Action Item Summary Dellenback


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





Requirements ProcessRequirements 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


SRS DevelopmentSRS 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.


Requirements ViewRequirements View


Requirements View - continuedRequirements View - continued


Select Synopsis of some High-Level Requirements


High-Level Review:High-Level Review:User LevelsUser 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


High-Level Review:High-Level Review:DMSDMS

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


High-Level Review:High-Level Review:CCTVCCTV

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


High-Level Review:High-Level Review:Traffic DataTraffic 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.


High-Level Review:High-Level Review:GUIGUI

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.


High-Level Review:High-Level Review:Incident ManagementIncident 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)


High-Level Review:High-Level Review:LoggingLogging

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


High-Level Review:High-Level Review:ReportsReports

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


Total RequirementsTotal Requirements

System FDOT SwRI Added

General 81

Web server 4Executive Handler (EH) 12 6

Inventory Management System (IMS) 17Incident Management (IM) 34 1Data Distribution (DD) 3 6GUI 7 7CCTV 30 11DMS 7 20TSS 11 5

Evacuation Coordination (EC) 39

RWIS 10C2C 3 17

Data Archiving (DA) 5

HAR 11

Status Logging (SL) 9

USER 3

Total Requirements 263 96

Future Requirements 43

FDOT to Address 23

SwRI to Address 197 96


Requirements StatusRequirements 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)


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





Requirements to DiscussRequirements 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


Requirements to Discuss:Requirements to Discuss:Non-testableNon-testable


Requirements to Discuss:Requirements to Discuss:Non-testable - continuedNon-testable - continued


Requirements to Discuss:Requirements to Discuss:RewordedReworded


Requirements to Discuss:Requirements to Discuss:Assigned to FDOTAssigned to FDOT


Requirements to Discuss:Requirements to Discuss:Assigned to FDOT - continuedAssigned to FDOT - continued


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





Issues Identified During Small Issues Identified During Small Group Requirements MeetingsGroup 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


Issues Identified During Small Group Issues Identified During Small Group Requirements Meetings – con’tRequirements 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.



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.



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



General:

– Device support: what devices will be supported? SwRI response:

• Working with FDOT on adding additional device drivers


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





Open Discussion on SwRI STMCSLS Requirements


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





CCTV GUI DemonstrationCCTV 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


CCTV GUI Demonstration CCTV GUI Demonstration Software SetupSoftware Setup


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





Open Discussion on SwRI STMCSLS Requirements


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





Project Web SiteProject Web Site

http://stmcsls.datasys.swri.edu


Proposed STMCSLS Proposed STMCSLS ArchitectureArchitecture

Robust

Extensible

Flexible

Scalable

Configurable

Proven


Release-Oriented Release-Oriented Development ApproachDevelopment Approach

Release 1 Release 2a Release 2b not in scope


““Generic Subsystem” DesignGeneric 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


Scope of STMCSLS EffortScope of STMCSLS Effort

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


Status of Release 1 ActivitiesStatus of Release 1 Activities

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


Deliverable StatusDeliverable 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.


Cost StatusCost 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


Schedule StatusSchedule Status

Current schedule is posted to project web site Overall project status:

– Ahead in many places– Beginnings of STMCSLS operational in the lab, primarily:

• Support processes (executive, logging)• Data Bus• DMS• Online soon in preliminary form: CCTV and TSS

(Transportation Sensor Subsystem) Current areas of concern:

– Lack of Oracle licenses could impact schedule– Documents:

• Concept of Operations• Security Plan

– Lack of final device drivers


Schedule Status - continuedSchedule Status - continued

SwRI would encourage a project status meeting during ITS America (April 26 – 28 in San Antonio)

SwRI would recommend April 29th

Agenda:– Project status– See STMCSLS operating in a multi-server, multi-

workstation environment– Meet the development team

Note: ITS Central Office will email all committee members about their plans in attending ITSA 2004


Action ItemsAction Items


Action Items - continuedAction Items - continued


SwRI STMCSLS LabsSwRI STMCSLS Labs


SwRI STMCSLS Labs – con’tSwRI STMCSLS Labs – con’t


General Comments / Feedback on Project Status


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





STMCSLS and Device DriversSTMCSLS and Device Drivers

Device functionality isolated by “ICDs” (Interface Control Documents)

Subsystems are “generic” and not specific to device functionality

Device drivers easy to add once base subsystem is complete and operational


Device Drivers In BAFO That Were Device Drivers In BAFO That Were Approved For ImplementationApproved For Implementation

DMS:

– NTCIP

– Mark IV (v 2.5)

CCTV (Cameras):

– NTCIP

– SunGuide

Video Switch:

– American Dynamics 2050

Traffic Detectors:– BiTrans 238I-95

Ramp Metering:– WsDOT

RWIS:– NTCIP

HAR


Device Drivers In BAFO That Were Device Drivers In BAFO That Were NOT Approved For ImplementationNOT Approved For Implementation

DMS:– Dambach– Vultron– Telespot

Video Switch:– Javelin– Cornet

CCTV:

– Pelco

– Vicon

– Hitachi

– Diamond

– Sanyo

Detection:

– Trafficon


SwRI Asked To Evaluate the SwRI Asked To Evaluate the Following IssuesFollowing Issues

IP Addressable devices:– The STMCSLS device drivers utilize TCP/IP

communications to communicate to terminal servers in the field

– The terminal server converts from TCP/IP to RS-232– The STMCSLS device drivers should be capable of

communicating directly to a IP addressable device, BUT, FDOT should provide a test device for SwRI to evaluate

Statewide IP address system coordination– SwRI is not sure of what actions need to be taken


SwRI Asked To Evaluate Adding SwRI Asked To Evaluate Adding New Devices to STMCSLS EffortNew Devices to STMCSLS Effort

Micro loop

RTMS

360 Surveillance

Streaming (IP) Video

Intelligent Devices


TSS Subsystem and DriversTSS Subsystem and Drivers

Transportation Sensor Subsystem (TSS) acquires vehicle information

Wide variety of detection devices available

Loops (or devices that emulate loops) are the most common


Micro LoopsMicro Loops

Assumptions:– Will use a Canoga micro loop controller from 3M

Scope of work:– A device driver compliant with the STMCSLS

TSS device driver Interface Control Document (ICD) interface shall be developed

– Efforts will include:• Design• Peer Review• Implementation• Testing• Integration with the TSS subsystem


RTMS DeviceRTMS Device

Assumptions:– A device driver for a Wavetronix SmartSensor device

will be developed.– The TCP/IP interface from the device will be used to

retrieve data Scope of work:

– A device driver compliant with the STMCSLS TSS device driver Interface Control Document (ICD) interface shall be developed

– Efforts will include:• Design• Peer Review• Implementation• Testing• Integration with the TSS subsystem


STMCSLS and 360 SurveillanceSTMCSLS and 360 Surveillance

SwRI recommendation:– Support:

• STMCSLS• 360 Surveillance

– Provides common GUI– Supports C2C software

concept– Does not “force” a

vendor solution to all Districts

Issues:– Software ownership– Device support (drivers

still needed)

Two video solutions can coexist with STMCSLS

architecture


Interfacing STMCSLS to the 360 Interfacing STMCSLS to the 360 Surveillance Cameleon SoftwareSurveillance Cameleon Software

360 Surveillance plans for an API to be developed in 1st Quarter 2004 (per salesperson)

STMCSLS could access this API to connect the 360 Surveillance software to the STMCSLS video subsystem (using the existing ICD)


360 Surveillance360 Surveillance

Assumptions:– 360 Surveillance will develop an API to access their control software,

SwRI will need to be able to review the API to assure it meets the STMCSLS needs

– FDOT will provide SwRI with a copy of the 360 Surveillance Cameleon software

– FDOT will provide appropriate test hardware to SwRI (for use in testing in the SwRI labs) within 2 months of starting the work.

Scope of work:– A device driver compliant with the STMCSLS CCTV video switch

Interface Control Document (ICD) and the camera device ICD interface shall be developed

– Efforts will include:• Design• Peer Review• Implementation• Testing• Integration with the CCTV subsystem

Note:– The functionality of the interface may be limited based on the

capabilities of the API provided by 360 Surveillance


Streaming IP VideoStreaming IP Video

IP video is the current direction for many ITS applications

Synopsis of technology:– Video is “encoded” (typically into MPEG-2) at the

source– Encoded video transmitted via TCP/IP multicast– Network hardware must support multicast

transmittal (hardware > 3 years may be problematic)

– Video is “decoded” where it is to be displayed– In THEORY: encoders/decoders should be inter-

operable (and some vendors are)


Streaming (IP) VideoStreaming (IP) Video

Assumptions:– SwRI will procure (augment) the following IP video hardware (on SwRI funds):

• VBrick• CoreTec• Teleste

Scope of work:– A device driver compliant with the STMCSLS CCTV video switch ICD– Efforts will include:

• Design• Peer Review• Implementation• Testing• Integration with the CCTV subsystem

Issues:– Network topology (e.g. network switches) may not all support the exchange of

IP based video, the Streaming Video task does not include any time for network design or evaluation – it is assumed that the network will support the exchange of IP based video.

– The Streaming IP Video effort only controls the switching of video, specific camera drivers must still be developed to control the positioning of camera devices.


Using IDI DevicesUsing IDI Devices

Exposes NTCIP functionality for any device (per IDI)

Loop through capability facilitates deployment and “cut over”

Augment device functionality (e.g. FDOT MIB)

STMCSLS NTCIP Interfaces:– CCTV (funded)– DMS (funded)– TSS (not funded)


Intelligent DevicesIntelligent Devices

Assumptions:– FDOT will procure all devices– All NTCIP compliance testing to be performed by FDOT

(TERL)– No software development effort by SwRI

Scope of work:– Work with FDOT staff to identify candidate devices– Observe NTCIP testing with FDOT staff– Once devices accepted by FDOT, perform integration

testing with STMCSLS software framework

ITS Central Office Note: Funding source of Intelligent Device procurement may come from STMCSLS Project budget allocated to the specific device driver replaced by Intelligent Device hardware.


Device Driver CostsDevice Driver Costs

SwRI was asked to evaluate the current device driver costs

Current device drivers were included in the BAFO approved by FDOT

New drivers can be added:

– SwRI based cost estimates on some assumptions (see previous slides)

– SwRI has developed cost estimates

– Schedule impact may vary based on timing and number of new drivers added


Device Driver Costs - continuedDevice Driver Costs - continued

Currently funded:– NTCIP CCTV Driver: $131,618 (spent ~$17,037 to date)– BiTrans TSS Driver: $99,480 (spent ~$2,222 to date)– AD 2050 Video Switch: $70,167 (spent ~$1,135 to date)– SunGuide CCTV Driver: $87,348 (spent $0 to date)– Mark IV DMS Driver: $52,504 (spent ~$14,160 to date)– NTCIP DMS Driver: $52,210 (spent ~$35,711 to date)

New potential device drivers (assume start on 2/1/04):– Microloop: $129,074, 4 months– RTMS: $103,684, 4 months– 360 Surveillance: $135,224, 8 months– Streaming (IP) Video: $97,260, 4 months– Intelligent Devices: $89,910, 18 months


Device Driver Costs – Device Driver Costs – SwRI Needs DirectionSwRI Needs Direction

Current drivers:– Continue on with current activities?– FDOT would need to initiate a contract modification

to delete the work

New drivers:– Cost and schedule has been determined by SwRI– FDOT would need to initiate a contract modification

to add the work– Any additions would need to be done soon to make

Release 1

No contract modifications implies that the device drivers included in the BAFO estimate will be delivered.


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





Open Discussion on MDX and Lee County Participation – What Devices Need To Be

Supported?


AgendaAgenda




10:00 – 10:15 Break



12:00 – 1:15 Lunch




3:00 – 3:15 Break





Action Item RecapAction Item Recap

Number Person Action

1

2

3

4

5

6

7


STMCSLS Project Team Contact STMCSLS Project Team Contact InformationInformation

Southwest Research InstituteP.O. Drawer 28510

San Antonio, Texas 78228

PB Farradyne3206 Tower Oaks BoulevardRockville, Maryland 20852

Steve [email protected]

(210) 522-3914

Robert [email protected](210) 522-3814

Charlie [email protected]

(352) 374-6635

John [email protected]

(301) 816-1852

statewide transportation management center software library system software requirements review...

Documents

stmcslsstmcsls status

current status informationecho

view status remote guest

srrhighlevel review

control functions

cctv control

ptzirisfocusswitch control

device control